2016-05-05

MITがSICPを教えなくなった理由

Programming by poking: why MIT stopped teaching SICP | posterior science

このNYC Lisp meetupの動画で、Gerry Sussmanに対する質問として、SussmanとAbelsonの古典、The Structure and Interpretation of Computer Programs(SICP)に基づく、伝説的な6.001講義をなぜMITはやめたのかと聞かれている。

Sussmanの回答としては、SussmanとHal Abelsonは1980年代から延々と教え続けるに嫌気が差し、1997年に、学部長の事務所に行って、「俺らはやめる。後どうするからは勝手に考えろ」と宣言した。より重要なこととしては、SICPのカリキュラムは、今日のエンジニアリングに求められるエンジニアを育てることができないからである。1980年代と1990年代には、エンジニアは複雑なシステムを組むのに、単純で十分に理解されている部品を組み合わせた。SICPの目的は、そのようなシステムを理解するための抽象的な言語を提供することだ。

今日では、状況が変わっている。今のエンジニアは、自分が完全に理解していない複雑なハードウェアのためのコードを日常的に書いている(そして、大抵の場合、企業秘密により完全に理解するのは不可能である)。ソフトウェアでも状況は同じだ。プログラミング環境は、多大な機能を提供する巨大なライブラリ群の集合として存在している。Sussmanの今日の生徒は、その時間の大半を、ライブラリのマニュアルを読み、どのように組み合わせれば目的が達成できるのかを把握することに費やしている。Sussman曰く、今日のプログラミングは、「より科学に近い。ライブラリを持ち寄って、つっつき回すのだ。プログラムを書くには、突っつき回して、どのように動作するかを観察する。そして、「目的を達成するために改造できるか」と考えるのだ」。SICPの「合成による解析」という物の見方である、小さな、単純な部品を組み合わせて大きなシステムを作るということは、もはや今日の状況にそぐわなくなった。今や、我々のプログラミングはつっつき回すことで行われている。

なぜPythonを選んだかということについて、Sussmanは、"late binding"に決定したと冗談を飛ばした。Pythonには大量のライブラリがあり、教育者の様々な実習に使いやすい(たとえば、ロボットを制御するソフトウェアを書くなど)

Sussmanは、SICPカリキュラムは現在のカリキュラムより洗練されていると考えているものの、正しいカリキュラムのあり方についてはまだ答えが出ていないという。

たしかに、今のプログラマーは、ハードウェアの仕様書を元にを直接操作するコードは書かないし、OSを実装していないし、コンパイラーも実装していないし、古典的なアルゴリズムやデータ構造さえ自分の手で書く必要がなくなっている。ライブラリが発達してその必要がなくなったためでもあり、また個々の機能があまりにも高度になりすぎて、到底一個の人間の手に負える作業量ではなくなったということもある。

不自由なハードウェア、ソフトウェアが蔓延してその詳細がわからなくなり、また自由なソフトウェアであっても、その内容が複雑になりすぎ、一つ一つ完全に理解するには時間が足りなすぎる。

何にせよ、平均的なプログラマーが実現できる機能は昔よりはるかに複雑になっていることは確かだ。

21 comments:

Anonymous said...

それだけにオーダーの計算が甘いということですよね。
3Ghzで動くコンピュータが遅いわけがないのに、まだ強欲にも処理能力を要求する。
レイヤー重ねすぎなのですが、それを覆す決定権のない人は悲惨です。

ほんと3Ghzで動くコンピュータが遅いってやつにPC98のベーシックで開発させたくなります。
N88BASICは偉大でした。

Anonymous said...

Pentium 4ぶつけんぞ!

Anonymous said...

>3Ghzで動くコンピュータが遅いわけがないのに、まだ強欲にも処理能力を要求する。
トマト姫とか一つの画面描くのにすらちんたら描いてたじゃねーか

Anonymous said...

ここまで老害なコメントだといっそ清々しいな
余生はずっと古典BASICで閉じこもってろよ
頼むから外にでてこないくれ

Anonymous said...

老害というのは権力があってこそなんで、
現状を愚痴ったくらいでそんなことを言われる筋合いはないと思う。

Anonymous said...

言ってる内容が害だって話なのに、なんで権力が関係あるんだろう?

例えば老害と同じ内容を、若い人が言ったとして
老人じゃないから問題ないとは思わないでしょう?

権力がなくても老害は老害なわけでw

