これがもう通用しないかもしれない。私が最後にスキームで入門CSを教えたときのエピソードをはっきり覚えてる：ファーストクラス関数を紹介した後、クラスで一番優秀な子が私のところに来て、「何が大したことなの？Pythonでもできるじゃん。」って言った。

それは、2年生の時に先生がLOGOで本当に複雑に見える（当時はね）虹の花を見せてくれた瞬間と同じくらいの formative な瞬間だった。彼女は数少ないカラーマッククラシックの一つを持っていて、ただ一つの花びらの道を描く作業をして、2つの値（開始角度と色）を変えた後に同じ「作業」を繰り返すだけだって教えてくれた。小学校でLogoを学んでいる時に再帰の概念を理解した瞬間の感動もよく覚えてる。最近数年間、主に書いてきたコードがEmacs Lispなのは、上の瞬間と無関係ではないと思う。

全てのScheme仕様を圧縮すれば両面に収まることがわかった これはR4RS以前の話だけだと思うよ。十分に圧縮すれば、「戦争と平和」を1ページに収めることもできる。

MITのプログラマーと一緒に働いたことがあるんだけど、彼はSchemeのカリキュラムを自慢してたんだ。でも、実際には一緒に働いた中で一番ダメなプログラマーだった。彼はClojureが大好きで、Pythonの文法についてずっと文句を言ってた。結局、彼の手作りのDatomicベースのシステムが却下されて、突然辞めちゃった。変わった教え方が優位性をもたらすって考えるのは罠だと思う。自分が他の人よりも賢いと思ってる人と働くのは本当にイライラするよ。

そうだね。コンピュータサイエンス学科が学生からよく受けていた不満の一つは、雇用主が使っている言語を学んでいないことだった。

機能型言語は、命令型言語よりもコンピュータサイエンス的なのかな？

コンピュータ工学は独自の分野で、通常は電気工学と一緒に扱われるけど、システムアーキテクチャやデザインに関することが多くて、プログラミングはデバイスのファームウェアみたいな低レベルの部分にしか触れないんだよね。あなたが本当に嘆いているのは、CS教育が職業的なプログラミングに退化していることだと思う。

大学がより職業的になっているのは、学生にとって大学の費用が高くなっているからだよね。そんなにお金を払って大学に行くなら、いい仕事を得るべきだと思う。これは必ずしも悪いことではないけど、研究に進みたい人のためにもっと良い道があればいいなと思う。SML（またはその派生物）が、ラムダ計算や型理論の観点からも、より良い教育用言語になると思うんだよね。

CS学科でこういう切り替えが起こっていたとき、大学院生として私はエリートCS機関での入門クラスでSchemeからPythonに切り替えることを提唱する「運動」の一部だったんだ。（他にも学際的な研究を重視していたけど、それはまた別の話。）当時の私の理由は、1. 広く使われているツールや実践は、学部生が計算について学ぶモチベーションを高めるフライホイールの役割を果たすから。Schemeを学んでも、結局Schemeを学んだだけなんだよね。でも当時Pythonを学んでいれば、PythonのシステムやソケットAPIを使ってラボや個人のLinuxシステムで遊ぶことができた。ウェブの方では、web.pyやFlask（あはは、これは2000年代後半から2010年代初頭の話）で自分を奮い立たせることができた。学生は夏にアプリやツールを作って、計算の「美的」な魅力以上の価値を理解できるようになるんだ。この頃はCS自体があまり権威がなくて、給料も今ほど高くなかったから、SchemeやMMIX、LC3に頭をぶつけていた人たちはEEや機械工学の学科に流れていった。2. 大学院生として、ほとんどのクラスをふるい落とす試験問題を作るのはほぼ簡単だった。特にSchemeが教えられる入門クラスではね。厳密さが問題なら、他の方法でその厳密さを保つのはとても簡単だった。3. 良くも悪くも、多くの学部生は大学院に進むつもりがなくて、私たちのクラスを受けている学部生の中にはコンピュータサイエンスの学生じゃない人も多かった。彼らは電気工学や産業工学の学生で、自分の分野で自動化するために十分なプログラミングを学びたいと思っていたけど、実際の専門分野にもっと興味があったんだ。この数年で私の考えは進化したけど、当時の信念は今でも変わらない。今のPythonの普及を考えると、ますますそう思う。

「コンピュータ工学」は職業的なものじゃないよ。ハードウェアの理論と応用を含む全体のサブスペシャリティなんだ。「プログラミング」は、伝統的には学術カリキュラムの範囲外だった職業的なシフトだよ。期待される結果を出す再現可能なプロセスがなければ、何もエンジニアリングしていないんだ。プログラミングだけではその基準を満たさないよ。

