Cyanを設計した高校生、5カ月で5つの言語を習得
読者の皆さんは、「Cyan」（サイアン）という言語をご存じないかもしれない。Cyanは、Lispのマクロを持ち、Python風のインデントによってブロックを表すプログラミング言語。2008年の春、林拓人という1人の高校生によって設計された。 連載第1回の竹内郁雄氏が「開発」の天才、第2回の五十嵐悠紀氏が「発想」の天才とするならば、今回の林氏は「プログラミング言語」の天才だ。 林氏がプログラミング言語に初めて触れたのは中学3年の夏休み。そこから冬休みまでの5カ月間に、5つのプログラミング言語を習得した。その後もいくつかのプログラミング言語を学ぶ中、林氏の興味はWebサービスなどのものづくりには行かず、ひたすら言語自体へと向かっていった。 高校2年の春、自身でプログラミング言語Cyanを作り上げた。Cyanを設計した林氏は、「U-20プログラミング・コンテスト」（以下、U-20プロコン）で経済
The Other Half of "Artists Ship"
November 2008 One of the differences between big companies and startups is that big companies tend to have developed procedures to protect themselves against mistakes. A startup walks like a toddler, bashing into things and falling over all the time. A big company is more deliberate. The gradual accumulation of checks in an organization is a kind of learning, based on disasters that have happened
You Used Ruby to Write WHAT?!
Ask any programmer what his favorite language is good for and he'll yell, "Everything!" At least until his next favorite language comes along, which is also good for everything. The truth is: Any language that's Turing Complete and supports enough language features can solve any problem. The difference between languages and their usefulness is a matter of degrees of "yak shaving." "Yak shaving" is
O'Reilly Village / オラの村: カーニハンが、ベントレーが、「コードの美しさ」を熱く語る珠玉のエッセイ集、『ビューティフルコード』今春刊行予定！サンプルPDFを公開
カーニハンが、ベントリーが、「コードの美しさ」を熱く語る珠玉のエッセイ集、『ビューティフルコード』今春刊行予定！サンプルPDFを公開 Posted by Editor : 2008-02-03 16:59 「ビューティフルコード」をテーマに、K&R、AWKのブライアン・カーニハン、『珠玉のプログラミング』のジョン・ベントリー、XMLの父ティム・ブレイ、ゲノム解析のジム・ケント、そしてRubyのまつもとゆきひろ氏など、一流プログラマたちが思い入れを語る珠玉のエッセイ集、『ビューティフルコード』（久野禎子、久野靖訳）がいよいよ今春発刊されます。今回、カーニハンの1章とベントリーの3章のPDFを公開いたします。ほかにもSubversion開発者のカール・フォーゲル、『Linuxデバイスドライバ』のグレッグ・クローハートマン、『プログラミング言語SCHEME』のR.ケント・ディヴィグ、『ハッカーの
【レポート】コメントドリブン開発 - コメントを書いてからコードを書くことの効能 | エンタープライズ | マイコミジャーナル
ソースコードにコメントを記載するべきか、どの程度コメントを入れるべきか、どういった内容を書くべきかはプログラミング普遍の議題であって、永遠に解決しない問題の1つのようなところがある。よく言われるのは、短く簡潔で、他人がそのコードを読んだ時に理解を助けるように「なぜ」そのコードをそのように書いてあるのかをコメントとして入れるべきということだ。理にかなっているし、もっとも無難な方法だ。 しかし逆にコメントを書かない方がいいとする考えもある。それはコードとコメントが必ずしも一致していないことがあるからだ。また最初は一致していても、コードに変更を加えていくうちにコメントと内容が一致しなくなり、コメントとコードの不一致が作業ミスの原因になるというものだ。これも一理ある。これを突き詰めれば、コメントをまったく書かなければデベロッパは大量のコードを追って読む必要があり、初期コストは高いかもしれないが結局
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Take note: Take notes! | Summa Blog
http://capsctrl.que.jp/kdmsnr/diary/20071210.html