Anonymous said...

もはや「老害」も歴史的な言葉ということですかね。
「助長」や「敷居が高い」並の。

Anonymous said...

ユーザーの時間はプログラマの時間より貴重だが、それよりも早くリリーススリことが大事だししかたない

Anonymous said...

 責任をユーザーに求めるようになったお気楽な職業のプログラマーですから、金儲けするには一番の職業ですね。

Unknown said...

いろいろな環境が複雑に絡み合っているのが現在の状況である。
そしてそれをすべて把握することは困難かつ不合理である。
って記事じゃないの?
それなのに全責任をプログラマが負えと言うなら、何も出来ない気がするけどね。

例えば家を建てる大工が原料全てに責任をもつかな?
農家が作った野菜に、市販の変な肥料使っていて問題になった時に農家が全責任を負うかな?
会社を作った社長が全社員・全商品の責任を本当に持ってるかな?
これ全部絶対に守れなんて現実的なじゃないと一緒で、プラグラマの責任を過度に求めるのは生産性を下げる。
こんなガッチガッチなこと言ってるから日本のIT活用なりは遅れてビジネス的にも負けまくっているんじゃないかな。

もっとエンジニアが広く視野を持って、やりたいことやるべきことを自由に積極的にやるべきだと思う。
でもプログラム義務教育化で今までの古臭い枠なんて無視されるようになるだろうねきっと。

Anonymous said...

愚痴ったくらいで何が「害」なんだかw

Anonymous said...

これは害悪ですわ。自覚がないのが何より害

Anonymous said...

計算量のオーダーくらい把握してデータ構造やアルゴリズムを選べって話がなんで老害なのか分からないから教えて欲しい。

N88BASICは偉大でしたって部分にみんな反応してるのかな?
そこは元々遅い8bitマシンをますます遅くさせる処理系のおかげで、計算量を考慮せざるをえなかったという話だと思うけど、まあそこは確かに老害部分かもしれんなあ。
当時のBASICを偉大だったとは思わないし。

Anonymous said...

よく分からないんだが
なんで"3Ghzで動くコンピュータが遅いってやつにPC98のベーシックで開発させたくなる"の?

Anonymous said...

全部が全部そうじゃないけど、3GHzで動くコンピュータで遅いプログラム書くような奴の9割方は、まず間違いなく非効率なアルゴリズムを選択しているだろうし(選択しているというよりは何も考えてなくて結果的に非効率なアルゴリズムになっているというのがより正確な表現)、N88-BASICの場合、速度が現代的な環境の千万分の1くらいで目茶遅いので、そういう効率の悪いアルゴリズムとか使ってると全く使い物にならないから嫌でも勉強するようになるんじゃないかって理屈でしょうね。まあ実際にはそんなことは無理だってのはさすがに分かって書いてる筈。

N88-BASIC(86)じゃなくてN88-BASICとあるから、素直に読むとPC-9801じゃなくてPC-8801ってことかもね。

Anonymous said...

「BASICは偉大だった」は老害染みてるけど、前半はその通りのことしか言ってないでしょ

Anonymous said...

何度読み返しても後半が意味不明なのは確か。
老害かどうかは知らないけど。

Anonymous said...

すげえ、お前ら本文の話一つもしてないな!
#1がAPI出したらみんなそれに習うんだな!
感心したわ

Anonymous said...

コメントを見ると第二のスラドだ
#名前を晒したくないのでAC

Anonymous said...

現実を見るとSussmanと同じ気持ちといいますか、考えに賛成です。

サクッと作って、サクッと動かして、
学生たちが「面白い!」と言ってくれるのが楽しい。

学生は面白ければいいんです。
プログラマになるわけじゃないので、
その場その場で楽しいことをやればいいのです。

そのためにはPythonの膨大なライブラリを使って、
げームや機械学習など表面的にすぐに結果のでることを教えるのが最もいいのです。

学生に基礎から教えようとすると大変です。
学生が理解できないし、興味を持てないし、何も勉強できない
ということになってしまうのです。

Pythonでライブラリの使い方をちょっと教えるだけで
お互いに楽しく授業ができて、興味をもてって学習してもらえるので、
Pythonで教えるのが最もいいと思います。

これをママゴトだと言って非難している人がいますが、間違いです。
誰だって子供のころのママゴトからスタートするのですから。

Anonymous said...