WGUの「コンピュータサイエンス」の修士課程を修了したばかりなんだけど、「コンピュータサイエンス」と言うのはちょっと怖い意味を込めてる。というのも、アルゴリズムとデータ構造のコースとAIのコース（これは非常に高レベルだった）以外は、純粋にエンジニアリングの内容だったから。一つの課題ではAWSを使って何かをデプロイしたり、作成できる「アプリ」のワイヤーフレームを設計したり、HTTPサーバーを一つ書かなきゃいけなかった。ちょっと楽しかったし、早く終わらせられたのは良かったけど、これを「コンピュータサイエンス」と呼ぶべきじゃない。ソフトウェアエンジニアリングと呼ぶべきだと思う。ソフトウェアエンジニアリング自体は悪くないけど、CSとは異なるけど関連していると見ているんだ。

スキームから始めるのは馬鹿げてると思う。Pythonを知ってるけどスキームを知らない卒業生は、コンピュータサイエンスで何かできる可能性がある。スキームを知ってるけどPythonを知らない卒業生は、技術的なレベルでコンピュータを使うことが基本的にできない。選択肢は「Python」か「スキーム + Python」のどちらかだけだ。（もちろん、その時点で自分でPythonを学ぶこともできるけど、自己学習の話をしているなら、全カリキュラムと両方の言語を自分で学べるから、ここでの議論は大学が学生に何を学ばせるべきかということだ。）

Pythonは応用コンピュータ工学を教えるのに優れているけど、基本的には命令型言語の実行可能な擬似コードだからなんだよね。そんなに単純じゃなくて、Pythonは細かくて複雑な高級言語で、非常にアドホックな方法で機能が増えてきたんだ。これが、実際の厳密さにちょっとでも注意を払う方法で教えたり学んだりするのを非常に難しくしている。たぶん、Schemeと同じくらいシンプルで厳密に定義された「ベビーパイソン」のサブセットを作って教えることはできるけど、今のMITの入門コースはそんな風には設計されてないんだよね。

Pythonは応用コンピュータ工学を教えるのに優れているけど、基本的には命令型言語の実行可能な擬似コードだからなんだよね。Pythonはかなり良いマルチパラダイムのサポートを提供していて、SICPの多くの重要な概念を探求するのに絶対使えるよ（確かに、Lisp系のようにメタプログラミングができる言語はないけど、他の言語でASTを操作するには追加のステップが必要だからね）。特に、Pythonのオブジェクトモデルには関数が含まれているから、高階関数も可能だし（実際、mapは組み込み関数で、reduceは以前の組み込みから標準ライブラリに降格されたんだ）。今はもちろん、型ヒントをコードに散りばめるのが流行ってるけど、これは教育的なアプローチにはちょっと邪魔になるね。でも、完全にオプションだし、実行時にはほとんど影響がないから、無視しても全然大丈夫。

同意する。私はスキームを教わったし、後に教えたこともある。Pythonよりもコンピュータサイエンスを教えるのにずっとクリーンで適した言語だった。学生は学期の終わりまでにその言語とその動作を完全に理解できた。スキームは数学に近いから、コーディング経験のない強い数学者を教えるのに適していた。それに、ハッカーたちをより厳密にし、「これをやって次にあれをやる」という命令的な考え方から彼らの思考を広げることにもつながった。スキームを最初に教わった人たちと、Pythonを最初に教わった人たちの間には顕著な違いがある。もちろん、どちらもその後PythonやFPなどを学ぶことができるけど、その基礎がなければ、ほとんどの人にとって本当に素晴らしいコーディングを教えるのは難しい。

これはこの分野の多くの亀裂の一つで、一般的な議論を難しくしているんだ。自分を「Xプログラマー」と考える人（YやZも含めて）や、そういう人を探しているマネージャーや企業がいる。一方で、自分をソフトウェアエンジニアだと思っている人たちもいて、言語はあまり重要じゃない（そういう人を雇う企業も）。この二つのグループが互いに話が噛み合わないことがよくあるよね。

でもこれが問題なんだ。私たちの一流の学術機関は、大手テック企業のための職業訓練プログラムとして存在するべきじゃない。むしろ、テクノロジーは大学の中ではまだマシな分野の一つだと思う。歴史や文学のプログラムを見れば、これがどこに向かっているかがわかる。最近の文学専攻の学生は、ほとんど本を読まないんじゃないかな。50年前には、週に何百ページも読むことが求められていたのに、4年間ずっと続いていたんだ。正直言って、もし大学がただの社会的シグナルのために学位証明書を印刷するだけなら、今すぐ大学を閉じた方がいいと思う。

