Diary-nagataka-シリコンバレーで働きたい!という夢への日々

外資ITで働くエンジニアが趣味や日々の事など書いてます(技術の話は別ブログ http://wanna-be-geek.seesaa.net/ )

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
  1. --/--/--(--) --:--:--|
  2. スポンサー広告
  3. このエントリーを含むはてなブックマーク

MITのCS6.001、schemeからpythonへ

どうも、風呂上がりにRSSをチェック中のながたかです。

MITの名物授業CS6.001といえば、あのschemeですよね!

教科書がwebに公開されているため、以前ワタシは研究室で自主ゼミをやっていた事がありました
http://mitpress.mit.edu/sicp/
(あれ、なんだかグダグダになった気が...リーダーシップが無くてスミマセンw)

その当時ブログにも書いてますね
http://nagataka.blog50.fc2.com/blog-entry-171.html


まぁ、関数型言語を崇拝しておられる(笑)方々がネット上には沢山おられるようで、それを見た俺は興味を持ったわけです、なんだかんだで結構楽しかったかも♪

ところで、そんな6.001なんですが、某ブログで知ったのですが、この度、言語がschemeからpythonに変ったそうです!

なんと!

ちょっと検索してみたら、何やらSussman氏のスピーチを聞いた人が記憶を頼りに内容をブログにupされていた

なので、ちょいと英語の特訓ついでにコイツをザッと訳してみる事にしましたw
(意訳してるトコロは勘弁。そして、普段あまり日本語に訳すという作業をしないため読みづらい日本語になってます...と、予め言い訳をしておくw)

When we conceived of scheme in the 1970’s, programming was a very different exercise than it is now. Then, what generaly happened was a programmer would think for a really long time, and then write just a little bit of code, and in practical terms, programming involved assembling many very small pieces into a larger whole that had aggregate (did he say ‘emergent’?) behaviour. It was a much simpler time.


1970年に私達がschemeを思いついたとき、プログラミングは今とはかなり違うものだった。その当時、一般的に行われていた事というのは、プログラマがかなりの長時間にわたり考え、そして、少しのコードを書くということだった。実際的な言い方をするなら、プログラミングというのは、多くの細かなピースを大きな一つのプログラムへとまとめる行為だった。とても単純だった頃だ。


Critically, this is the world for which scheme was originally designed. Building larger programs out of a group of very small, understandable pieces is what things like recursion and functional programming are built for.


これは、schemeが最初にデザインされた当時の話しだ。とても小さなピースから大きなプログラムを作るために、例えば再帰とか関数型プログラミングが作られた。

The world isn’t like that anymore. At some point along the way (he may have referred to the 1990’s specifically), the systems that were being built and the libraries and components that one had available to build systems were so large, that it was impossible for any one programmer to be aware of all of the individual pieces, never mind understand them. For example, the engineer that designs a chip, which now have hundreds of pins generally doesn’t talk to the fellow who’s building a mobile phone user interface.


世界はもはやそのような状態ではない。ここに至るまでのいくつかの時点において、作られたシステムや、システムを作るために利用可能なライブラリやコンポーネントはあまりに大きく、一人のプログラマにとって、全てのピースを気にかけるのはもはや不可能だ。例えば、チップ(現在においては数百本ものピンを有している)をデザインするエンジニアはふつう携帯電話のユーザーインターフェイスを作るエンジニアの事は話さない。

The fundamental difference is that programming today is all about doing science on the parts you have to work with. That means looking at reams and reams of man pages and determining that POSIX does this thing, but Windows does this other thing, and patching together the disparate parts to make a usable whole.


根本的な違いは、今日のプログラミングは、あなたが関わらなくてはならない事柄に関するすべてについて科学しなければならないという事だ。それは、果てしなく膨大な文書やマニュアルに目を通し、
(...よくわかんない...w)
それらを、一つの利用可能なものいまとめる事を意味する。

Beyond that, the world is messier in general. There’s massive amounts of data floating around, and the kinds of problems that we’re trying to solve are much sloppier, and the solutions a lot less discrete than they used to be.


その上、世界はグチャグチャだ。そこら中に膨大な量のデータがあり、私達が解決しようとしている問題はもうメチャクチャで(かなりの意訳w)、解決策は、以前よりもかなりdiscreteでない。

Robotics is a primary example of the combination of these two factors. Robots are magnificently complicated and messy, with physical parts in the physical world. It doesn’t just move forward along the ground linearly and without interruption: the wheels will slip on the ground, the thing will get knocked over, etc.


ロボティクスはこれらの二つの要素の初歩的な例だ。ロボットは、実際の"モノ"を伴いかなり複雑でゴチャゴチャしている。ロボットは、ただ前に一直線に進むだけじゃない。

This is a very different world, and we decided that we should adjust our curriculum to account for that. So, a committee (here, Prof. Sussman peaked his hands over his head, which I interpreted to indicated pointy-headedness) got together and decided that python was the most appropriate choice for future undergraduate education. Why did they choose python? Who knows, it’s probably because python has a good standard library for interacting with the robot.


全く別の世界だ。なので、私達は、我々のカリキュラムをこれらに適合させる事を決めた。委員会が結成され、pythonが最も学部生の授業にふさわしいと決めたのだ。何故彼らはpythonにしたのか?知らないが、たぶん、pythonはロボットと相互に作用するための良い標準ライブラリを備えていたのではないか。



以上、間違い結構あると思うので、指摘してください~
ってか、ちとこの訳は酷いなw時間を見つけてちゃんと読んで訳し直さないと恥ずかしいカモ...訳が悪いとここまで文意が掴みずらいもんかw


まぁ、原文を読んでください。。

ともあれ、あの強烈に胡散臭い表紙のSICPの教科書はこれからも古典として語り継がれ、そして一部の熱烈なファンはこれからもLispをあがめ続けるのでしょうw

けど、pythonってホント人気なんだなぁ。

言語の差を語れる程の力は無いのでよくわかりませんが。
可読性が良い、か。。
まぁ、そのうち機会を見つけてちゃんと触ってみたいな。



では、最近はバイトでよく使う機会があるため、今さらperlが好きになりつつあるながたかでした~
また明日も頑張りましょう^^
スポンサーサイト
  1. 2009/09/30(水) 02:16:50|
  2. SICP
  3. | トラックバック:0
  4. | コメント:0
  5. このエントリーを含むはてなブックマーク

忘備録

.emacsに以下を追加

(setq scheme-program-name "gosh")

(require 'cmuscheme)

(defun scheme-other-window ()

"Run scheme on other window"

(interactive)

(switch-to-buffer-other-window

(get-buffer-create "*scheme*"))

(run-scheme scheme-program-name))

(define-key global-map

"\C-cS" 'scheme-other-window)


こうすると、二分割したwindowの片っぽでプログラムを書きながら、もう一方で処理系(ワタシはGaucheを使用)を動かしてファイルを読み込んで実行が出来る!

便利やぁ!!

一番感激したのが...Emacsがプログラム中のカッコの対応を点滅して教えてくれる事!
いや~最初っからこの情報を仕入れていればどんなに楽だったでしょうw(まぁずっとこういうサポート機能無しで書いてたから最近は慣れてきて、インデントをちゃんと整えて書くようにして、それを頼りにいくつ末尾にカッコが必要かパッとわかるようになってきてたけど)

使い方

C-c S 別ウィンドウで gauche インタプリタが起動する。
C-c C-l Scheme file のロード
C-x C-e 直前のS式を評価
M-C Space カーソルの次のS式をマーク
M-C-a カーソルを含むトップレベルのS式の先頭へ移動
M-C-e カーソルを含むトップレベルのS式の末尾へ移動
M-C-f 次のS式へ移動
M-C-b 前のS式へ移動


情報はコチラのサイト様で調べさせてもらいました、謝謝^^


あとは、SICPを読んでいてなんとなく印象に残ったトコを一つメモ

We are not at that moment concerned with how the procedure computes its result, only with the fact that it computes the square.


Thus, considering only the values they return, the following two procedures for squaring a number should be indistinguishable. Each takes a numerical argument and produces the square of that number as the value.25

(define (square x) (* x x))

(define (square x)
(exp (double (log x))))

(define (double x) (+ x x))


So a procedure definition should be able to suppress detail. The users of the procedure may not have written the procedure themselves, but may have obtained it from another programmer as a black box. A user should not need to know how the procedure is implemented in order to use it.


今までプログラムを書く上で何気なくそうしてたけど、改めてこうやって文章で書かれているのを読むと、「そうなんだよな~」って思ってしまう。

で、Lispって、上のレベルから関数を定義して行けるから凄い!

例えば、以下はこの教科書に出ているニュートン法実装の例

(define (sqrt-iter guess x)
(if (good-enough? guess x)
guess
(sqrt-iter (improve guess x)
x)))


A guess is improved by averaging it with the quotient of the radicand and the old guess:

(define (improve guess x)
(average guess (/ x guess)))


where

(define (average x y)
(/ (+ x y) 2))


We also have to say what we mean by ``good enough.'' The following will do for illustration, but it is not really a very good test. (See exercise 1.7.) The idea is to improve the answer until it is close enough so that its square differs from the radicand by less than a predetermined tolerance (here 0.001):22

(define (good-enough? guess x)
(< (abs (- (square guess) x)) 0.001))


Finally, we need a way to get started. For instance, we can always guess that the square root of any number is 1:23

(define (sqrt x)
(sqrt-iter 1.0 x))


最初にsqrt-iterを定義する時点では、まだgood-enough?もguessもimproveも何も定義されていないってのが凄い!!
CとかJavaでこれやったらまずここでバシバシ怒られるw

関数定義プロセスを考えてみると、
まずCやらJavaなんかでは
1:何をする関数なのか?(ここではニュートン法によって二乗根を求める)
2:その関数にはどんな値が必要なのか考える
3:その値はどのように得られるのか、得るために必要な関数なり式なりを考える
ここでまた、再帰的に3に対して1を適用して、葉までたどり着いたら下から順番に実装していく。

一方のLispは
1の段階からすぐに実装ができてしまう!
そして、上のプロセスでは一旦一番下まで降りてから実装開始だったけど、降りながら実装ができちゃうってのが凄い!


うろ覚えだけど、誰かが書いた
「Lispは、Lispを使って考えられるトコロが素晴らしいんだ」
というような内容の文章を思い出した。

CやJavaでは、頭の中で考え、時には紙に書き出したりして設計して、概要が脳内に出来上がってからプログラムに落とし込む

一方のLispは、「Lispを使って考える

ただの実装用のプロセスとしてのプログラミングではなくて、考えるtoolとしてのプログラミング言語
というような事をどこかで読んだ気がする。

なんだか、まだまだ俺のレベルじゃぁそんな境地には到達し得ないだろうけど、その一端を見た気がしたこのLispという言語の仕様とprocedural abstractionなのでした。
  1. 2008/02/29(金) 15:15:27|
  2. SICP
  3. | トラックバック:0
  4. | コメント:0
  5. このエントリーを含むはてなブックマーク

λの世界へ

卒論が終わってから、「Structure and Interpretation of Computer Programs」(略してSICP)という本を読み始めた。

(↑のAmazonのレビューは何故か原書に日本語版のレビューがつけられている^^;)

これはMITの教科書で、関数型言語のschemeを使って、タイトル通りComputer ProgramのStructureとInterpretationを紹介している。

なんと原文全文がwebで読めてしまうという何とも親切なMIT^^
http://mitpress.mit.edu/sicp/full-text/book/book.html

読んでるのは原書なので英語です^^;

研究室には日本語訳もあるんだけど、せっかくだから(?)英語版で無理して読んでます(いや~俺ってば見栄っ張りw)

なんでやり始めたかというと...カッコいいからw

だってLispってなんだかミステリアスな感じがするじゃんw

関数型ってなんか頭良い感じするじゃん(こんな事を言っている時点で俺の頭の悪さバレバレorz)

いや、本気で理由を答えると、関数型というプログラミングパラダイムに触れる事で、また新しい視野が得られるし、今までの手続き型やOOPの概念も新しい視野から見られるよ、的な文章をweb上で見たからです。

それにやっぱり、うちのBossをはじめ、関数型ファンというのは沢山いるようで(特にPaul GrahamなんかのLispヨイショぶりは凄い)、「何で?何が魅力なの?」と前々から思っていて、機会があれば触れてみたいと思っていたのです。

で、春休みに何を勉強しようかと悩んでいたんですが(いや、研究はどうしたってw)、選択肢としては
1:Javaでマルチスレッド
2:アルゴリズム
3:C言語中~上級
4:Ajax
5:コレ(SICP)
がありましたが、やはり関数型のミステリアスさ、格好良さ(?)に惹かれコレに決定!(まぁ結局これでアルゴリズムを書いてみたりしたいと思ってるから、選択としては2&5って事になるかな。)

たまたま小飼弾さんがプログラミングの学習として理想的な流れはLisp⇒C⇒etcという事を挙げられていたのも大きいかも(私は流されやすい人間なのです...)

で、久々の関数型なワケでございます。

関数型言語は二年の時に授業でStandardMLというイギリスのエディンバラ大学で開発されたという言語を習いました。

はじめは戸惑ったけど、これのお陰で「再帰」がよくわかるようになった^^

あと、関係があるものとしては、プログラム意味論という教科書を使った授業でλカリキュラスは勉強したか。

けれど、当時の私は「音楽音楽!サークルサークル!」という感じで勉強にはあまり興味を持っていなかったため、せっかくの機会も大分無駄にしてしまっていました。

今現在、この本を読みながら、関数型の不思議な感覚を改めて1から感じ取っているところであります。

現在1.1.7まで読了。

目標は春休み中に1•2章を読み終える事!

しかし今日やった練習問題のうちの一つで、俺が書いたコードよりwebで見つけた模範解答の方が二行短くて条件がスッキリしていて、やっぱり俺って処理を考える上でスマートに考えられていないなぁとガッカリしたorz

どうやったらスマートな考え方が出来るようになるのか。。

こればっかりは、ワタシのような凡人はまずは自分でコードを書いてみて、優れた解答と比較して自分との視点の違いを確認して...というのをひたすら繰り返すしかないのでしょう。


そうそう、さっき某(カリフォルニアで出会った)後輩のブログを覗いていたらなんと、彼は06年に既にこの本を読んで勉強していたようです!

いやぁ、彼には関心しっぱなしですわ^^;

彼は以前「よく、学生のうちに遊んでおけって言う人がいますけど、やりたい勉強を好きなだけできるのって学生のうちが最後じゃないかと思うんです」と言っていた。

それを聞いて本当に感心してしまった。

確かに、社会人になったら、勉強をする時間なんてないのかも。

もしあったとしても、必要な事を勉強するという事になるんだと思う。

今回の俺のように、単純に(何の役に立つのかあまり自分でもわからないし、直接自分の研究には関係ないけれど)興味から何かの勉強に時間を割くというのはしづらくなるんだろうな。

俺は彼のように勉強がデキル人間ではないけど、少なくとも勉強に対するスタンスは見習わないとと奮起しております!

 
で、schemeの話しですが、いつも括弧にイライラさせられています。。

SMLは括弧に煩わされなくて良かったのになぁ。。


まぁとにかく、私はついに(他の言語も大して出来ていないくせに)足を踏み入れようとしております、神の操る言語:Lispの世界へ。

そしてλの世界へ。

Hello λ(lambda) and ... hello so many parenthesis ... orz
  1. 2008/02/24(日) 01:33:12|
  2. SICP
  3. | トラックバック:2
  4. このエントリーを含むはてなブックマーク
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。