龍虎氏の記事(2024/02/24)に対するコメント。
リストのスライスも完全に忘れてるのでちゃんと読む。これ、ほ〜・・って感じ
まぁ、これから実感してくと思うんだけど、「忘れてても構わなかった」になると思う(笑)。調べたら「あ、この程度か」ってのが「Lispより抽象度の低い言語との相対」では頻出だから、だ。
繰り返すけど、ポール・グレアムの「ほげ言語」のパラドックスってマジなんだよ。それをこれから実感していくと思う。
もうかなり「Lispを通した目」で他言語を見れるようになっていく筈だ。これは必ずしも「上から目線」は意味してなくて、単に「機能が多い言語」で「それより機能が少ない言語」を学ぶのは比較的ラクだ、って話なんだよ。
概念上の問題に煩わされる事が少ない、って意味なんだ。
破壊的！便利そうですけどね
うん。
でもこの「機能」ってのは本来は、メモリの使い方の一つ、スタックの機能をリストでエミュレートする為、ってのが本懐なんだ。
スタック、と言うメモリ構造に対しては基本的に、ポップとプッシュと言う「たった2つの操作」しかない。で、Pythonの場合、プッシュにはappendメソッドがあり、残りがpopなんだ。
プログラムを書いてて、スタック操作が必要な局面が多いんで、リスト操作に於いて「リストをスタックに見立てる為」に、appendとpopメソッドが実装されてる、って考えた方が実は正しいんだよね。
「破壊的操作が推奨されてる」わけじゃなくって、「スタック利用の為」ってのが原則なんだ。
真偽値に関しては言語ごとにちゃんとまとめておかないとな〜と。
そう、その通りだ(笑)。
ほらね、Lispやっただけでそういう「勘所」が分かるようになる(笑)。
少なくとも「空リストをどう解釈するか?」がANSI Common LispとSchemeの大きな違いなんで、この辺、他言語で「真偽値はどう定義されてるのか」慎重になるクセは付くよな。
;; Racket> (not '())
#f;; ANSI Common LispCL-USER> (not '())
T
CL-USER>
# Python>>> not []
True
実は空リストの扱いに関しては、PythonはSchemeじゃなくってANSI Common Lispのような解釈をしてる、って事なんだ。
ほ〜ん・・クラス抽象、関数抽象、構文抽象。
「実用Common Lisp」(PAIP)の著者、ピーター・ノーヴィック先生の文書だよね。
 | 実用Common Lisp ピーター・ノーヴィグ 翔泳社 |
ちなみに、Pythonをやり出したんで、クラス抽象に入り始めてる。関数抽象は既に「修了」だ。実はOCamlの"ml"ってのはそこに書いてあるMLの事なの。構文抽象はマクロだ。Racketで既にマクロに関しても「触っては」いる。
ここで挙げられてるリストで今の時点で足りないのは宣言的抽象、そして並列処理をサポートするもの、なんだけど(※1)、並列処理は僕も良く分かってないんで明言せんけど(笑)、一方、何度か言ったが、Prologは是非とも一回は触ってみるべき"Mustな言語"だと思う。これだけは既存のどの言語と比べても異質だ。ポール・グレアム流に言うと「Lispを頂点とした連続した抽象度のスペクトル」のどこにも属していない(笑)。Prologは仲間外れだ(笑)。良く言うと「独自ポジションにいる」稀有な言語と言っていいだろう(※2)。
もちろん「実用Common Lisp」には「Prologを実装する」ってネタがあるんで、それをやってみて「間接的に触る」をやってみてもいいけどね(※3)。
とりあえずC++やれば網羅出来るか？いつかはやらないといけないな。
ん〜、多分あんま必要ない(笑)。
いや、ピーター・ノーヴィグ先生が書いてる事は間違いってまずねぇんだよな。
ただ、「言語の選定」ってのはどうしても「書いた時期」の影響を受けるのね。これって多分2000年前後にオリジナルは書かれてるんだ・・・つまり24年前、四半世紀前後前での「言語選定」なのね(そう考えると「随分と昔」だ)。
そう考えると、「パラダイム毎に言語を学ぶべき」ってのは「その通り」なんだけど、じゃあ「どの言語を?」ってのはズレが出て然るべき、なんだよ(笑)。
大体、リストを精査しても、何だかんだ言って「歴史の流れに逆らって」生き残ってるプログラミング言語ってLisp語族しかねぇじゃない(笑)。
クラス抽象、で考えるとPythonで充分、って事になる。あるいは、Javaを選ぶなら現在ではC#を選ぶべきだよな。いや、僕はC#やったことねぇけどさ(笑・※4)。
人によっては「Javaはウェブアプリのバックエンドとして使われてるんで学ぶ価値はある」って言うけど、言い換えるとこれって言ってるレベルが「銀行業務ではCOBOLが使われてるんで、学ぶ価値がある」と言うのと同じなんだよな(笑)。
後者なら「そうか?」って思うだろう。じゃあ、どうして前者は「そうか?」にならんのか。
つまり、ピーター・ノーヴィグ先生が言ってるような事を「学習の動機」とするなら、「学習」に対してどういう言語にすんのか、ってのは「別の視点」で考えなければダメだ、って事なんだよ。学習の動機が重要なのに、「特定分野で使われるから」を理由に挙げるのはダメ、なんだ(こういう「推挙」が良く行われる)。むしろやっちゃアカンのだ(もちろん「Webアプリのバックエンドが書きたいんです!」って動機があったり「銀行業務のプログラムを書きたいんです!」が動機ならこの限りじゃないけど、このコンテクストではそれらは動機になり得ないだろ)。
少なくとも、C#はJavaより後発なんで、「Javaに新しい機能を導入したら歪になっちまった」部分が整理されてるだろう。「それ込み」で最初からクリーンな設計を目指しただろうからな。言い換えると、「後方互換性を重視した為に」Javaがテを入れられない辺りを「最初から作り直した」のがC#なんだ。Javaがどうしても、「過去の資産を捨てられない」辺りはC#は当然「新参」な以上気にせんでエエ。だからJavaに比べるとどうしても当然クリーンな設計になる。
もう一つ重要なのは、C#には国際標準(ISO)により「標準言語仕様」が制定されてしまった。Javaにはそれがない。Javaにも仕様は存在するが、それはOracleが決めたモノが文書として発表されてる、ってだけで、要は「権威がない」言語仕様書なんだよな。いつ言語仕様が「Oracleの都合によって」変更されるか分からん。一方、C#はマイクロソフトが作った言語なんだけど、既にマイクロソフトの手を離れてて、マイクロソフトでさえ「自分の勝手で」言語仕様を変更する事が不可能になっちまってるんだ。
「公式仕様の存在」ってのは「その言語を学ぶのは安心」と言う理由付けの一つ、となる。「いつ何がどう変わるか分からん」言語なんざ推薦出来るか、って話が当然出てくる。Javaに欠けてるものがC#には「ある」んだよ。
C++を学習する事に対するアレコレに対してもスティーヴ・イエギの文書に詳しい。
C++は地上でもっともバカな言語だ。すごく感覚が鈍いという意味で。C++は自分自身のことがわからない。イントロスペクティブでないのだ。Cも同様だが、Cは別に「オブジェクト指向」なわけではない。そしてオブジェクト指向であるということの小さからぬ部分は、プログラムが自分自身のことをわかるということなのだ。オブジェクトはアクターだ。だからOO言語はランタイムリフレクションとランタイムタイピングを 備えている必要があるのだが、C++は本当にはそれを持っていない。あなたが使ったやつは違うのだ。Cについて言うと、Cの上にイントロスペクションのように振る舞うツールを作れるCコンパイラを書くのはとても簡単だ。一方、C++は本質的にパースできない。だからあなたが、たとえば仮想関数のシグネチャを教えてくれたり、コードをリファクタリングしてくれたりするような賢いツールを書こうと思うなら、誰か他の人の書いたツールセットを我慢して使うしかない。あなたはまずパースできないはずだ。そしてC++をパースするツールセットというのはどれも最低だ。C++はバカであり、バカな言語で賢いシステムを書くことはできない。言語は世界を形作る。バカな言語はバカな世界を作る。コンピューティングはすべて抽象化に基づいている。低いレベルのものの上に、高いレベルのものが作られる。分子から都市を造ることはできない。あまりに抽象度 のレベルが低いものを使おうとするなら、災難に見舞われることになる。そして私たちは災難に見舞われている。Cでまっとうに書くことのできる一番大きなものはオペレーティングシステムだ。そしてそれは実際のところそんなに大きなものではない。それが大きく見えるのはアプリケーションのためであって、カーネルは小さなものだ。C++で書くことのできる一番大きなものは･･･やはりオペレーティングシステムだ。まあ、幾分大きめの。3倍大きいということにしておこう。あるいは10倍でもいい。しかしオペレーティングシステムのカーネルはせいぜい100万行というところだろうか? だからC++でまっとうに書ける一番大きなシステムは1000万行で、そのあとは崩れていき、コントロールできる見込みはなくなり、「リトル・ショップ・オブ・ホラーズ」の工場みたいなことになる。食わせてくれーー・・・コンパイルできるところが限界だ。うちには5000万行のC++コードがある。いや、今ではもっと増えている。もはやどれくらいになっているのかわからない。去年のクリスマス、つまり9ヶ月前には5000万行だった。それから4半期ごとに800万行ずつ増えている。増加率自体も増えている。やれやれ。ここでは何かやるのにいつまでも時間がかかる。以前あるAmazonのエンジニアが、我々のコードベースをこう形容した。「巨大なクソの山で、かつて見たこともないほどでかく、その中心まで潜って 行くのが我々の仕事であり、そのたびに何かを直す羽目になる」それが4年前の話だ。そのエンジニアはもっと快適な場所へと去ってしまった。残念なことだ。彼は本当に優秀な人間だったのだ。これはすべてC++の問題だ。口答えしない。そうなのだ。私たちは世界でもっともバカな言語を使っている。それはメタ-バカとでもいうたぐいのものだ。そう思わない?とは言え、C++コードでいいものを書くことは明らかに可能だ。それはつまり、ほとんどCのコードに、いくらかのC++の機能が、最低限だけうまく使われているような場合だ。しかしそういうこと には決してならない。C++はすごい遊び場であり、そのすべてを知るとすごく賢くなった気分になる。だからあなたはそのすべてを使おうとすることになる。しかしそれはうまくやるのが本当に難しいのだ。なぜならC++はそもそもにおいてクズ言語だからだ。たとえあなたが優秀であったとしても、結局は台無しになってしまう。こんなことを言うのが異端であるのはわかっている。固有名詞の異端だ。私だって大学生のときはC++が好きだったのだが、それは私がそれしか知らなかったからだ。私の言語の教授のクレイグ・チェインバーズがC++は大嫌いだと言うのを聞いたとき、「どうして? 私はこんなに気に入ってるのに」と思った。そしてSTLの作者がOOPは嫌いだと言ったという話を聞いたとき、私は彼がどうかしてると思った。OOPを嫌うなんてことがありうるだろうか? こともあろうにSTLの作者が?満足を育むのは、多くの場合コンピュータ言語自体ではなく、馴染んでいるということによってだ。慣れ親しんだもので満足してしまう前に、もっといい言語のエキスパートになる必要がある。だから私がC++について言ったことが気に入らないなら、もっといい言語のエキスパートになることだ(私はLispをおすすめする)。そうすればあなたは私に反論する準備ができたことになる。しかしあなたはそうしないだろう。私はあなたを引っかけたのだ。そのときには、あなたはもうC++のことが好きではなくなっている。そして私が引っ かけて元好きだった言語を嫌いにさせたことに腹を立てるかもしれない。だからあなたはたぶん私が今言ったことは単に忘れてしまった方がいいのだ。C++はすごいよ。本当に。すばらしいとしか言いようがない。私の言ったことは忘れてほしい。問題ないって。
あと、ちとズレるけど、Cに対しても同じだ。
いや、このノーヴィック先生の文書にはCが挙げられていない。そこに対してはホント、ノーヴィック先生が「挙げてなかった」って事に対しての信頼度はグンバツ、だ。C++は「Cとは違う」辺りで推薦されてるわけで、C≒C++って曖昧な観点がない。除かれるべき「何らかの理由により」Cは挙げられてない。混同されていない。
ただし、「Cを含む」となると、そして「Cそのものを」学ぶ、となると、プラクティカルな意味だと以前推薦した「Build your own lisp」以上の文書は知ってる限り存在しない。入門者向け、ってなるとそうなるんだよ。このWeb文書は、ワールド・デファクト・スタンダードである「C99」の書き方で書かれていて、そんな文書は日本の「C言語入門書の類」では見られない(実は海外の「入門サイト」でも珍しい)。通常の本/サイトの著者陣が「スタンダードとは何か」の意識が欠落してる以上、そのテの本やサイトで学んではいけない、んだ。
しかし、そのサイトは英語で書かれている以上、日本語でCを学ぶ、と言うのは事実上不可能だ。でも、競合しそうな言語、って言うと現在はRustがある。こいつも権威のある標準言語仕様がねぇけど、C/C++/C#やJavaを学ぶより、その辺のパラダイムを纏めて学ぶんだったら良い言語なんじゃねぇの、ってのが触ってみた感触だ。恐らく、こいつが色々と置き換えてくれると思う。
学習用のページが完備されてるのがいい。しかも日本語だ。ハッキリ言って、2024年現在、システムプログラミングまでターゲット(この視点は、少なくとも現在のLispには欠けてる)に入れた汎用プログラミング言語を学ぶとしたら、どれがいいだろう?って質問に関しては、Cでもなく、C++でもなく、答えはRustなんじゃないか、って思ってる。それくらい「プログラミング基礎教育」としても充分使える言語なんじゃないか、って思ってるんだ。
もう一つ言うと、これも何度も指摘してるけど「C言語を学べばコンピュータの仕組みが分かる」ってのはウソだ。妄言の類、だ。
ハッキリ言うけど、何人も個人的にプログラマに訊いてはみたけど、C言語を学んだからコンピュータの仕組みが分かった、なんつー人は一人もいなかった。
事実は逆で、元々コンピュータの仕組みが分かってるから、C言語を上手く使える事が出来る、んだよ。これは典型例なんだけど、プログラマは理論的、とか言うけど良く因果関係を間違えるのね。原因と結果を取り違えるのに、理論的なわけないじゃない(笑)。
あと、大学のプログラミングの授業とかで、インタプリタやコンパイラの実装を扱うじゃない?インタプリタやコンパイラの実装を扱われたんで、コンピュータの仕組みが分かった、ってのはあり得るんだけど、それとC言語は全く関係ないわけ。言っちゃえば、どんな言語を使おうとインタプリタやコンパイラの実装を経験すればコンピュータの仕組みを分からざるを得ないんだ。
ただ、そういう授業とか?C言語で行われてるケースが多いんで、C言語と「コンピュータの仕組み」が直結して記憶で結びついてる、に過ぎないんだ。実は単なる印象論なんだよな。
そして以前、二分探索木の話でも書いたけど、C言語で授業を行うと言う事はコンセプトの理解、じゃなくって実装詳細の話へすり替わる。
つまり、根本的に何故にインタプリタ/コンパイラを書く授業をしてんのか、と言う理由を(一部の天才学生を除き)誰も理解しない、と言う恐るべき状態になるんだよ。
特に何故にインタプリタを実装するのか?それは一つにコンピュータの動作原理がインタプリタである、と言う事を理解する為。もう一つは全てのソフトウェアはインタプリタが基本となっている、と言う事を学ぶため。
この2つを学ばせる為に尤も抽象的かつ一般的なインタプリタを実装するわけ、なんだけど、どーゆーわけか枝葉末節の構文解析が主題になるんだな(笑)。
んで恐ろしい事に、これで学んだ人が今度教える側になると、ますます、何のためだか良く分からんけど、長年コンピュータサイエンスではインタプリタ/コンパイラの実装法を教えてるからそれをやる、って話になるわけ。
つまり、教える方も「何故にそれを教えるのか」ってヴィジョンが全くねぇんだよ(笑)。そういう状態が何世代にも渡ってきてる、んだよな。
あれだ、この人がこういう事を書いてたんだけど。
何だろ、本を読んでもちっともプログラミングが出来るようにならない、って歯がゆさから書いたのかな?多分。
でも言っちゃえば、別に機密事項がどーの、とか飯の種がどーの、とかそこまで考えてない、と思う。事実はもっとシンプルで、かつ恐ろしい、って事なんじゃないか。
つまり、実はフツーのプログラマ(95%くらい)ってのは、このテの本の著者も含め、ソフトウェアを作る能力がない、と言う。言い換えると一人で一本のソフトウェアを作れないんだ。あるいは汎用の方法論を知らん。だから書かない、んじゃなくって書けない、んだよ。
いや、状況証拠から見るとそうだとしか思えないんだ。何故に「プログラミング入門」系の書籍だと「実際のプログラムの組み方」が書いてないのか。何故にK&Rの焼き直し、のような構成なのか。何故にその言語の「仕様書」を絵解きした程度の本になるのか。
それは「誰もソフトウェアの作り方の一般論を知らない」と言う恐るべき事実を浮き上がらせる。もちろん、会社では書いてるだろう。っつーか、何百人もいるメンバーの中の一人である、とか?書いてるブツも部品だろうが、書いてる方も部品だろう。言わば建築現場で建ててるビルに使われる水道の蛇口ばっか作ってて、じゃあ「一個の大きいビルが作れるか」って訊かれれば答えはNoだろう。そういう事だよな?
逆に言うと、教科書執筆者として見ればアレなんだけど、一人で一本のソフトウェア(なでしこ)を作り上げられるクジラ飛行机さん、とか?どう考えてみてもプログラマとしては超一流の人なんだよな。こんな「一人でソフトウェアを一本作れる」って人、プログラマをテキトーにランダムサンプリングして見ても100人に一人もいねぇんじゃねぇの?
いや、多分事実はそうなんだよ。殆どの「プロのプログラマ」って、一人でソフトウェアを一つ組み上げられない、あるいはそういう方法論を知らん人の方が多い筈だ。そうじゃないとすれば、世の中もっと、フリーソフトウェアが多い筈なんだよね。でもそこまで行き着かない人の方が実は多いんだ。
いやマジで、例えば龍虎氏みたいに「一本ゲームを書いた」ってのは結構凄い事、なんだよ。
あと、最近知ったんだけどこの人も凄い。
何か作り上げちゃった、ってのはどっちみち凄いんだわ。
さて、本論に戻るけど、どうしてそうなってんのか、っつーと上に書いた通りだ。コンピュータサイエンスで学んだ人ってのは殆ど、「知識は持ってる」んだけど、「知識と知識の関連性」とか、その具体性を全く把握してない、って事になる。要は「芯が一本ある」教育ではない、って事なんだよ。あるいは垂直に一本軸が立ってて、あらゆる学んだ事柄がそれに絡んでいる、ってパースペクティヴがない。
んで、殆どの学生は「何だか良く知らんけど」課題をこなす事がまず先なわけじゃん?じゃないと単位を貰えないし。だから俯瞰した位置から物事は見れずに、目先の物事を消化するしかなくなる。
ハッキリ言えば「インタプリタがコンピュータの基礎で、全てのソフトウェアはインタプリタ作成の応用だよ」って一言言えば色んな事が氷解する。でもそもそも「教える側」がそれを把握してないんだ。
一体どういう教育環境なんだ、ってな話でさ(笑)。そして「実装詳細をどーにかするのが主眼になってる」ってののかなりの責は、ハッキリ言ってやる、「C言語を教育の基礎として採用する、なんつーバカな決定のせいだ」(笑)。
前から書いてるけど、僕がノーヴィック先生の「実用Common Lisp」と、「Land of Lisp」の二冊を推薦するのはそれが理由だ。この二冊の本「だけ」は「Read-Eval-Print Loop」、つまりインタプリタの仕組みが全てのソフトウェア作成の基礎だ、ってハッキリ述べている。そして他の本にはそんな事は書かれてない、んだ。
 | Land of Lisp M.D. ConradBarski オライリージャパン |
んで、僕個人の話をすると、例えばSICPとか読んでやってて、
「なんでLispでLisp実装せなアカンねん・・・。」
とかむしろ思ってた方なんだよな(笑)。
そもそも「プログラミングを学びたい」人って、大体「何か実用的なモノを組み上げたい」ってぇんで勉強始めるわけじゃん?
SICPってそういうトコが全くねぇ本なんだよな(笑)。「理論に理論を重ねて・・・」とか言うのってさしてキョーミがないわけじゃん?フツー。モティベーションとしてはさ。
マジでやりながら「何だこれは・・・」とか思ってた(笑)。机上の空論としか思えなかったんだよな。SICP is filled with 机上の空論、だ。
今だと理由もハッキリ見える。SICPには「インタプリタ実装法が全てのソフトウェア作成の基本だ」って言うメッセージが欠けてるんだよ。PAIPにはあってSICPに無いモノはそこだ。
だから僕はSICPを評価しないわけ。「名著だ!」とか言う人多いけど、僕はそこまでとは思っていない。
いや、色んな貴重な「アイディア」は書かれてる本だ、って事は認めよう。でもそれらアイディアの配置も散文的だし、総体的にはその語られているアイディアが最後まで辿られる事はないんだよね、この本だと。言っちゃえば「濡れ場がないエロ小説」みてぇなモンでさ(笑)、「そこが一番大事だろ!」って部分が丸々削除されている以上、評価は出来ないんだよ。
いずれにせよ、PAIPかLoLを「まずは読め」ってのが、「理論と実践を繋ぐ」一番イイ方法だと思う。そうすれば、プログラミングの初心者向けの課題、
/* C言語(※5) */
#include <glib-2.0/glib.h>
#include <editline/readline.h>
GString* eval(gchar* arg) {
GString* hello = g_string_new("Hello, ");
return g_string_append(hello, arg);
}
int main(void) {
while (TRUE) {
printf("%s\n", eval(readline("name? > "))->str);
}
return EXIT_SUCCESS;
};; Racket(define (interp arg)
(format "Hello, ~a" arg))
(define (main)(display "name? > ")
(printf "~a~%" (interp (read)))
(main))
(main)# Python#!/usr/bin/env python3
def interp(arg):
return f'Hello, {arg}'
if __name__ == '__main__':
while True:
print(interp(input('name? > ')))
のようなプログラムのまさしく「延長線上」に、モノホンの「ソフトウェア」が存在する事が分かるだろう。一本の線になるわけだ。
(ちなみに、上のプログラム例は「無限ループをする前提で」書いてるので、脱出する時はCtrlキーとCキーを同時に押す事)
さて、龍虎氏の場合は、既に「アドベンチャーゲームの作り方」をモノにしている。
これも前に指摘したが、「アドベンチャーゲームエンジン」の仕組みはマジでそのまま、「インタプリタ」、つまりRead-Eval-Print Loopだ。
言い換えると、「アドベンチャーゲームを作る」事は極めてコンピュータサイエンス的な話題なんだ。「エロゲで学ぶコンピュータサイエンス」って本を出してもいいくらいだ(笑)。いや、俺は書かんが(笑)。
そこで、今までの議論を見てくれば分かるだろうけど、「コンピュータの仕組みを学ぶ」のと「C言語系プログラミング言語を学ぶ」ってのは実は全く関係がない。
んで、「コンピュータの動作原理を知りたい」なら、マジで「言語処理系を一旦書いちゃう」方がマシ、なんだ。
つまり、その観点で言うと、「C言語系プログラミング言語を学ぶ」のは無駄だ。むしろ「今知ってる言語で、一旦言語インタプリタを書いちゃう」方がよっぽど理解が出来る、って事になる。
んで、このブログでも扱った事があるけど、一番簡単なのはBrainfuckインタプリタを実装してみる事、だ。言語仕様はWikipediaに書いてある通りで、たった8つの条件しかない。記号の一つ一つが「シナリオに書かれた命令」にあたる。そしてこれほど「小さい」言語処理系を利用せんのは勿体ない。
いや、技術的にはもう、これくらい実装出来るレベルには到達している、んだ。大学生辺りだと3〜4年生くらいの技術は「アドベンチャーゲームを作った」以上、既にあるんだよ。気づかんかもしれんが。そしてBrainfuckインタプリタを実装した方が「メモリを理解出来る」。わざわざC系言語を使うまでもない。実際、Brainfuckは、インタプリタ言語処理系としては殆ど「仮想マシン」の仕組みそのまま、なんだ。
これ、一回「自分で考えて」、アドベンチャーゲーム作りの記憶を頼りに実装してみて欲しい。また、「別の言語を学んだ」(例えばOCamlやPython、それ以外)際にもその言語でBrainfuckを実装してみる、ってのはオススメの学習法だ。「どんな言語でもBrainfuckを実装出来る」となれば、みるみる実力が上昇していくだろう(※6)。
繰り返すけど、龍虎氏は既にそういう「言語処理系(インタプリタ)」を作れるレベルに到達している。
これ！
うん(笑)。
エリック・レイモンドが書いた文章だけど、引用はフレッド・ブルックスの本から、だ。
 | 人月の神話 フレデリック・P・ブルックス，Jr. 丸善出版 |
これ、教えて!gooとかに顔出ししてるとマジで良く分かるんだわ(笑)。
以前から、「プログラミングが出来ない人の特徴」として
- 日本語が怪しい/日本語がおぼつかない
- パソコンのモニタをスマホで撮影する
ってのを指摘してたんだけど、これもそうだ。「とにかくデータを軽視する」。
こう、質問でも「どんなデータ形式を取ってるか」分からんとサッパリ分からん、ってのが良くあるんだよ(笑)。「書いた関数じゃなくって設計したデータを見せてみな」って言うの(笑)。「何がやりたいか」と「設計したデータ」さえあれば、自ずとから「どういうプログラムにすべきか」ってのは決まるんだよ。
いや、これはPascalの発明者、ヴィルト先生も言ってた、と思うんだけど(又聞き)、「プログラミングってデータ設計さえ終われば80％は終わってる」んだって。だって残りはその「データ設計」に対してどうプロセスすっか、しか残ってないんだから。
んで、龍虎氏はもう理解したと思うんだけど、例えば上の「コンピュータサイエンスで学んで」「実は一本のソフトウェアが作り上げられない」人たちが書いた本で、「クラス」と言えば「オブジェクト指向」、「データにくっついたメソッド」ってやりたがる人がこれを実は分かってないんだよな。
まず第一に、構造体やクラスってのはその「プロセスしやすいデータを作り上げる」為の材料なのね。その観点がまず欠けてるわけ。クラス/構造体は「データ形式を設計する為にある」の。まずはデータなんだよ。データ形式の設計が来る。そこを強調して強調し過ぎる事はない。
毎回毎回自作でデータ形式を作る必要はないし、既存の形式?xmlとかJSONに乗っかってもいいだろう(Lisp使いなら真っ先にS式を思い浮かべるだろうが・笑)。ただ、最近だとすぐWebスクレイピングでデータを取ってくるだけ、とか?エクセルから簡単に表を読み込めるから、とか?何だろうね、まずはプログラミングに於いて「自分でデータ設計をする」ってキチンと教えてねぇんじゃねぇの、って気がしてる。だからオブジェクト指向如きでビビるんだよ(笑)。んで自分でビビった過去があるから、ニュービーもビビるように書く(笑)。
そんなんじゃねぇんだっての。構造体もクラスもむしろ「プロセス対照としてのデータ形式を記述する為に」あんだって。そして確かにそこを強調してる教科書とか無いよね。無いんだ。いや、Lispは「ある」けど、何でもかんでもリストにしようとするだけ、だ(笑)。
いずれにせよ、「プログラミングよりまずはデータ設計」ってのは一般にはあんま強調されてなくって、「出来るヤツは勝手に気づく」けど「出来ないヤツは永久に気づかない」辺りが問題を深刻化させてんだよな。
Undergraduation僕にとってはコンピューターサイエンスが十分難しいですけどね(^o^)！
いや、多分、以前にも言った事があるけど、いわゆる理系、ってのはある意味学問的なヒエラルキーがあって、ボカして書いてるけど、それを暗示してはいる(笑)。
どっちにせよ、数学が頂点なのね。で「理論度がオチていく」と「知的内容が最も少なく」なる(笑)。
で、日本だと「知的内容が少なくなればなるほど」金になる、って構図なんだ(笑)。逆に、頂点、つまり数学に近づけば近づく程「金にならん」(笑)。
言っちゃえば「理学」より「工学」が金になるし、「工学」より(ry
まあでもひょっとしたら究極の楽しみは計算機を使って純粋数学って奴を楽しむ事なのかも知れませんね？
残念(笑)!それは純粋数学じゃなくって応用数学だ(笑)!
Great Hackersゴミを拾って来て動いて喜ぶってのが親近感あったので
ああ、これもポール・グレアムのエッセイだな。
Macintosh SE。初代Mac、Fat Mac、Mac Plusと来て四代目のMacintosh。ここでデフォルトでの搭載RAMが2Mbyteとかなったんじゃないかうろ覚えだけど。日本だとこれだけで40万円、とか80万円とか、そんな価格だったような気がする(値段に差がありすぎ、って思うだろうけど、これが初めてHDD内蔵を考慮したMacだったんじゃないか・・・HDDが高かったんだよ)。ちなみに、これ以前だと筐体は白、と言うよりどっちかっつーとベージュ掛かっていたが、Mac SEで白くなり、ちと筐体が角ばってシャープになる。しかし、4代続けてCPUはモトローラの68000で(つまり、基本的にはSHARP X68000と同じだ)、CPU自体の速度は変わらないけど、回路周りが良くなっている。そして後、Macintosh Classicで復活はするが、「1年毎の連作として」68000が採用された最後のマシンだ。
でも当時の?アメリカのプログラミングやってた学生にはフツー、Macintoshってウケが悪かったんだよ(笑)。ポール・グレアムの感性はやっぱりかなり独特だ(笑)。
Macintoshって今で言うとAPIの塊で、そのテのツール使用をプログラマに「強制させる」初めての民生機だったのね(笑)。今じゃそういうの当たり前だけどさ。メーカーがOS積んで、「OSに積まれてるライブラリを使ってください!」ってのを強制する、と。
そういうのって当時の「MS-DOSを主戦場に」つまり、出来れば良い成績取ってマイクロソフトに勤めたい、とか考えてる学生にはウケが悪かった(笑)。MS-DOSってAPIらしいAPI提供しなかった?みたいで、プログラムする側の裁量がデカい、っつーか、当時は「自由度が高い」って印象だったらしいの。「何でもコントロール可能だ!」ってのが当時の「プログラマ志望の学生」には魅力的だったみたい。Macは逆に「やることに制限をかける」って印象で好まれてなかったみてぇなんだよな。
大体、Macって当時はアメリカの市場だと「シリアスなアプリケーションがない、ビジネスじゃ使えないおもちゃ」って印象なんだよ。ハリウッド映画だと良くMac出てたけどさ。Appleの映画会社を使った宣伝で。
アーノルド・シュワルツネッガー主演のKindergarten Cop(1990年)。シュワちゃんの後ろに鎮座しているパソコンはMacintoshじゃなくって、恐らくApple II gs。小中学校だとApple IIが支配的だったが、ぶっちゃけgsは失敗してる。いずれにせよ、こうやって「ハリウッド映画」ではApple製品が割に良く登場する。なお、CPUはスーパーファミコンと同じMOS65816を採用。
ご存知、スピルバーグのJurassic Park(1993年)。Jurassic Parkの中ではたくさんのApple Macintoshが動いてる。なお、同映画では、CGを実際制作したCGマシン、シリコン・グラフィックスの機械の登場率も高い。映画のラストシーン近くで、女のクソガキが「わたし、UNIXなら使えるわ!」と言って向かった先のコンピュータがシリコン・グラフィックス製マシンだ(そしてシリコン・グラフィックスは確かに「UNIXマシン」だ)。なお、シリコン・グラフィックスを知らない人の為に捕足しておくと、任天堂のNintendo 64の開発協力会社で、現在では、プログラミングで3Dグラフィックを扱うライブラリ、OpenGLの開発元だった。また、初代プレイステーションのCPU、R3000を開発したMIPSテクノロジーは、シリコン・グラフィックスの子会社だった。
いずれにせよ、ホンマ、ポール・グレアムの感性って独特だわ(笑)。まぁ、アメリカでは売れた機械ではあるんだけど、最初のパソコンはTRS-80でした、とかさ(笑)。Apple IIじゃなかったんかい、とか(笑)。何か色々「ハズす」、っつーかそういう人ではある(笑)。
とするとコンピュータももっと根本のメモリとか機械語とかの仕組みを知っておいた方が良いのやろか・・って考えを持つのは邪道かな。
いや、邪道じゃないです。「教養として」知っておくのはイイことだと思うし。
でも、上に書いたけど、「直接ハードウェアを組み上げる」のでもないのなら(昔はそれも「アリ」だったけど、今だとパーツさえ「パッケージ化」してるんで、ハンダ片手に・・・とはイカん)、やっぱまずはBrainfuckを実装してみる事をオススメします。
マジで、Brainfuck実装だと色々と学べます。間違いない。
と言う辺りかな、今回は。
※1: Coroutineに関してはSchemeを既に触ってるんで除外する・・・っつーかここでも「継続」が出てきて、結果、どのくらい広く「Lisp言語族」が「抽象度」って意味では各パラダイムに対応してるのか良く分かると思う。
Coroutineの継続での実装に関しては、例えば紫藤のページに例が載っている。
ただし、「COBOLに合わせた文法」をSQLが採用した為に、「COBOLが廃れちまった」せいで、モダンな言語からSQLを介してデータベースを操作する事が苦行になっちまった。
反面、Prologを触れば、Prologの記述力がクエリとしても如何に優れてるのか、と言うのを実感する事となるだろう。
※3: Prologのフリー実装ではSWI-Prologが有名。オンライン版もある。
なお、現在では日本では、殆どユーザーがいないマイナー言語化したPrologだが、かつて(1980年代)ではLispと人気を二分した古典的人工知能研究用言語だった。
また、その当時はユーザー数も多く、JIS(日本産業規格)で言語標準規格が制定された程のメジャー言語(つまり、CやC++に匹敵する程の人気度)だった(2024年現在では失効してる)。
※4: LinuxでもC#のプログラミングは既に可能になってる。
ただし、Debian系ディストロだと、Chicken Schemeと言う処理系のcsc(Checken Scheme Compiler)と言うコマンド名とC#のcsc(C Sharp Compiler)と言うコマンド名が全く同じで、要はコンフリクト(名前の衝突)が起きていて、全くこの「バカな」状態が解決されてないんだ。
結果、Schemeを愛用してる僕の立場だとC#コンパイラが入れられない、と言うしょーもない状況が長い間続いてるわけだ(笑)。
んで、「泣く泣く」C#を使ってみるのを諦めてるわけだ。
※5: ロジックは初心者向けで簡単でも、C言語だと題意的にはeditlineライブラリやGLibを使わなきゃこの程度のプログラムも書けない、ってのが間接的にまたもや「C言語はプログラミング初心者には向かない」証明になっている。
なお、コンパイルは、例えば
gcc -Wall -o foo foo.c -ledit $(pkg-config --cflags --libs glib-2.0)
のようにして行う。
※6: 類似の方法で、「新しくプログラミング言語を学ぶ度に」それでLisp処理系を書く、ってやってきたのが「魔法言語リリカル☆Lisp」のLispエンジンの作者、zick氏だ。
この人、このリリカル☆Lispを作ってた時って多分京都工芸繊維大学の学生さん、だったと思うんだけど、「新しくプログラミング言語を学ぶ」度にLispをそれで書く、ってのを繰り返してたらしい。天才っぽいし、実際天才だろうけど、「天才っぽい非常識でマニアックな行動をしてた」なんじゃなくって、「言語を使いこなすようになる」には理にかなった方法論なんだよな、実は。
「言われてみりゃその通り」なんだけど、天才と凡才の「違い」ってのは、そういう「学習効率性に気づく」か否か、って辺りであって、それで言うとこの人はまさしく「天才」だろう。
なお、このzick氏、例えばニコニコ動画用のニコスクリプト、なる言語でさえLisp処理系を書いちゃう、って凄い事をしている(本人は学習過程のつもりだったんだろうが・・・・・・)。
まぁ、それでも「Lisp処理系を作る」のはBrainfuckインタプリタを実装するより骨だし、Brainfuckの方がLispより遥かに小さい。
そんなわけで、我々凡人にはBrainfuckインタプリタ実装の方が適してるだろう。
