  |
はてなキーワード: PROLOGとは
Liella!5th福岡ライブにおいて、Starlight Prologを始めとしたアニメ1期曲の11人披露で再び1期生5人原理主義者と現行Liella!推しラブライバー(以下リエライバーと称す)が議論する炎上が起こった。
筆者はラブライブ！スーパースター！！を視聴し、その感動に浸り、1stライブまで見に行き2期生が来ると知ってLiella!を去った5人原理主義の1人だ。アニメは一応2期も視聴済だが、到底話したくない内容だ。もちろん今回のセトリにはいろいろ思うところがある。ただ、今回の炎上で5人原理主義者を叩くリエライバーの内容を見るとあまりにも屁理屈が多くて頭を抱えてしまったところではある。なので代表面をする訳では無いが、5人原理主義者は何も考え無しに批判している訳ではないと伝えるため、今回はてな匿名ダイアリーを利用し1人の原理主義者としての考え、主観をここに記すことにした。匿名にした理由は筆者個人の都合及び(筆者の仲良い人との)トラブル防止としていることをご理解いただきたい。
まず始めに筆者は全てのラブライブ！シリーズをアニメを主体として評価、或いは批判している。それはアニメ自体もそうだがライブでも同様に鑑賞している。今回話すことの大半はアニメを主題としていることを理解いただきたい。また原理主義者であると記したが、11人でLiella!という現状は概ね理解している。なので5人でLiella!という絶対的な主観までは持ち合わせていないことを伝えておく。しかし筆者の中での最高傑作はもちろんアニメ1期であり、5人のLiella!を原点として考えている。逆に現行の9人、11人体制発表には酷く幻滅した。結局私が見たアニメ1期は何だったのかと。5人でもラブライブ！という証明がアニメをもって発表されたにも関わらず結局人を増やしますと言われて「そうなんですね！続きも期待してます！」にはならない。筆者は「5人で物語が続く」と思っていたから。ただ決まってしまったものは仕方ないので、せめてアニメ2期や次回ライブで1期の曲は5人でこそ...と思った結果があのザマである。雑なシナリオ、不憫なキャラの描かれ方、アニメ1期で得た感動を全て雑にして返されたようなものだ。そして挙句の果てにはその都度行われた9人ライブでかつて披露された5人の曲を歌い始めたのだ。ここら辺については語ると物凄く長くなってしまうので省略するが。
せめて、1期公開前に最終的にLiella!は11人になりますという示唆があればそれを受け入れて1期を見れただろう。もちろん1期最終話のラブライブ！敗北の味が薄くなってはしまうが、次が来るということの心の準備はできていた。その示唆さえなくあの神作品ができてしまえば、5人でLiella!という価値観として結ばれるしあとから人増やしますねと言われても納得が行くわけが無い。最初から言ってほしかった。要するに、私が見たアニメ1期を返してほしい、続けていくのであればアニメ1期のストーリーや曲の思い出を大切にしてほしいというのが筆者なりの原理主義に基づく考えだ。
さて、筆者個人の考えはここまでとし本題の炎上の方に入る。単刀直入に言えば、現リエライバーの擁護があまりにも屁理屈すぎて説得力に欠けていた。様々な意見を見たが、特に「虹ヶ咲は12人で歌ってるじゃん」「異次元フェスでスノハレアイマスが歌ったじゃん」「キャストが傷つく、キャストはMCでこう言っていたじゃないか」という主張を多く見受けた。それぞれの意見について筆者の見解は下記の通りだ。
・虹ヶ咲は12人で歌ってるじゃん→アニメ1期の曲は12人で歌ってないけど？
虹ヶ咲1期で披露されたアニメ曲はソロを除きOPの虹色Passions!、EDのNEO SKY NEO MAP、13話披露曲の夢がここからはじまるよの3曲になるがどれも9人でないし当時のメンバー及び9人で歌っている(後述するが異次元フェスは例外とする)。R3BIRTHの3人は上記3曲を1度も歌っていないしまして初披露となる4th大阪1日目で虹パが披露された時はちゃんと9人(楠木ともりは病のため不登壇だったが)で歌った。アニメを主体として批判しているので前期曲を歌っていないR3BIRTH3人組を含めた12人の虹ヶ咲と、前期曲を歌った11人のLiella!では引き合いに出せない。まあそもそも虹ヶ咲がラブライブ！とは似て非なる番外編ということを割り切っているからというのもあるが。
・異次元フェスでスノハレアイマス歌ったじゃん→スパスタ！！のアニメを主体にした批判で他コンテンツを引き合いに出す脳みそを持つ人間がラブライブ！コンテンツにいることに戦慄している。異次元フェスはアイドルマスターとの「コンテンツ間におけるコラボレーション」としてのライブなのでアニメを主軸として鑑賞はしなかった。それこそアイマスキャラ含めた虹色Passions!、私のsymphonyをやったが原理主義の感情が出てくるほど嫌とは感じなかった。
・キャストが悲しむ、キャストのMCを聞かなかったのか→筆者が1番この意見に苛立ちを覚えた。そもそも声優のことについて批判していないしどちらかというと対運営を中心とした意見なのになぜ声優が悲しむことになるのか意味が分からない。むしろお前らが批判ツイートをみて中傷した感情を声優に置き換えているだけでは？
MCに関しても正直何も言われたところで考えを改めるつもりはない。今回の福岡ライブで「11人でLiella!です」と伊達氏は話したそうだが11人である事実を再認識するとしても5人原理主義の考えを改めるきっかけにはならない。擁護や反対の主張をするにあたって声優を盾にする行為はそれこそ声優方に対して失礼ではないだろうか。万一声優方から似たような声明があったとしても、声優に対しての批判ではないのでそれで発言を控えようとは思わないが。
繰り返すが、筆者は作品の在り方を問われるようなセールスを行っている運営らを対象に批判しているので声優個人個人の批判は一言も発していない。むしろ筆者の中で声優方の評価は高い方なので尚更批判する箇所が皆無に等しい。故に、運営を批判する＝声優が悲しむという流れは全く理解ができないので擁護派が言うキャストが悲しむからやめろという問いかけには一切応じない。もし仮に本当だとしてもそれは大変申し訳ないが声優方の解釈や考え方に問題があるとしか言い様がない。つまり自分自身の問題なので筆者を含め上記のような批判発言をしている方々に責任はない。むしろ、勝手に自分のことを言っていると解釈違いされた人達が不憫だ。ハッキリ言ってしまえば、悲しむなら勝手に悲しんでくれ。
こんなことをいうとそれでもファンか？と思い始める人が出てくると思うので予め言っておくが筆者はもうLiella!から離れている。1stライブ以降9人での姿を見たのは2023年のブシロックが初であり11人は異次元フェスが初。もう単独に行こうとする気力すら起こらない。ただ応援しているコンテンツを提供する会社の運営や営業方針を肯定するイエスマンになることがファンであるという考えを持っているリエライバーは今すぐその考えを捨てるべきだ。だから全肯定だの脳死オタクだの散々バカにされる。バカにされてムカつくというツイートも見たがそういうイエスマンたちは反対派の意見をしっかり読み理解しているのだろうか。筆者からすれば全くそうは見えないのでめちゃくちゃバカにしている。
ではLiella!から離れたのになぜLiella!を批判するのか？それはたまたま目に入ったからにすぎない。テレビをつけたら酷いプレーをするテニスの選手をボロクソに叩くことに近い。荷物を頼んでいて時間通りに来なかった時に「なんで遅いんだ、もっと早く来れるだろ」と吐くことに近い。金を払っていようがいまいが批判する権利というのは誰にでも存在する。だからこそ「在宅お気持ちはありえない」という主張に筆者は賛同しない。自分が行った現場で似たような在宅お気持ちを見ても筆者はそれに対して金を払ってないくせに文句を言うなという気持ちにもならない。
今回の炎上で筆者を始めとした5人主義を批判している現リエライバーはキャストとして応援している傾向があると感じた。だからこそキャストが悲しむようなことを言うなとかって出てくるんだろうけど。
また上記の主張を含め、5人で歌うことの意味を自問自答している人はいなく9人或いは11人として評価しているリエライバーが大半であった。筆者のような5人原理主義者を「過去に捕われている人」として嘲笑しているリエライバーもいた。要するに筆者ら5人原理主義の主張に同意ないし尊重するリエライバーは極小数であった。もちろん筆者は過去に捕われている。このLiella!に関してはずっと過去に拘っている。ただ過去に囚われている事が間違いだと主張するのであればそれは違う。
他のアニメ作品でいうと、イナズマイレブンがそれにあたる。前者アレスの天秤、オリオンの刻印は過去作イナイレを凌駕できず散々の言われようであった(ここら辺はアニメ2期を批評するブログにも記載していたので詳細は省略)。その2作品に対しての感想の大半は「前の方が良かった」と。
今のLiella!もといスーパースター！！はイナイレと近い道を辿っている。余程のことがない限り"今"が前より酷ければ人は"前"を好む。イナイレもそうだしスパスタ！！もそうだし。それは見た当時に受けた"良かったという感情"を同じ作品の続きて壊されたからだ。筆者はその余程という部分に捕われて過去にしがみついている。だからあの頃の自分の好きだった5人は9人、11人となり5人で歌う姿はもう見られないという現実を受け入れても筆者の中では5人のLiella!が1番最高だ。
Liella!5th福岡ライブにおいて、Starlight Prologを始めとしたアニメ1期曲の11人披露で再び1期生5人原理主義者と現行Liella!推しラブライバー(以下リエライバーと称す)が議論する炎上が起こった。
筆者はラブライブ！スーパースター！！を視聴し、その感動に浸り、1stライブまで見に行き2期生が来ると知ってLiella!を去った5人原理主義の1人だ。アニメは一応2期も視聴済だが、到底話したくない内容だ。もちろん今回のセトリにはいろいろ思うところがある。ただ、今回の炎上で5人原理主義者を叩くリエライバーの内容を見るとあまりにも屁理屈が多くて頭を抱えてしまったところではある。なので代表面をする訳では無いが、5人原理主義者は何も考え無しに批判している訳ではないと伝えるため、今回はてな匿名ダイアリーを利用し1人の原理主義者としての考え、主観をここに記すことにした。匿名にした理由は筆者個人の都合及び(筆者の仲良い人との)トラブル防止としていることをご理解いただきたい。
まず始めに筆者は全てのラブライブ！シリーズをアニメを主体として評価、或いは批判している。それはアニメ自体もそうだがライブでも同様に鑑賞している。今回話すことの大半はアニメを主題としていることを理解いただきたい。また原理主義者であると記したが、11人でLiella!という現状は概ね理解している。なので5人でLiella!という絶対的な主観までは持ち合わせていないことを伝えておく。しかし筆者の中での最高傑作はもちろんアニメ1期であり、5人のLiella!を原点として考えている。逆に現行の9人、11人体制発表には酷く幻滅した。結局私が見たアニメ1期は何だったのかと。5人でもラブライブ！という証明がアニメをもって発表されたにも関わらず結局人を増やしますと言われて「そうなんですね！続きも期待してます！」にはならない。筆者は「5人で物語が続く」と思っていたから。ただ決まってしまったものは仕方ないので、せめてアニメ2期や次回ライブで1期の曲は5人でこそ...と思った結果があのザマである。雑なシナリオ、不憫なキャラの描かれ方、アニメ1期で得た感動を全て雑にして返されたようなものだ。そして挙句の果てにはその都度行われた9人ライブでかつて披露された5人の曲を歌い始めたのだ。ここら辺については語ると物凄く長くなってしまうので省略するが。
せめて、1期公開前に最終的にLiella!は11人になりますという示唆があればそれを受け入れて1期を見れただろう。もちろん1期最終話のラブライブ！敗北の味が薄くなってはしまうが、次が来るということの心の準備はできていた。その示唆さえなくあの神作品ができてしまえば、5人でLiella!という価値観として結ばれるしあとから人増やしますねと言われても納得が行くわけが無い。最初から言ってほしかった。要するに、私が見たアニメ1期を返してほしい、続けていくのであればアニメ1期のストーリーや曲の思い出を大切にしてほしいというのが筆者なりの原理主義に基づく考えだ。
さて、筆者個人の考えはここまでとし本題の炎上の方に入る。単刀直入に言えば、現リエライバーの擁護があまりにも屁理屈すぎて説得力に欠けていた。様々な意見を見たが、特に「虹ヶ咲は12人で歌ってるじゃん」「異次元フェスでスノハレアイマスが歌ったじゃん」「キャストが傷つく、キャストはMCでこう言っていたじゃないか」という主張を多く見受けた。それぞれの意見について筆者の見解は下記の通りだ。
・虹ヶ咲は12人で歌ってるじゃん→アニメ1期の曲は12人で歌ってないけど？
虹ヶ咲1期で披露されたアニメ曲はソロを除きOPの虹色Passions!、EDのNEO SKY NEO MAP、13話披露曲の夢がここからはじまるよの3曲になるがどれも9人でないし当時のメンバー及び9人で歌っている(後述するが異次元フェスは例外とする)。R3BIRTHの3人は上記3曲を1度も歌っていないしまして初披露となる4th大阪1日目で虹パが披露された時はちゃんと9人(楠木ともりは病のため不登壇だったが)で歌った。アニメを主体として批判しているので前期曲を歌っていないR3BIRTH3人組を含めた12人の虹ヶ咲と、前期曲を歌った11人のLiella!では引き合いに出せない。まあそもそも虹ヶ咲がラブライブ！とは似て非なる番外編ということを割り切っているからというのもあるが。
・異次元フェスでスノハレアイマス歌ったじゃん→スパスタ！！のアニメを主体にした批判で他コンテンツを引き合いに出す脳みそを持つ人間がラブライブ！コンテンツにいることに戦慄している。異次元フェスはアイドルマスターとの「コンテンツ間におけるコラボレーション」としてのライブなのでアニメを主軸として鑑賞はしなかった。それこそアイマスキャラ含めた虹色Passions!、私のsymphonyをやったが原理主義の感情が出てくるほど嫌とは感じなかった。
・キャストが悲しむ、キャストのMCを聞かなかったのか→筆者が1番この意見に苛立ちを覚えた。そもそも声優のことについて批判していないしどちらかというと対運営を中心とした意見なのになぜ声優が悲しむことになるのか意味が分からない。むしろお前らが批判ツイートをみて中傷した感情を声優に置き換えているだけでは？
MCに関しても正直何も言われたところで考えを改めるつもりはない。今回の福岡ライブで「11人でLiella!です」と伊達氏は話したそうだが11人である事実を再認識するとしても5人原理主義の考えを改めるきっかけにはならない。擁護や反対の主張をするにあたって声優を盾にする行為はそれこそ声優方に対して失礼ではないだろうか。万一声優方から似たような声明があったとしても、声優に対しての批判ではないのでそれで発言を控えようとは思わないが。
繰り返すが、筆者は作品の在り方を問われるようなセールスを行っている運営らを対象に批判しているので声優個人個人の批判は一言も発していない。むしろ筆者の中で声優方の評価は高い方なので尚更批判する箇所が皆無に等しい。故に、運営を批判する＝声優が悲しむという流れは全く理解ができないので擁護派が言うキャストが悲しむからやめろという問いかけには一切応じない。もし仮に本当だとしてもそれは大変申し訳ないが声優方の解釈や考え方に問題があるとしか言い様がない。つまり自分自身の問題なので筆者を含め上記のような批判発言をしている方々に責任はない。むしろ、勝手に自分のことを言っていると解釈違いされた人達が不憫だ。ハッキリ言ってしまえば、悲しむなら勝手に悲しんでくれ。
こんなことをいうとそれでもファンか？と思い始める人が出てくると思うので予め言っておくが筆者はもうLiella!から離れている。1stライブ以降9人での姿を見たのは2023年のブシロックが初であり11人は異次元フェスが初。もう単独に行こうとする気力すら起こらない。ただ応援しているコンテンツを提供する会社の運営や営業方針を肯定するイエスマンになることがファンであるという考えを持っているリエライバーは今すぐその考えを捨てるべきだ。だから全肯定だの脳死オタクだの散々バカにされる。バカにされてムカつくというツイートも見たがそういうイエスマンたちは反対派の意見をしっかり読み理解しているのだろうか。筆者からすれば全くそうは見えないのでめちゃくちゃバカにしている。
ではLiella!から離れたのになぜLiella!を批判するのか？それはたまたま目に入ったからにすぎない。テレビをつけたら酷いプレーをするテニスの選手をボロクソに叩くことに近い。荷物を頼んでいて時間通りに来なかった時に「なんで遅いんだ、もっと早く来れるだろ」と吐くことに近い。金を払っていようがいまいが批判する権利というのは誰にでも存在する。だからこそ「在宅お気持ちはありえない」という主張に筆者は賛同しない。自分が行った現場で似たような在宅お気持ちを見ても筆者はそれに対して金を払ってないくせに文句を言うなという気持ちにもならない。
今回の炎上で筆者を始めとした5人主義を批判している現リエライバーはキャストとして応援している傾向があると感じた。だからこそキャストが悲しむようなことを言うなとかって出てくるんだろうけど。
また上記の主張を含め、5人で歌うことの意味を自問自答している人はいなく9人或いは11人として評価しているリエライバーが大半であった。筆者のような5人原理主義者を「過去に捕われている人」として嘲笑しているリエライバーもいた。要するに筆者ら5人原理主義の主張に同意ないし尊重するリエライバーは極小数であった。もちろん筆者は過去に捕われている。このLiella!に関してはずっと過去に拘っている。ただ過去に囚われている事が間違いだと主張するのであればそれは違う。
他のアニメ作品でいうと、イナズマイレブンがそれにあたる。前者アレスの天秤、オリオンの刻印は過去作イナイレを凌駕できず散々の言われようであった(ここら辺はアニメ2期を批評するブログにも記載していたので詳細は省略)。その2作品に対しての感想の大半は「前の方が良かった」と。
今のLiella!もといスーパースター！！はイナイレと近い道を辿っている。余程のことがない限り"今"が前より酷ければ人は"前"を好む。イナイレもそうだしスパスタ！！もそうだし。それは見た当時に受けた"良かったという感情"を同じ作品の続きて壊されたからだ。筆者はその余程という部分に捕われて過去にしがみついている。だからあの頃の自分の好きだった5人は9人、11人となり5人で歌う姿はもう見られないという現実を受け入れても筆者の中では5人のLiella!が1番最高だ。
やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ。
話し合い、耳を傾け、承認し、任せてやらねば、人は育たず。
やっている、姿を感謝で見守って、信頼せねば、人は実らず。
まずは、あなた自身がプログラマーになって、見本を見せることが第１歩です。
その後受託系の会社に就職できたのだけど、人間関係がうまくいかなかったようで数ヶ月で辞めた。
鬱病気味になったみたい...。
どうやら、プログラミングという仕事の特徴について、あなたは理解していないようですね？
プログラミングの特徴は、「コンピューターが相手なので、嘘やハッタリが一切通用しない」ということです。
人間相手なら、適当に指示を出したり、いい加減な対応でも何とかなるけど、コンピューター相手だと1mmも融通が利きません。
という3点が必要です。
警察に職務質問されて有名になった江添亮さんのブログ等を読んで、この方のようにネチネチと論理をこねくり回すのが好きなら、プログラマーに向いています。
(例)本の虫: 麻布十番で職務質問を受けた話 https://cpplover.blogspot.jp/2017/08/blog-post.html
プログラムというのは、小さな部品を組み合わせて、大きなシステムが作られています。
小さな部品がパズルのピースに相当して、大きなシステムがパズルの完成品です。
つまり、大きな問題を小さな問題に分解して、１つずつ順番に問題をつぶして行く姿勢が必要です。
があります。
命令型のプログラミング言語しか使えない人がプログラマーになると、テスト地獄に陥って、結果的に鬱病を発症しやすくなるだろうと危惧しています。
上述のように、パズルのピースを組み合わせてプログラムを作るには、「関数型」の作法を身に付けておくと良いでしょう。
関数型プログラミングを習得するために、今なら「Haskell」または「OCaml」というプログラミング言語をお勧めします。
HaskellやOCamlは、良い参考書がたくさんあるので、本屋に行って実物を確かめてください。
Haskellを学んでみて、パズルのピースを組み合わせる感覚が理解できたら、あなたはテスト地獄に苦しめられないプログラマーになれるでしょう。
もしも、Haskellが理解できないようだったら、残念ですがプログラマーには向いていないかもしれません。
（例外的に、あなたがマゾで、テスト地獄や残業、徹夜が楽しいと思える性格なら、Haskellが理解できなくても大丈夫かもしれません。）
Haskellの教材（英語）を紹介するので、参考までに読んでみてください。
http://learnyouahaskell.com/chapters
（このサイトの内容は、日本語の書籍「すごいHaskellたのしく学ぼう！」として出版されています。）
Haskellは、順番に学べば必ず理解できるようになっています。
もしも、Haskellが習得できなければ、大きな問題を小さな問題に分解して解決していく作業には不向きな性格かもしれないので、他の仕事も検討してはいかがでしょうか？
（人生は一度きり。時間の無駄にならないようにお気を付けください。）
あなたと友人が、無事Haskellを習得して、テスト地獄を乗り超えるスーパーハッカーになり、日本のIT産業を牽引されることに期待いたします。
（追記）
自分が作りたいプログラムすら作れない人が、他人が希望するプログラムを作るなんてできっこないからねｗ
（プログラマーが楽で簡単な仕事だと思ったら大間違いですよ？）
（追記 その２）
関数型プログラミングをマスターしておけば、OOPでも役に立つよ。（現実には、関数型もOOPも必要に応じて投入するし）
iOS→「プロトコル指向プログラミング」「RxSwift」、Android→「RxJava」辺りのキーワードでググってみて。
別に皮肉とか宗教戦争で煽ってるわけじゃなくて、自分も苦労して辿りついた口だから、今から始める人には遠回りして、余計な苦労を味わって欲しくない。
（追記 その３）
他の人が書いてたけど、１人でプログラミングするんじゃなくて、２人（ペアプログラミング）や３人以上（モブプログラミング）から始めたら良いかも。
Googleの「プロジェクト・アリストテレス」で、仕事の生産性を改善するには「心理的安全性」が重要と分かり、プログラミングの仕事もやり方が変わって来ています。
https://kuranuki.sonicgarden.jp/2017/01/psychological-safety.html
（追記 その４）
元記事が消えていたのでバックアップしておきます。（この投稿だけ読むと意味が分からなくなるため）
https://anond.hatelabo.jp/20170910205249
2017-09-10
■知り合いをプログラマにさせたいんだけど知恵を貸してくれ
プログラマって育休からの復帰しやすいだろうし、アルバイトよりは待遇いいし、勤怠ゆるいし、労力の割に楽ちんだと思うんだよね。
接客のバイトで消耗するくらいなら、プログラマになればいいと思っているのだが、その知り合いは自身のことをプログラミングを不向きと評価しているらしい。私は、プログラミングに限らず物事は時間をかければ習熟していくものだと思っているので、不向きではないと思うんだ。不向きというのは物理的に制限のある時だと思う。
その知り合いについて。
Vimはぎこちないけど使える。日常的にmacOSを使っていてターミナルの操作はできている。cd, ls あたりは理解している。
趣味を含めてアプリケーションを完成させた経験はないが、ifやfor文などの基本構文は理解している。数年前にプログラミングスクールのようなところに半年間通っていた。その後受託系の会社に就職できたのだけど、人間関係がうまくいかなかったようで数ヶ月で辞めた。鬱病気味になったみたい...。
何か成功体験があれば自然とのめり込んでと思うんだけどなかなかスイッチが入っていないみたい。
こちら側からは、プログラマーになれば？と直接は伝えてはなくて、素人でもプログラミングできましたみたいなネットの記事をシェアーしているくらい。(心理的リアクタンス避け)
知恵を貸して欲しい。
ちょっとよくわからないんだが、LispにしろPrologにしろ199X年代には少なくとも大学で授業として教えるような”古典”だったわけだが
2005年だったか、2006年だったかに出版の話があったようでその後2007年に発売されたわけだが、当時Lispの情報ってあんまりなくて、翻訳苦労してるみたいなことをはてダに書いていた（ような気がする）。
すくなくともLISPの情報が少ないということはなかったと思うぞ。
Perlが198X年代だがLISPは195X年代で、超がつくほどの古典言語で、日本語でも山ほど文献があるはずなんだが、最近は進化していないので、ネット上に文献があるか？という話では難しいが、古い図書館に行けば古い本がいっぱいあるだろ。
第1章 プログラミング概念入門 1.1 計算器 1.2 変数 1.3 関数 1.4 リスト 1.5 リストについての関数 1.6 プログラムの正しさ 1.7 計算量 1.8 遅延計算 1.9 高階プログラミング 1.10 並列性 1.11 データフロー 1.12 明示的状態 1.13 オブジェクト 1.14 クラス 1.15 非決定性と時間 1.16 原子性 1.17 ここからどこへ行くのか？ 1.18 練習問題 第1部 一般的計算モデル 第2章 宣言的計算モデル 2.1 実用的プログラミング言語の定義 2.1.1 言語の構文 2.1.2 言語の意味 2.2 単一代入格納域 2.2.1 宣言的変数 2.2.2 値格納域 2.2.3 値生成 2.2.4 変数識別子 2.2.5 識別子を使う値生成 2.2.6 部分値 2.2.7 変数の，変数への束縛 2.2.8 データフロー変数 2.3 核言語 2.3.1 構文 2.3.2 値と型 2.3.3 基本型 2.3.4 レコードと手続き 2.3.5 基本操作 2.4 核言語の意味 2.4.1 基本概念 2.4.2 抽象マシン 2.4.3 待機不能な文 2.4.4 待機可能な文 2.4.5 基本概念再訪 2.5 メモリ管理 2.5.1 末尾呼び出し最適化 2.5.2 メモリライフサイクル 2.5.3 ガーベッジコレクション 2.5.4 ガーベッジコレクションは魔術ではない 2.5.5 Mozartのガーベッジコレクタ 2.6 核言語から実用的言語へ 2.6.1 構文上の便宜 2.6.2 関数(fun文) 2.6.3 対話的インターフェース(declare文) 2.7 例外 2.7.1 動機と基本概念 2.7.2 例外を持つ宣言的モデル 2.7.3 親言語の構文 2.7.4 システム例外 2.8 進んだ話題 2.8.1 関数型プログラミング言語 2.8.2 単一化と内含(entailment) 2.8.3 動的型付けと静的型付け 2.9 練習問題 第3章 宣言的プログラミング技法 3.1 宣言的とはどういうことか？ 3.1.1 宣言的プログラムの分類 3.1.2 仕様記述言語 3.1.3 宣言的モデルにおいてコンポーネントを実装すること 3.2 反復計算 3.2.1 一般的図式 3.2.2 数についての反復 3.2.3 局所的手続きを使うこと 3.2.4 一般的図式から制御抽象へ 3.3 再帰計算 3.3.1 スタックの大きさの増加 3.3.2 代入ベースの抽象マシン 3.3.3 再帰計算を反復計算に変換すること 3.4 再帰を用いるプログラミング 3.4.1 型の記法 3.4.2 リストについてのプログラミング 3.4.3 アキュムレータ 3.4.4 差分リスト 3.4.5 キュー 3.4.6 木 3.4.7 木を描画すること 3.4.8 構文解析 3.5 時間効率と空間効率 3.5.1 実行時間 3.5.2 メモリ使用量 3.5.3 償却的計算量 3.5.4 性能についての考察 3.6 高階プログラミング 3.6.1 基本操作 3.6.2 ループ抽象 3.6.3 ループの言語的支援 3.6.4 データ駆動技法 3.6.5 明示的遅延計算 3.6.6 カリー化 3.7 抽象データ型 3.7.1 宣言的スタック 3.7.2 宣言的辞書 3.7.3 単語出現頻度アプリケーション 3.7.4 安全な抽象データ型 3.7.5 安全な型を備えた宣言的モデル 3.7.6 安全な宣言的辞書 3.7.7 資格とセキュリティ 3.8 宣言的でない必要物 3.8.1 ファイルを伴うテキスト入出力 3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力 3.8.3 ファイルとの状態なしデータI/O 3.9 小規模プログラム設計 3.9.1 設計方法 3.9.2 プログラム設計の例 3.9.3 ソフトウェアコンポーネント 3.9.4 スタンドアロンプログラムの例 3.10 練習問題 第4章 宣言的並列性 4.1 データ駆動並列モデル 4.1.1 基本概念 4.1.2 スレッドの意味 4.1.3 実行列 4.1.4 宣言的並列性とは何か？ 4.2 スレッドプログラミングの基本的技法 4.2.1 スレッドを生成すること 4.2.2 スレッドとブラウザ 4.2.3 スレッドを使うデータフロー計算 4.2.4 スレッドのスケジューリング 4.2.5 協調的並列性と競合的並列性 4.2.6 スレッド操作 4.3 ストリーム 4.3.1 基本的生産者／消費者 4.3.2 変換器とパイプライン 4.3.3 資源を管理し，処理能力を改善すること 4.3.4 ストリームオブジェクト 4.3.5 ディジタル論理のシミュレーション 4.4 宣言的並列モデルを直接使うこと 4.4.1 順序決定並列性 4.4.2 コルーチン 4.4.3 並列的合成 4.5 遅延実行 4.5.1 要求駆動並列モデル 4.5.2 宣言的計算モデル 4.5.3 遅延ストリーム 4.5.4 有界バッファ 4.5.5 ファイルを遅延的に読み込むこと 4.5.6 ハミング問題 4.5.7 遅延リスト操作 4.5.8 永続的キューとアルゴリズム設計 4.5.9 リスト内包表記 4.6 甘いリアルタイムプログラミング 4.6.1 基本操作 4.6.2 ティッキング(ticking) 4.7 Haskell言語 4.7.1 計算モデル 4.7.2 遅延計算 4.7.3 カリー化 4.7.4 多態型 4.7.5 型クラス 4.8 宣言的プログラムの限界と拡張 4.8.1 効率性 4.8.2 モジュラ性 4.8.3 非決定性 4.8.4 現実世界 4.8.5 正しいモデルを選ぶこと 4.8.6 拡張されたモデル 4.8.7 異なるモデルを一緒に使うこと 4.9 進んだ話題 4.9.1 例外を持つ宣言的並列モデル 4.9.2 さらに遅延実行について 4.9.3 通信チャンネルとしてのデータフロー変数 4.9.4 さらに同期について 4.9.5 データフロー変数の有用性 4.10 歴史に関する注記 4.11 練習問題 第5章 メッセージ伝達並列性 5.1 メッセージ伝達並列モデル 5.1.1 ポート 5.1.2 ポートの意味 5.2 ポートオブジェクト 5.2.1 NewPortObject抽象 5.2.2 例 5.2.3 ポートオブジェクトに関する議論 5.3 簡単なメッセージプロトコル 5.3.1 RMI(遠隔メソッド起動) 5.3.2 非同期RMI 5.3.3 コールバックのあるRMI(スレッド使用) 5.3.4 コールバックのあるRMI(継続のためのレコード使用) 5.3.5 コールバックのあるRMI(継続のための手続き使用) 5.3.6 エラー報告 5.3.7 コールバックのある非同期RMI 5.3.8 二重コールバック 5.4 並列性のためのプログラム設計 5.4.1 並列コンポーネントを使うプログラミング 5.4.2 設計方法 5.4.3 並列性パターンとしての機能的構成要素 5.5 リフト制御システム 5.5.1 状態遷移図 5.5.2 実装 5.5.3 リフト制御システムの改良 5.6 メソッド伝達モデルを直接使用すること 5.6.1 1つのスレッドを共有する複数のポートオブジェクト 5.6.2 ポートを使う並列キュー 5.6.3 終点検出を行うスレッド抽象 5.6.4 直列依存関係の除去 5.7 Erlang言語 5.7.1 計算モデル 5.7.2 Erlangプログラミング入門 5.7.3 receive操作 5.8 進んだ話題 5.8.1 非決定性並列モデル 5.9 練習問題 第6章 明示的状態 6.1 状態とは何か？ 6.1.1 暗黙的(宣言的)状態 6.1.2 明示的状態 6.2 状態とシステム構築 6.2.1 システムの性質 6.2.2 コンポーネントベースプログラミング 6.2.3 オブジェクト指向プログラミング 6.3 明示的状態を持つ宣言的モデル 6.3.1 セル 6.3.2 セルの意味 6.3.3 宣言的プログラミングとの関係 6.3.4 共有と同等 6.4 データ抽象 6.4.1 データ抽象を組織する8つの方法 6.4.2 スタックの変種 6.4.3 多態性 6.4.4 引数受け渡し 6.4.5 取り消し可能資格 6.5 状態ありコレクション 6.5.1 インデックス付きコレクション 6.5.2 インデックス付きコレクションを選ぶこと 6.5.3 その他のコレクション 6.6 状態に関する推論 6.6.1 不変表明 6.6.2 例 6.6.3 表明 6.6.4 証明規則 6.6.5 正常終了 6.7 大規模プログラムの設計 6.7.1 設計方法 6.7.2 階層的システム構造 6.7.3 保守性 6.7.4 将来の発展 6.7.5 さらに深く知るために 6.8 ケーススタディ 6.8.1 遷移的閉包 6.8.2 単語出現頻度(状態あり辞書を使用する) 6.8.3 乱数を生成すること 6.8.4 口コミシミュレーション 6.9 進んだ話題 6.9.1 状態ありプログラミングの限界 6.9.2 メモリ管理と外部参照 6.10 練習問題 第7章 オブジェクト指向プログラミング 7.1 継承 7.2 完全なデータ抽象としてのクラス 7.2.1 例 7.2.2 この例の意味 7.2.3 クラスとオブジェクトを定義すること 7.2.4 クラスメンバ 7.2.5 属性を初期化すること 7.2.6 第1級メッセージ 7.2.7 第1級の属性 7.2.8 プログラミング技法 7.3 漸増的データ抽象としてのクラス 7.3.1 継承グラフ 7.3.2 メソッドアクセス制御(静的束縛と動的束縛) 7.3.3 カプセル化制御 7.3.4 転嫁と委任 7.3.5 内省 7.4 継承を使うプログラミング 7.4.1 継承の正しい使い方 7.4.2 型に従って階層を構成すること 7.4.3 汎用クラス 7.4.4 多重継承 7.4.5 多重継承に関するおおざっぱな指針 7.4.6 クラス図の目的 7.4.7 デザインパターン 7.5 他の計算モデルとの関係 7.5.1 オブジェクトベースプログラミングとコンポーネントベースプログラミング 7.5.2 高階プログラミング 7.5.3 関数分解と型分解 7.5.4 すべてをオブジェクトにすべきか？ 7.6 オブジェクトシステムを実装すること 7.6.1 抽象図 7.6.2 クラスを実装すること 7.6.3 オブジェクトの実装 7.6.4 継承の実装 7.7 Java言語(直列部分) 7.7.1 計算モデル 7.7.2 Javaプログラミング入門 7.8 能動的オブジェクト 7.8.1 例 7.8.2 NewActive抽象 7.8.3 フラウィウス・ヨセフスの問題 7.8.4 その他の能動的オブジェクト抽象 7.8.5 能動的オブジェクトを使うイベントマネージャ 7.9 練習問題 第8章 状態共有並列性 8.1 状態共有並列モデル 8.2 並列性を持つプログラミング 8.2.1 さまざまな手法の概観 8.2.2 状態共有並列モデルを直接使うこと 8.2.3 原子的アクションを使うプログラミング 8.2.4 さらに読むべき本 8.3 ロック 8.3.1 状態あり並列データ抽象を構築すること 8.3.2 タプル空間(Linda) 8.3.3 ロックを実装すること 8.4 モニタ 8.4.1 定義 8.4.2 有界バッファ 8.4.3 モニタを使うプログラミング 8.4.4 モニタを実装すること 8.4.5 モニタの別の意味 8.5 トランザクション 8.5.1 並列性制御 8.5.2 簡易トランザクションマネージャ 8.5.3 セルについてのトランザクション 8.5.4 セルについてのトランザクションを実装すること 8.5.5 トランザクションについてさらに 8.6 Java言語(並列部分) 8.6.1 ロック 8.6.2 モニタ 8.7 練習問題 第9章 関係プログラミング 9.1 関係計算モデル 9.1.1 choice文とfail文 9.1.2 探索木 9.1.3 カプセル化された 9.1.4 Solve関数 9.2 別の例 9.2.1 数値例 9.2.2 パズルとnクイーン問題 9.3 論理型プログラミングとの関係 9.3.1 論理と論理型プログラミング 9.3.2 操作的意味と論理的意味 9.3.3 非決定性論理型プログラミング 9.3.4 純粋Prologとの関係 9.3.5 他のモデルにおける論理型プログラミング 9.4 自然言語構文解析 9.4.1 簡単な文法 9.4.2 この文法に従う構文解析 9.4.3 構文木を生成すること 9.4.4 限定記号を生成すること 9.4.5 パーサを走らせること 9.4.6 パーサを「逆向きに(backward)」走らせること 9.4.7 単一化文法 9.5 文法インタプリタ 9.5.1 簡単な文法 9.5.2 文法のコード化 9.5.3 文法インタプリタを走らせること 9.5.4 文法インタプリタを実装すること 9.6 データベース 9.6.1 関係を定義すること 9.6.2 関係を使って計算すること 9.6.3 関係を実装すること 9.7 Prolog言語 9.7.1 計算モデル 9.7.2 Prologプログラミング入門 9.7.3 Prologプログラムを関係プログラムに翻訳すること 9.8 練習問題 第2部 特殊化された計算モデル 第10章 グラフィカルユーザインタフェースプログラミング 10.1 宣言的／手続き的方法 10.2 宣言的／手続き的方法を使うこと 10.2.1 基本的ユーザインタフェースの要素 10.2.2 GUIを構築すること 10.2.3 宣言的座標 10.2.4 リサイズ時の宣言的振る舞い 10.2.5 ウィジェットの動的振る舞い 10.3 対話的学習ツールPrototyper 10.4 ケーススタディ 10.4.1 簡単なプログレスモニタ 10.4.2 簡単なカレンダウィジェット 10.4.3 ユーザインタフェースの動的生成 10.4.4 状況順応時計 10.5 GUIツールを実装すること 10.6 練習問題 第11章 分散プログラミング 11.1 分散システムの分類 11.2 分散モデル 11.3 宣言的データの分散 11.3.1 オープン分散と大域的ネーミング 11.3.2 宣言的データを共有すること 11.3.3 チケット配布 11.3.4 ストリーム通信 11.4 状態の分散 11.4.1 単純状態共有 11.4.2 分散字句的スコープ 11.5 ネットワークアウェアネス 11.6 共通分散プログラミングパターン 11.6.1 静的オブジェクトとモバイルオブジェクト 11.6.2 非同期的オブジェクトとデータフロー 11.6.3 サーバ 11.6.4 クローズド分散 11.7 分散プロトコル 11.7.1 言語実体 11.7.2 モバイル状態プロトコル 11.7.3 分散束縛プロトコル 11.7.4 メモリ管理 11.8 部分的失敗 11.8.1 失敗モデル 11.8.2 失敗処理の簡単な場合 11.8.3 回復可能サーバ 11.8.4 アクティブフォールトトレランス 11.9 セキュリティ 11.10 アプリケーションを構築すること 11.10.1 まずは集中，後に分散 11.10.2 部分的失敗に対処すること 11.10.3 分散コンポーネント 11.11 練習問題 第12章 制約プログラミング 12.1 伝播・探索法 12.1.1 基本的考え方 12.1.2 部分情報を使って計算すること 12.1.3 例 12.1.4 この例を実行すること 12.1.5 まとめ 12.2 プログラミング技法 12.2.1 覆面算 12.2.2 回文積再訪 12.3 制約ベース計算モデル 12.3.1 基本的制約と伝播子 12.3.2 計算空間の探索をプログラムすること 12.4 計算空間を定義し，使うこと 12.4.1 深さ優先探索エンジン 12.4.2 検索エンジンの実行例 12.4.3 計算空間の生成 12.4.4 空間の実行 12.4.5 制約の登録 12.4.6 並列的伝播 12.4.7 分配(探索準備) 12.4.8 空間の状態 12.4.9 空間のクローン 12.4.10 選択肢を先に任せること 12.4.11 空間をマージすること 12.4.12 空間失敗 12.4.13 空間に計算を注入すること 12.5 関係計算モデルを実装すること 12.5.1 choice文 12.5.2 Solve関数 12.6 練習問題 第3部 意味 第13章 言語意味 13.1 一般的計算モデル 13.1.1 格納域 13.1.2 単一代入(制約)格納域 13.1.3 抽象構文 13.1.4 構造的規則 13.1.5 直列実行と並列実行 13.1.6 抽象マシンの意味との比較 13.1.7 変数導入 13.1.8 同等性の強制(tell) 13.1.9 条件文(ask) 13.1.10 名前 13.1.11 手続き抽象 13.1.12 明示的状態 13.1.13 by-need同期 13.1.14 読み出し専用変数 13.1.15 例外処理 13.1.16 失敗値 13.1.17 変数置き換え 13.2 宣言的並列性 13.2.1 部分停止と全体停止 13.2.2 論理的同値 13.2.3 宣言的並列性の形式的定義 13.2.4 合流性 13.3 8つの計算モデル 13.4 よくある抽象の意味 13.5 歴史に関する注記 13.6 練習問題
第1章 プログラム変換入門 佐藤泰介 1.1 今なぜプログラム変換か？ 1.2 変換あれこれ 1.3 システム化について 第2章 等式プログラムの等価変換 二木厚吉 2.1 等価変換例 2.2 等価性 2.3 等価変換法 2.4 おわりに 第3章 論理型言語におけるプログラム変換 玉木久夫 3.1 はじめに 3.2 論理プログラムとその意味論 3.3 展開/たたみ込み変換：例題 3.4 展開/たたみ込み変換の正当性 3.5 他の変換との両立性 3.6 おわりに 第4章 部分計算 二村良彦 4.1 はじめに 4.2 部分計算の概要 4.3 部分計算の応用例 4.4 部分計算の理論 4.5 実用化のための課題 第5章 メタ・プログラミングと部分計算 竹内彰一 5.1 はじめに 5.2 Prologプログラムの部分計算 5.3 メタ・プログラミングへの応用 5.4 メタ・インタプリタの段階的特殊化 5.5 おわりに 第6章 合成問題への新しいアプローチ 佐藤泰介 6.1 否定技法 6.2 二重否定技法 6.3 論理プログラムの合成 第7章 ベクトル化とプログラム変換 安村通晃 7.1 はじめに 7.2 プログラム変換 7.3 ベクトル化 7.4 主要変換 7.5 基軸変換 7.6 その他の変換 7.7 ベクトル化におけるプログラム変換の特徴 7.8 おわりに 第8章 GHCでのプログラム変換 吉川康一 8.1 はじめに 8.2 簡単な問題 8.3 フィルタ・プロセスの融合 8.4 プログラム変換の手順 8.5 電子回路シミュレータへの応用 8.6 おわりに 第9章 実用規模プログラムの変換試行事例 吉田紀彦 9.1 はじめに 9.2 コンパイラの変換 9.3 プログラム変換の実用可能性 9.4 おわりに
第1章 並行プログラミングとGHC (上田和紀) 1.1 はじめに 1.2 ターゲットを明確にしよう 1.3 はじめが大切 1.4 GHCが与える並行計算の枠組み 1.4.1 GHCにおける計算とは，外界との情報のやりとり(通信)である 1.4.2 計算を行う主体は，互いに，および外界と通信し合うプロセスの集まりである 1.4.3 プロセスは，停止するとは限らない 1.4.4 プロセスは，開いた系(open system)をモデル化する 1.4.5 情報とは変数と値との結付き(結合)のことである 1.4.6 プロセスは，結合の観測と生成を行う 1.4.7 プロセスは，書換え規則を用いて定義する 1.4.8 通信は，プロセス間の共有変数を用いて行う 1.4.9 外貨も，プロセスとしてモデル化される 1.4.10 通信は，非同期的である 1.4.11 プロセスのふるまいは，非決定的でありうる 1.5 もう少し具体的なパラダイム 1.5.1 ストリームと双方向通信 1.5.2 履歴のあるオブジェクトの表現 1.5.3 データ駆動計算と要求駆動計算 1.5.4 モジュラリティと差分プログラミング 1.5.5 プロセスによるデータ表現 1.6 歴史的背景と文献案内 1.7 並行プログラミングと効率 1.8 まとめ 第2章 様相論理とテンポラル・プログラミング (桜川貴司) 2.1 はじめに 2.2 様相論理 2.3 時制論理 2.4 多世界モデル 2.5 到達可能性と局所性 2.6 純論理プログラミングへ向けて 2.7 Temporal Prolog 2.8 RACCO 2.9 実現 2.10 まとめと参考文献案内 第3章 レコード・プログラミング (横田一正) 3.1 はじめに 3.2 レコードと述語の表現 3.3 レコード構造とφ-項 3.3.1 φ-項の定義 3.3.2 型の半順序と束 3.3.3 KBLとLOGIN 3.4 応用――データベースの視点から 3.4.1 演繹データベース 3.4.2 レコード・プログラミングとデータベース 3.4.3 いくつかの例 3.5 まとめ 3.6 文献案内 第4章 抽象データ型とOBJ2 (二木厚吉・中川 中) 4.1 はじめに 4.2 抽象データ型と代数型言語 4.2.1 抽象データ型 4.2.2 代数型言語 4.2.3 始代数 4.2.4 項代数 4.2.5 項書換えシステム 4.3 OBJ2 4.3.1 OBJ2の基本構造 4.3.2 モジュールの参照方法 4.3.3 混置関数記号 4.3.4 モジュールのパラメータ化 4.3.5 パラメータ化機構による高階関数の記述 4.3.6 順序ソート 4.3.7 属性つきパターンマッチング 4.3.8 評価戦略の指定 4.3.9 モジュール表現 4.4 おわりに 第5章 プログラム代数とFP (富樫 敦) 5.1 はじめに 5.2 プログラミング・システム FP 5.2.1 オブジェクト 5.2.2 基本関数 5.2.3 プログラム構成子 5.2.4 関数定義 5.2.5 FPのプログラミング・スタイル 5.3 プログラム代数 5.3.1 プログラム代数則 5.3.2 代数則の証明 5.3.3 代数則とプログラム 5.4 ラムダ計算の拡張 5.4.1 ラムダ式の拡張 5.4.2 拡張されたラムダ計算の簡約規則 5.4.3 そのほかのリスト操作用演算子 5.4.4 相互再帰的定義式 5.4.5 ストリーム(無限リスト)処理 5.5 FPプログラムの翻訳 5.5.1 オブジェクトの翻訳 5.5.2 基本関数の翻訳 5.5.3 プログラム構成子の翻訳 5.5.4 簡約規則を用いた代数則の検証 5.6 おわりに 第6章 カテゴリカル・プログラミング (横内寛文) 6.1 はじめに 6.2 値からモルフィズムへ 6.3 カテゴリカル・コンビネータ 6.3.1 ラムダ計算の意味論 6.3.2 モルフィズムによる意味論 6.3.3 カテゴリカル・コンビネータ理論CCL 6.4 関数型プログラミングへの応用 6.4.1 関数型プログラミング言語ML/O 6.4.2 CCLの拡張 6.4.3 CCLに基づいた処理系 6.4.4 公理系に基づいた最適化 6.5 まとめ 第7章 最大公約数――普遍代数，多項式イデアル，自動証明におけるユークリッドの互除法 (外山芳人) 7.1 はじめに 7.2 完備化アルゴリズム 7.2.1 グラス置換えパズル 7.2.2 リダクションシステム 7.2.3 完備なシステム 7.2.4 完備化 7.2.5 パズルの答 7.3 普遍代数における完備化アルゴリズム 7.3.1 群論の語の問題 7.3.2 群の公理の完備化 7.3.3 Knuth-Bendix完備化アルゴリズム 7.4 多項式イデアル理論における完備化アルゴリズム 7.4.1 ユークリッドの互除法 7.4.2 多項式イデアル 7.4.3 Buchbergerアルゴリズム 7.5 一階述語論理における完備化アルゴリズム 7.5.1 レゾリューション法 7.5.2 Hsiangのアイデア 7.6 おわりに 第8章 構成的プログラミング (林 晋) 8.1 構成的プログラミング？ 8.2 型付きラムダ計算 8.3 論理としての型付きラムダ計算 8.4 構成的プログラミングとは 8.5 構成的プログラミングにおける再帰呼び出し 8.6 おわりに：構成的プログラミングに未来はあるか？ 第9章 メタプログラミングとリフレクション (田中二郎) 9.1 はじめに 9.2 計算システム 9.2.1 因果結合システム 9.2.2 メタシステム 9.2.3 リフレクティブシステム 9.3 3-Lisp 9.4 リフレクティブタワー 9.5 GHCにおけるリフレクション 9.5.1 並列論理型言語GHC 9.5.2 GHCの言語仕様 9.5.3 GHCのメタインタプリタ 9.5.4 リフレクティブ述語のインプリメント 9.6 まとめ
第1章 新しいプログラミング・パラダイムをめぐって (井田哲雄) 1.1 はじめに 1.2 プログラミング・パラダイムの形成 1.3 プログラミング・パラダイムの展開 1.4 パラダイムと作法と構造化プログラミング 1.5 構造化プログラミングを超えて 1.6 関数型プログラミング，論理型プログラミング，対象指向プログラミング 1.7 新しいプログラミング・パラダイム 1.8 まとめ 第2章 ラムダ計算と高階プログラミング (横内寛文) 2.1 はじめに 2.2 ラムダ計算 2.3 最左戦略 2.4 コンビネータによる計算 2.5 まとめ 第3章 マルセイユProlog，Prolog Ⅱ，Prolog Ⅲ 3.1 はじめに 3.2 準備 3.2.1 述語 3.2.2 項 3.2.3 項の単一化 3.2.4 節およびHorn節 3.2.5 論理式の意味 3.2.6 論理的帰結と導出 3.3 マルセイユProlog 3.3.1 Prologの記法 3.3.2 Prologの計算規則 3.3.3 Prologプログラムの例 3.3.4 カット・オペレータ 3.3.5 DEC-10 Prologとの相違 3.4 Prolog Ⅱ 3.4.1 difオペレータ 3.4.2 freeze 3.4.3 ループ構造 3.4.4 Prolog Ⅱのインプリメンテーション 3.5 Prolog Ⅲ 3.5.1 制約の枠組 3.5.2 Prolog Ⅲのプログラム例 3.5.3 束縛の領域と制約系 3.5.4 Prolog Ⅲのインプリメンテーション 3.6 まとめ 第4章 制約論理型プログラム (相場 亮) 4.1 はじめに 4.2 制約プログラミング 4.3 制約の分類 4.4 プログラムの実行 4.5 制約の評価 4.6 まとめ 第5章 オブジェクト指向 (柴山悦哉) 5.1 はじめに 5.2 モジュラリティと抽象化 5.2.1 抽象化 5.2.2 手続き抽象 5.2.3 データ抽象 5.2.4 オブジェクトによる抽象化 5.2.5 並列オブジェクトによる抽象化 5.3 共有 5.3.1 多相型 5.3.2 継承 5.3.3 多重継承 5.3.4 Self 5.3.5 動的束縛の意義 5.4 対話性 5.4.1 クラスの再定義 5.4.2 表示機能の一体化 5.5 オブジェクト指向の弱点 5.6 まとめ 第6章 型推論とML (横田一正) 6.1 はじめに 6.2 LCFの超言語からMLへ 6.3 プログラミング言語と型 6.4 MLの表現と型宣言 6.5 MLの型推論 6.6 LCFへの応用 6.7 まとめ 第7章 Miranda (加藤和彦) 7.1 はじめに 7.2 Mirandaの概観 7.2.1 等式による定義 7.2.2 基本データ型と基本演算子 7.2.3 ガード付き等式とスコープ・ルール 7.2.4 高階関数とカリー化 7.2.5 パターン・マッチング 7.2.6 ノンストリクト性と遅延評価 7.2.7 ドット式とZF式 7.3 型 7.3.1 強い型付けと静的な型付け 7.3.2 多相型 7.3.3 型類義 7.3.4 代数データ型 7.3.5 抽象データ型 7.4 処理系 7.5 まとめ 7.6 文献の紹介 第8章 項書換えシステムと完備化手続き (大須賀昭彦) 8.1 はじめに 8.2 項書換えシステム 8.3 TRSの停止性 8.3.1 意味順序 8.3.2 構文順序 8.4 TRSの合流性 8.4.1 完備なTRS 8.4.2 危険対 8.4.3 危険対を用いたTRSの合流性判定 8.5 Knuth-Bendixの完備化手続き 8.6 KBの応用 8.6.1 帰納的な定理証明への応用 8.6.2 等号論理の定理証明への応用 8.7 まとめ 第9章 等式プログラミングから融合型プログラミングへ (富樫 敦) 9.1 はじめに 9.2 等式プログラミング 9.2.1 等式プログラム 9.2.2 代表的な等式プログラム 9.2.3 プログラミング技法 9.2.4 正則プログラムと正規化戦略 9.3 条件付き等式プログラム 9.3.1 条件付き書換え規則 9.3.2 条件の種類 9.3.3 利点と問題点 9.4 融合型プログラミング 9.4.1 AMLOGシステム 9.4.2 向付き等式 9.4.3 実行戦略の変更 9.4.4 代入操作 9.4.5 合流するプログラムへの変換 9.5 まとめ
第1章 有限オートマトン D.Perrin：橋口攻三郎 1. 序論 2. 有限オートマトンと認識可能集合 3. 有理表現 4. Kleeneの定理 5. 星の高さ 6. 星自由集合 7. 特殊なオートマトン 8. 数の認識可能集合 第2章 文脈自由言語 J.Berstel and L.Boasson：富田 悦次 1. 序論 2. 言語 2.1 記法と例 2.2 Hotz 群 2.3 曖昧性と超越性 3. 反復 3.1 反復補題 3.2 交換補題 3.3 退化 4. 非生成元の探求 4.1 準備 4.2 生成元 4.3 非生成元と代入 4.4 非生成元と決定性 4.5 主錐の共通部分 5. 文脈自由群 5.1 文脈自由群 5.2 Cayleyグラフ 5.3 終端 第3章 形式言語とべき級数 A.Salomaa：河原 康雄 1. 序論 2. 準備 3. 書換え系と文法 4. Post正準系 5. Markov系 6. 並列書換え系 7. 射と言語 8. 有理べき級数 9. 代数的べき級数 10. べき級数の応用 第4章 無限の対象上のオートマトン W.Thomas：山崎 秀記 序論 Ⅰ部 無限語上のオートマトン 記法 1. Buchiオートマトン 2. 合同関係と補集合演算 3. 列計算 4. 決定性とMcNaughtonの定理 5. 受理条件とBorelクラス 6. スター自由ω言語と時制論理 7. 文脈自由ω言語 Ⅱ部 無限木上のオートマトン 記法 8. 木オートマトン 9. 空問題と正則木 10. 補集合演算とゲームの決定性 11. 木の単項理論と決定問題 12. Rabin認識可能な集合の分類 12.1 制限された単項2階論理 12.2 Rabin木オートマトンにおける制限 12.3 不動点計算 第5章 グラフ書換え：代数的・論理的アプローチ B.Courcelle：會澤 邦夫 1. 序論 2. 論理言語とグラフの性質 2.1 単純有向グラフの類S 2.2 グラフの類D(A) 2.3 グラフの性質 2.4 1階のグラフの性質 2.5 単項2階のグラフの性質 2.6 2階のグラフの性質 2.7 定理 3. グラフ演算とグラフの表現 3.1 源点付きグラフ 3.2 源点付き超グラフ 3.3 超グラフ上の演算 3.4 超グラフの幅 3.5 導来演算 3.6 超辺置換 3.7 圏における書換え規則 3.8 超グラフ書換え規則 4. 超グラフの文脈自由集合 4.1 超辺置換文法 4.2 HR文法に伴う正規木文法 4.3 超グラフの等式集合 4.4 超グラフの文脈自由集合の性質 5. 超グラフの文脈自由集合の論理的性質 5.1 述語の帰納的集合 5.2 論理構造としての超グラフ 5.3 有限超グラフの可認識集合 6. 禁止小グラフで定義される有限グラフの集合 6.1 小グラフ包含 6.2 木幅と木分解 6.3 比較図 7. 計算量の問題 8. 無限超グラフ 8.1 無限超グラフ表現 8.2 無限超グラフの単項性質 8.3 超グラフにおける等式系 8.4 関手の初期不動点 8.5 超グラフにおける等式系の初期解 8.6 等式的超グラフの単項性質 第6章 書換え系 N.Dershowitz and J.-P.Jouannaud：稲垣 康善，直井 徹 1. 序論 2. 構文論 2.1 項 2.2 等式 2.3 書換え規則 2.4 決定手続き 2.5 書換え系の拡張 3. 意味論 3.1 代数 3.2 始代数 3.3 計算可能代数 4. Church-Rosser性 4.1 合流性 4.2 調和性 5. 停止性 5.1 簡約順序 5.2 単純化順序 5.3 経路順序 5.4 書換え系の組合せ 6. 充足可能性 6.1 構文論的単一化 6.2 意味論的単一化 6.3 ナローイング 7. 危険対 7.1 項書換え 7.2 直交書換え系 7.3 類書換え 7.4 順序付き書換え 7.5 既約な書換え系 8. 完備化 8.1 抽象完備化 8.2 公平性 8.3 完備化の拡張 8.4 順序付き書換え 8.5 機能的定理証明 8.6 1階述語論理の定理証明 9. 書換え概念の拡張 9.1 順序ソート書換え 9.2 条件付き書換え 9.3 優先度付き書換え 9.4 グラフ書換え 第7章 関数型プログラミングとラムダ計算 H.P.Barendregt：横内 寛文 1. 関数型計算モデル 2. ラムダ計算 2.1 変換 2.2 計算可能関数の表現 3. 意味論 3.1 操作的意味論：簡約と戦略 3.2 表示的意味論：ラムダモデル 4. 言語の拡張 4.1 デルタ規則 4.2 型 5. 組合せ子論理と実装手法 5.1 組合せ子論理 5.2 実装の問題 第8章 プログラミング言語における型理論 J.C.Mitchell：林 晋 1. 序論 1.1 概論 1.2 純粋および応用ラムダ計算 2. 関数の型をもつ型付きラムダ計算 2.1 型 2.2 項 2.3 証明系 2.4 意味論と健全性 2.5 再帰的関数論的モデル 2.6 領域理論的モデル 2.7 カルテシアン閉圏 2.8 Kripkeラムダモデル 3. 論理的関係 3.1 はじめに 3.2 作用的構造上の論理的関係 3.3 論理的部分関数と論理的同値関係 3.4 証明論的応用 3.5 表現独立性 3.6 論理的関係の変種 4. 多相型入門 4.1 引数としての型 4.2 可述的な多相的計算系 4.3 非可述的な多相型 4.4 データ抽象と存在型 4.5 型推論入門 4.6 型変数をもつλ→の型推論 4.7 多相的宣言の型推論 4.8 他の型概念 第9章 帰納的な関数型プログラム図式 B.Courcelle：深澤 良彰 1. 序論 2. 準備としての例 3. 基本的な定義 3.1 多ソート代数 3.2 帰納的な関数型プログラム図式 3.3 同値な図式 4. 離散的解釈における操作的意味論 4.1 部分関数と平板な半順序 4.2 離散的解釈 4.3 書換えによる評価 4.4 意味写像 4.5 計算規則 5. 連続的解釈における操作的意味論 5.1 連続代数としての解釈 5.2 有限の極大要素と停止した計算 6. 解釈のクラス 6.1 汎用の解釈 6.2 代表解釈 6.3 解釈の方程式的クラス 6.4 解釈の代数的クラス 7. 最小不動点意味論 7.1 最小で唯一の解を得る不動点理論 7.2 Scottの帰納原理 7.3 Kleeneの列と打切り帰納法 8. プログラム図式の変換 8.1 プログラム図式における同値性の推論 8.2 畳込み，展開，書換え 8.3 制限された畳込み展開 9. 研究の歴史，他の形式のプログラム図式，文献ガイド 9.1 流れ図 9.2 固定された条件をもつ一様な帰納的関数型プログラム図式 9.3 多様な帰納的関数型プログラム図式 9.4 代数的理論 9.5 プログラムの生成と検証に対する応用 第10章 論理プログラミング K.R.Apt：筧 捷彦 1. 序論 1.1 背景 1.2 論文の構成 2. 構文と証明論 2.1 1階言語 2.2 論理プログラム 2.3 代入 2.4 単一化子 2.5 計算過程―SLD溶融 2.6 例 2.7 SLD導出の特性 2.8 反駁手続き―SLD木 3. 意味論 3.1 1階論理の意味論 3.2 SLD溶融の安全性 3.3 Herbrand模型 3.4 直接帰結演算子 3.5 演算子とその不動点 3.6 最小Herbrand模型 3.7 SLD溶融の完全性 3.8 正解代入 3.9 SLD溶融の強安全性 3.10 手続き的解釈と宣言的解釈 4. 計算力 4.1 計算力と定義力 4.2 ULの枚挙可能性 4.3 帰納的関数 4.4 帰納的関数の計算力 4.5 TFの閉包順序数 5. 否定情報 5.1 非単調推論 5.2 閉世界仮説 5.3 失敗即否定規則 5.4 有限的失敗の特徴付け 5.5 プログラムの完備化 5.6 完備化の模型 5.7 失敗即否定規則の安全性 5.8 失敗即否定規則の完全性 5.9 等号公理と恒等 5.10 まとめ 6. 一般目標 6.1 SLDNF-溶融 6.2 SLDNF-導出の安全性 6.3 はまり 6.4 SLDNF-溶融の限定的な完全性 6.5 許容性 7. 層状プログラム 7.1 準備 7.2 層別 7.3 非単調演算子とその不動点 7.4 層状プログラムの意味論 7.5 完全模型意味論 8. 関連事項 8.1 一般プログラム 8.2 他の方法 8.3 演繹的データベース 8.4 PROLOG 8.5 論理プログラミングと関数プログラミングの統合 8.6 人工知能への応用 第11章 表示的意味論 P.D.Mosses：山田 眞市 1. 序論 2. 構文論 2.1 具象構文論 2.2 抽象構文 2.3 文脈依存構文 3. 意味論 3.1 表示的意味論 3.2 意味関数 3.3 記法の慣例 4. 領域 4.1 領域の構造 4.2 領域の記法 4.3 記法上の約束事 5. 意味の記述法 5.1 リテラル 5.2 式 5.3 定数宣言 5.4 関数の抽象 5.5 変数宣言 5.6 文 5.7 手続き抽象 5.8 プログラム 5.9 非決定性 5.10 並行性 6. 文献ノート 6.1 発展 6.2 解説 6.3 変形 第12章 意味領域 C.A.Gunter and D.S.Scott：山田 眞市 1. 序論 2. 関数の帰納的定義 2.1 cpoと不動点定理 2.2 不動点定理の応用 2.3 一様性 3. エフェクティブに表現した領域 3.1 正規部分posetと射影 3.2 エフェクティブに表現した領域 4. 作用素と関数 4.1 積 4.2 Churchのラムダ記法 4.3 破砕積 4.4 和と引上げ 4.5 同形と閉包性 5. べき領域 5.1 直観的説明 5.2 形式的定義 5.3 普遍性と閉包性 6. 双有限領域 6.1 Poltkin順序 6.2 閉包性 7. 領域の帰納的定義 7.1 閉包を使う領域方程式の解法 7.2 無型ラムダ記法のモデル 7.3 射影を使う領域方程式の解法 7.4 双有限領域上の作用素の表現 第13章 代数的仕様 M.Wirsing：稲垣 康善，坂部 俊樹 1. 序論 2. 抽象データ型 2.1 シグニチャと項 2.2 代数と計算構造 2.3 抽象データ型 2.4 抽象データ型の計算可能性 3. 代数的仕様 3.1 論理式と理論 3.2 代数的仕様とその意味論 3.3 他の意味論的理解 4. 単純仕様 4.1 束と存在定理 4.2 単純仕様の表現能力 5. 隠蔽関数と構成子をもつ仕様 5.1 構文と意味論 5.2 束と存在定理 5.3 隠蔽記号と構成子をもつ仕様の表現能力 5.4 階層的仕様 6. 構造化仕様 6.1 構造化仕様の意味論 6.2 隠蔽関数のない構造化仕様 6.3 構成演算 6.4 拡張 6.5 観測的抽象化 6.6 構造化仕様の代数 7. パラメータ化仕様 7.1 型付きラムダ計算によるアプローチ 7.2 プッシュアウトアプローチ 8. 実現 8.1 詳細化による実現 8.2 他の実現概念 8.3 パラメータ化された構成子実現と抽象化子実現 8.4 実行可能仕様 9. 仕様記述言語 9.1 CLEAR 9.2 OBJ2 9.3 ASL 9.4 Larch 9.5 その他の仕様記述言語 第14章 プログラムの論理 D.Kozen and J.Tiuryn：西村 泰一，近藤 通朗 1. 序論 1.1 状態，入出力関係，軌跡 1.2 外的論理，内的論理 1.3 歴史ノート 2. 命題動的論理 2.1 基本的定義 2.2 PDLに対する演繹体系 2.3 基本的性質 2.4 有限モデル特性 2.5 演繹的完全性 2.6 PDLの充足可能性問題の計算量 2.7 PDLの変形種 3. 1階の動的論理 3.1 構文論 3.2 意味論 3.3 計算量 3.4 演繹体系 3.5 表現力 3.6 操作的vs.公理的意味論 3.7 他のプログラミング言語 4. 他のアプローチ 4.1 超準動的論理 4.2 アルゴリズム的論理 4.3 有効的定義の論理 4.4 時制論理 第15章 プログラム証明のための手法と論理 P.Cousot：細野 千春，富田 康治 1. 序論 1.1 Hoareの萌芽的な論文の解説 1.2 C.A.R.HoareによるHoare論理のその後の研究 1.3 プログラムに関する推論を行うための手法に関するC.A.R.Hoareによるその後の研究 1.4 Hoare論理の概観 1.5 要約 1.6 この概観を読むためのヒント 2. 論理的，集合論的，順序論的記法 3. プログラミング言語の構文論と意味論 3.1 構文論 3.2 操作的意味論 3.3 関係的意味論 4. 命令の部分正当性 5. Floyd-Naurの部分正当性証明手法とその同値な変形 5.1 Floyd-Naurの手法による部分正当性の証明の例 5.2 段階的なFloyd-Naurの部分正当性証明手法 5.3 合成的なFloyd-Naurの部分正当性証明手法 5.4 Floyd-Naurの部分正当性の段階的な証明と合成的な証明の同値性 5.5 Floyd-Naurの部分正当性証明手法の変形 6. ライブネスの証明手法 6.1 実行トレース 6.2 全正当性 6.3 整礎関係，整列集合，順序数 6.4 Floydの整礎集合法による停止性の証明 6.5 ライブネス 6.6 Floydの全正当性の証明手法からライブネスへの一般化 6.7 Burstallの全正当性証明手法とその一般化 7. Hoare論理 7.1 意味論的な観点から見たHoare論理 7.2 構文論的な観点から見たHoare論理 7.3 Hoare論理の意味論 7.4 構文論と意味論の間の関係：Hoare論理の健全性と完全性の問題 8. Hoare論理の補足 8.1 データ構造 8.2 手続き 8.3 未定義 8.4 別名と副作用 8.5 ブロック構造の局所変数 8.6 goto文 8.7 （副作用のある）関数と式 8.8 コルーチン 8.9 並行プログラム 8.10 全正当性 8.11 プログラム検証の例 8.12 プログラムに対して1階論理を拡張した他の論理 第16章 様相論理と時間論理 E.A.Emerson：志村 立矢 1. 序論 2. 時間論理の分類 2.1 命題論理 対 1階述語論理 2.2 大域的と合成的 2.3 分岐的 対 線形 2.4 時点と時区間 2.5 離散 対 連続 2.6 過去時制 対 未来時制 3. 線形時間論理の技術的基礎 3.1 タイムライン 3.2 命題線形時間論理 3.3 1階の線形時間論理 4. 分岐的時間論理の技術的基礎 4.1 樹状構造 4.2 命題分岐的時間論理 4.3 1階の分岐的時間論理 5. 並行計算：その基礎 5.1 非決定性と公平性による並列性のモデル化 5.2 並列計算の抽象モデル 5.3 並列計算の具体的なモデル 5.4 並列計算の枠組みと時間論理の結び付き 6. 理論的見地からの時間論理 6.1 表現可能性 6.2 命題時間論理の決定手続き 6.3 演繹体系 6.4 モデル性の判定 6.5 無限の対象の上のオートマトン 7. 時間論理のプログラムの検証への応用 7.1 並行プログラムの正当性に関する性質 7.2 並行プログラムの検証：証明論的方法 7.3 時間論理による仕様からの並行プログラムの機械合成 7.4 有限状態並行システムの自動検証 8. 計算機科学における他の様相論理と時間論理 8.1 古典様相論理 8.2 命題動的論理 8.3 確率論理 8.4 不動点論理 8.5 知識 第17章 関係データベース理論の構成要素 P.C.Kanellakis：鈴木 晋 1. 序論 1.1 動機と歴史 1.2 内容についての案内 2. 関係データモデル 2.1 関係代数と関係従属性 2.2 なぜ関係代数か 2.3 なぜ関係従属性か 2.4 超グラフとデータベーススキーマの構文について 2.5 論理とデータベースの意味について 3. 従属性とデータベーススキーマ設計 3.1 従属性の分類 3.2 データベーススキーマ設計 4. 問合わせデータベース論理プログラム 4.1 問合わせの分類 4.2 データベース論理プログラム 4.3 問合わせ言語と複合オブジェクトデータモデル 5. 議論：関係データベース理論のその他の話題 5.1 不完全情報の問題 5.2 データベース更新の問題 6. 結論 第18章 分散計算：モデルと手法 L.Lamport and N.Lynch：山下 雅史 1. 分散計算とは何か 2. 分散システムのモデル 2.1 メッセージ伝達モデル 2.2 それ以外のモデル 2.3 基礎的概念 3. 分散アルゴリズムの理解 3.1 挙動の集合としてのシステム 3.2 安全性と活性 3.3 システムの記述 3.4 主張に基づく理解 3.5 アルゴリズムの導出 3.6 仕様記述 4. 典型的な分散アルゴリズム 4.1 共有変数アルゴリズム 4.2 分散合意 4.3 ネットワークアルゴリズム 4.4 データベースにおける並行性制御 第19章 並行プロセスの操作的および代数的意味論 R.Milner：稲垣 康善，結縁 祥治 1. 序論 2. 基本言語 2.1 構文および記法 2.2 操作的意味論 2.3 導出木と遷移グラフ 2.4 ソート 2.5 フローグラフ 2.6 拡張言語 2.7 その他の動作式の構成 3. プロセスの強合同関係 3.1 議論 3.2 強双模倣関係 3.3 等式による強合同関係の性質 3.4 強合同関係における置換え可能性 3.5 強等価関係上での不動点の唯一性 4. プロセスの観測合同関係 4.1 観測等価性 4.2 双模倣関係 4.3 観測合同関係 4.4 プロセス等価性上での不動点の唯一性 4.5 等式規則の完全性 4.6 プロセスの等価性に対するその他の概念 5. 双模倣等価関係の解析 5.1 等価性の階層構造 5.2 階層構造の論理的特性化 6. 合流性をもつプロセス 6.1 決定性 6.2 合流性 6.3 合流性を保存する構成子 7. 関連する重要な文献
その大学には情報工学部が別にあったんですが、工学部にも情報工学を学べるコースがあったんです。
自分は別のコースだったんですが、情報処理技術者試験対策に、その情報工学を学べるコースの授業をとってました。
で、何故かわからないんですが、その授業、情報工学コースの学生がみんな寝てるの。起きてるの私だけ。
なんで？
データベースの授業だったんですが、なんで私だけ起きてて、他の人はみんな寝てたんだろう…。別の授業(Prologを使ったなにか)はさすがにそんなことなかったけど。まああれは実習だしなあ…。
これみて思い出したんで書きました。
http://anond.hatelabo.jp/20090404235214です。
ご協力ありがとうございます。
普通の：
・Compiler Construction (Louden)
・Effective C# (Wagner)
・Compilers (Aho, et al.)
・Virtual Machines (Smith, Nair)
・Garbage Collection (Jones, Lins)
・車窓で旅する日本列島
・Common Lisp 第2版 (Steele Jr.)
・Assembly Language for Intel-Based Computers (Irvine)
・Concrete Mathematics (Knuth, et al.)
・Programming Language Pragmatics (Scott)
・Basic Category Theory for Computer Scientists (Pierce)
ダメげなの：
・サモンナイトコレクション
・しろ画集
・カーネリアンコレクション
・Bittersweet Fools ビジュアルファンブック
・ISO/IEC 13211 Information technology - Programming languages - Prolog - (Prologの規格書)
・県別マップル十数冊
整理されてなさすぎるのがよくわかった。
その他本棚にあるもの：
・危ない28号 3冊
・夏少女の紙袋
http://anond.hatelabo.jp/20090220065041
8つしかないボタンの順番を正しく押さないと目的地への切符が買えない。
普通の英文による注文で切符が買えるハズなのだが、実際には専門家に頼んで注文を書いてもらわないと上手く買えない。
亀を出発駅から到着駅まで移動させることで切符を買う。
出発駅と到着駅の型が違う場合、適切な経由駅を設定しないと切符が買えない。
任意の切符を発行するためのビルダーテンプレートのインスタンスを生成できる。
切符は他の切符のコピーで作られるため、切符をどう印刷するかについてのプログラムはまったく入っていない。
到着駅と出発駅を入力すると、到達可能であることが示される。切符は出てこない。
どの駅でも同じ操作で切符が買えるハズなのだけど、実際のところは微妙に違ってぬるぽで落ちる。
http://anond.hatelabo.jp/20081105135432
彼女ができた。なんとHaskellerだ。
8月に参加したLLイベントで知り合い、10月から付き合い始めた。なんでLLイベントにHaskellerが…
これまで5人くらいのプログラマと付き合ったことがあるけれど、一般的なプログラマと比較して
といった点が目立つ。
見た目はLisperを少し丸くしたようなかわいらしさがあるのだけれど、要するに中身はPrologだ。
初めは戸惑いもあったが、案外こういうプログラマとつきあうのは楽で楽しいと分かってきた。
コードは深い問題もFizzBuzzのような軽い問題も内容を伴って書ける。
いろいろメタプログラミング・アロー記法・ユニコード演算子などを試そうとするなど好奇心が強い。
純粋関数型言語も習得しているというのに論理系の言語も習得しようと勉強していて向上心の強さがある。
IOモナドをコントロールできない自分に「おかしいな、普段はこんなはずじゃないのに///」と恥ずかしがる。
Haskeller、はっきり言ってオススメです。
問題はどうやって知り合うかだけれど、職場(あるのか?)という戦闘モードの時に誘うのではなく、.emacsなどを書いているオフタイムが狙い目としか。
初めの一歩が難しいだけで、後は一般的な女の子よりも付き合いは簡単かも。
via Twitterオタが非オタの彼女にTwitter世界を軽く紹介するための10ユーザ
まあ、どのくらいの数のプログラミング言語オタがそういう彼女をゲットできるかは別にして、
「オタではまったくないんだが、しかし自分のオタ趣味を肯定的に黙認してくれて、
その上で全く知らないプログラミング言語の世界とはなんなのか、ちょっとだけ好奇心持ってる」
ような、ヲタの都合のいい妄想の中に出てきそうな彼女に、プログラミング言語のことを紹介するために
習得させるべき10言語を選んでみたいのだけれど。
（要は「脱オタクファッションガイド」の正反対版だな。彼女にプログラミングを布教するのではなく
相互のコミュニケーションの入口として）
あくまで「入口」なので、アーキテクチャに過度に依存するアセンブラ等の低級言語は避けたい。
あと、いくら基礎といってもBrainf*ckやUnlambdaのような難しすぎるものは避けたい。
ポール・グラハムが『Arc』は外せないと言っても、それはちょっとさすがになあ、と思う。
そういう感じ。
彼女の設定は
ロジカル度が高く、頭はけっこう良い
まあ、いきなりここかよとも思うけれど、「Java以前」を濃縮しきっていて、「Java以後」を決定づけたという点では
ただ、ここでオタトーク全開にしてしまうと、彼女との関係が崩れるかも。
この情報過多な言語について、どれだけさらりと、嫌味にならず濃すぎず、それでいて必要最小限の情報を彼女に
伝えられるかということは、オタ側の「真のコミュニケーション能力」の試験としてはいいタスクだろうと思う。
アレって典型的な「オタクが考える一般人に受け入れられそうなプログラミング言語（そうオタクが思い込んでいるだけ。実際は全然受け入れられない）」そのものという意見には半分賛成・半分反対なのだけれど、それを彼女にぶつけて確かめてみるには一番よさそうな素材なんじゃないのかな。
「プログラミング言語オタとしてはこの二つは“教育用言語”としていいと思うんだけど、率直に言ってどう？」って。
ある種の言語オタが持ってるラムダ計算への憧憬と、ACM監修の関数型言語的純粋さへのこだわりを
彼女に紹介するという意味ではいいなと思うのと、それに加えていかにも参照透過な
の二要素をはじめとして、オタ好きのする要素を言語にちりばめているのが、紹介してみたい理由。
たぶんこれを見た彼女は「Emacsだよね」と言ってくれるかもしれないが、そこが狙いといえば狙い。
この系譜の作品がその後続いていないこと、これがポール・グラハムの間では大人気になったこと、
ポールグラハムがウェブサービスの構築に使って、それがいろんなウェブサービス開発者にも影響しててもおかしくはなさそうなのに、
実際のウェブサービスでこういうのが使われないこと、なんかを非オタ彼女と話してみたいかな、という妄想的願望。
「やっぱりプログラミングはバッチ処理のためのものだよね」という話になったときに、そこで選ぶのは「awk」
でもいいのだけれど、そこでこっちを選んだのは、この言語にかけるラリーとdankogaiの思いが好きだから。
断腸の思いで延ばしに延ばしてそれでも2008年、っていうPerl 6のリリース予定日が、どうしても俺の心をつかんでしまうのは、
そのリリースというイベントへの諦めきれなさがいかにもオタ的だなあと思えてしまうから。
Perlのリリース延期を無駄だとは思わないし、拙速なリリースは無茶だろうとは思うけれど、一方でこれが
GuidoやMatzだったらきっちり予定通りリリースしてしまうだろうとも思う。
なのに、各所に頭下げて迷惑かけてリリースを延期してしまう、というあたり、どうしても
「自分の言語を形作ってきた哲学(TMTOWTDI)が捨てられないオタク」としては、たとえラリーがそういうキャラでなかったとしても、
親近感を禁じ得ない。言語自体の高評価と合わせて、そんなことを彼女に話してみたい。
今の若年層でPostscriptを直で書いたことのある人はそんなにいないと思うのだけれど、だから紹介してみたい。
PDFよりも前の段階で、DTPの哲学とか印刷技法とかはこの作品で頂点に達していたとも言えて、
こういうクオリティのプログラミング言語がエディタで書かれてたんだよ、というのは、
別に俺自身がなんらそこに貢献してなくとも、なんとなくプログラミング言語好きとしては不思議に誇らしいし、
いわゆるJava VMでしかスタック型言語を知らない彼女には見せてあげたいなと思う。
PHPの「HTMLに埋め込み可能な点」あるいは「RDBMSとの接続性」をオタとして教えたい、というお節介焼きから教える、ということではなくて。
「HTMLのテンプレートエンジンを作り続ける」的な感覚が言語オタには共通してあるのかなということを感じていて、
だからこそアメリカ版『Yahoo!』の開発言語はPHP以外ではあり得なかったとも思う。
「MとVとCを分離なんてできない」というオタの感覚が今日さらに強まっているとするなら、その「オタクの気分」の
源はPHPにあったんじゃないか、という、そんな理屈はかけらも口にせずに、
単純に楽しんでもらえるかどうかを見てみたい。
これは地雷だよなあ。地雷が火を噴くか否か、そこのスリルを味わってみたいなあ。
こういう述語論理風味の計算をこういうかたちで言語化して、それが非オタに受け入れられるか
気持ち悪さを誘発するか、というのを見てみたい。
9本まではあっさり決まったんだけど10本目は空白でもいいかな、などと思いつつ、便宜的にC++を選んだ。
Javaから始まってC++で終わるのもそれなりに収まりはいいだろうし、テンプレート以降のメタプログラミング時代
の先駆けとなった言語でもあるし、紹介する価値はあるのだろうけど、もっと他にいい言語がありそうな気もする。
というわけで、俺のこういう意図にそって、もっといい10本目はこんなのどうよ、というのがあったら
教えてください。
「駄目だこの増田は。俺がちゃんとしたリストを作ってやる」というのは大歓迎。
こういう試みそのものに関する意見も聞けたら嬉しい。