スキームでの入門コースを受けたおかげで、コンピュータサイエンスについてたくさん学べたよ。キャリアの中で役立った概念がたくさんある。Pythonではなかなか表現できないし、理解も難しいと思う（Pythonは大好きだけど、ほとんどのプロジェクトや個人のコーディングはPythonでやってる）。

この詳細な説明ありがとう。ちょっとオフトピックなサイドクエスチョン：>学生はそれぞれソフトウェアラジオを手に入れてWi-Fiのようなシステムを構築する予定だった（ソフトウェアラジオは難しかったし、ずっと後になって、私はこれを音響モデムプロジェクトにする手助けをした）。ソフトウェアラジオが難しかった理由は何だったの？

このコメントは明らかにhttps://news.ycombinator.com/highlightsに載るべきもので、これを機にそのサイトが存在することを言及するのもいいかも。ありがとう！（オフトピックでごめんね）

MITの「単位」を3で割った数が、他のアメリカの大学の単位になる。3、4、5単位はそれぞれ9、12、15単位に相当する。一般的に15単位には実験時間が含まれるけど、純粋な実験クラスもある。単位は週あたりの授業時間で、単位は授業時間に宿題を加えたもので、実際にはそれ以上の宿題があるというのが実情。

歴史を教えてくれてありがとう！当時は学部生で、6.001と6.01の選択肢があったのを覚えてる。まだ正式にコース6に切り替えてなかったと思うし、切り替えた時には6.01しか選べなかったな。

15単位のコースが4つあって、それぞれがこれらの「言語」の一つについてだったんだけど、君の説明はちょっと変に感じるな。Lisp系の言語はマルチパラダイム（言ってしまえばパラダイムに依存しない）で、「手続き的」とは呼べないと思う。SICPの核心的な内容は、プログラミング言語が提供する「結合の手段」と「抽象の手段」を考えることに関わっていて、これは「手続き」よりも「構造」や「アーキテクチャ」、「機能性」にもっと関係しているように思う。

この歴史を教えてくれてありがとう、すごく興味深い！その理由はわかる気がするけど、6.001を楽しみで受けた経済学専攻の私としてはちょっと悲しいな。あのクラスは本当に頭が混乱するくらい面白かった。

こんにちは、Keith！もう一つの考慮事項は、基本的なプログラミングスキルをコース6の学生だけでなく、ほぼ全員に教える必要があったことだよ。ソース：私はHalとGerryの隣のオフィスでKeithと一緒に働いてた—彼がJavaを教えてくれたんだ！面白いエピソード：RMSの物を新しいCSAILビルに移動しなきゃいけなかったのは、彼が壁をパンチして腕を骨折したからなんだ。

経済学が何を教えるか、どう教えるかにおいて、教育的な動機と同じくらい、いやそれ以上に重要な役割を果たすことを思い出させてくれるね。出席が減ると、大学は方針を変えられるからね。とにかく人を座らせなきゃ。20年前、Ciscoはオーストラリアでマイクロコードができる電気工学の卒業生を探してたんだ。アメリカの大学は、ほとんどの仕事のためにエッジケースをコーディングする方法を教えるのをやめてしまって、ルーターやスイッチのベンダーはまだそれをやっている場所を探さなきゃいけなかったんだ。

「じゃあ、なんでPythonなの？まあ、サスマンが言うには、ロボティクスインターフェース用のライブラリがすでに実装されてたから、それだけだろうね。」私はレスリー・ケールブリングと同じ「ヌーベルAI」/ロボティクスのグループ出身だった。当時のAIにおける自律ロボティクスはかなり小さなコミュニティで、みんな（少なくともNATOやその友達）は会議やワークショップで顔見知りだった。その頃、そういうロボットシステムのカーネルやインターフェースライブラリを書いてたから、言語選択を決めるのに問題になるほどの労力ではなかった。コミュニティにいた時の私の無知な推測では、教育が物理的な基盤、制御パラダイム、システムに焦点を当てていて、「世界は自分自身の最良のモデル」とか、以前の象徴的推論システムに対する反発があったから、Scheme/Lispは象徴的パラダイムのアイコンだったから排除されたんじゃないかな。そして、新しい「サブシンボリック」の世界では、基本的にデータ/信号の流れやセンサーからアクチュエーターへの相互結合された層状の微分方程式しか見てなかったから、プログラミング言語には全く注目してなかったんだ。

その学部はEECSのコアカリキュラムのアイデアをほとんど廃止してしまった。私の視点からすると、悲劇だね。