まぁ、プログラミングが、面白くなくなってしまった感じはしますね。だって、なんでも簡単なんだもの。ただ、ライブラリがあるってのは、「どうしても何か作らなければならない」って状況では便利ですよ。昔なら、何でもイチからですから。HTMLプロトコル自前で実装したりとか、今の時代やってられません。

これは、ある意味、ソフトウェア開発というものが、民生化した結果と言うことで、考えようによっては喜ばしいことなのでしょう。あらゆる工学的な技術がいつかは民生化するわけで、そうなると当然、教育は実務を意識したものに変わります。時代の流れですね。その分、技術者の給料も安くなります。今の最先端はバイオでしょうか。

ただ、レッドハットでOSのカーネルいじってる連中や、マイクロソフトでなんとか言語の設計などをしている人は、なんだかんだで今でもいるわけで、そういうポストを狙っているのならSICP相当の基礎知識は常識として必要でしょう。いわゆる、「高給取りのプログラマ」にはその手の知識は今でも必要です。大学院レベルの教育ですね。

言い換えるなら「普通のプログラマ」になるために高度な教育が必要だった時代はもう終わったのだとおもいます。なにしろ、Webによってあらゆる情報や技術が、ほとんどタダ同然に手に入りますしね。ライブラリの仕様だって、オンラインでいくらでも見れる。実際、教育機関の存在価値自体がどんどんなくなってきている気がします。

昔の話になりますが、CPUが3GHzどころか、MHzだった時代、「速いプログラム」を書こうと思ったら、BASICでは全然足りませんでしたよ。アセンブラが必要でした。私はグラフィック関連のプログラムが好きだったので、ハードウェアの機能を使わないと、とても実用的な速度が出ない。ところがPC98なんて、ハードウェアの仕様書がどこ探してもなくて(探してたところが間違ってのかもしれませんが)、いろんな情報源から情報を集めながらコードを書かなければなりませんでした。買うにしても、めっちゃ値が張りましたしね。その頃は、やりたいことがあっても性能的な問題で出来ないことの方が多く、それに比べたら今の方がましかなぁと思ってしまいます。プログラミングが科学どころか、職人芸だった時代ですね。Cで書いても遅かったし、メモリもなかった。

楽しかったのは、Pentium 3~4くらいのころだった気がします。このくらいになると、マシンの性能がそれなりにあるので、アルゴリズムの改善で、あっという間に速度が10倍とか20倍になっていました。もう、職人芸的なものはいらなくて(SSEでしたっけ?そういう特殊な命令を使う以外はということですが)、メモリも豊富、コンパイラも賢い。このころから、実装依存のテクニックを知っているプログラマより、ソフトウェア理論を知っているプログラマのほうが早いコードを書けるようになってきたのではないでしょうか。まぁ、このころは仕事でやっていたわけではないので、飽くまで私見ですが。

で、そのあとWebの技術と共にLL言語が普及してきた辺りから、あらゆる分野で「ライブラリ」が充実しはじめるとともに、言語自体が高機能になったせいで、効率など無視してコードを書いてもちゃんと動くようになってきました。そのため、このころは実装技術よりコードをメンテナンスするための技術(リファクタリング、再利用可能なコード、バージョン管理、継続的インテグレーション)が注目されていた気がします。

現在、Webが下火になり、花形は携帯アプリとデータサイエンス。どちらも、プログラミングよりコンテンツや情報技術以外の技能が重要視されている分野です。プログラミング自体も複雑なロジックはライブラリ側に既にあり、それを呼び出すような小さなコードを書くことが多そうですね。そのうち、大規模なコードベースをメンテナンスする、と言うこと自体が過去のものになっていきそうです。

結局、プログラミングというのは「思ったことをコンピューターにやらせる」ために必要な作業(記述法)にすぎません。飽くまでコンピューターを利用するための手段であり、根本的には技術ではないような気もします。もちろん、大規模サービスのサーバーサイドのような仕事もありますが…連中は数少ない高給取りの部類ですからね。

とまぁ、ずいぶん長くなりますが90年代くらいから色々見てきているので、ここ数十年のソフトウェア技術の進歩にはかなりの感銘を受けています。なんか、一番微妙なところに生まれてしまったという気もしますね。技術と言えるほどニッチな時代には、私は生まれてなくて、歳をとる前に、学んだことが不要になってしまうというね。まぁ、どの分野でもそんなもんなのかもしれませんが。