Design and Research
デザインとリサーチ ---Design and Research--- Paul Graham, January 2003. Copyright 2003 by Paul Graham. これは、Paul Graham：Design and Research を、原著者の許可を得て翻訳・公開するものです。 <版権表示> 本和訳テキストの複製、変更、再配布は、この版権表示を残す限り、自由に行って結構です。 (「この版権表示」には上の文も含まれます。すなわち、再配布を禁止してはいけません)。 Copyright 2003 by Paul Graham 原文: http://www.paulgraham.com/desres.html 日本語訳：Shiro Kawai (shiro ＠ acm.org) <版権表示終り> Paul Graham氏のエッセイをまとめた『ハッカーと画家』の 邦訳版が
ハッカーと画家 Hackers and Paintersの翻訳公開
ハッカーと画家 ---Hackers and Painters--- Paul Graham, May 2003 Copyright 2003 by Paul Graham. これは、Paul Graham：Hackers and Painters を、原著者の許可を得て翻訳・公開するものです。 <版権表示> 本和訳テキストの複製、変更、再配布は、この版権表示を残す限り、自由に行って結構です。 (「この版権表示」には上の文も含まれます。すなわち、再配布を禁止してはいけません)。 Copyright 2003 by Paul Graham 原文: http://www.paulgraham.com/hp.html 日本語訳：Shiro Kawai (shiro ＠ acm.org) <版権表示終り> Paul Graham氏のエッセイをまとめた『ハッカーと画家』の 邦訳版が出版されました。
What You Can't Say
口にできないこと ---What You Can't Say--- Paul Graham, January 2004 Copyright 2004 by Paul Graham. これは、Paul Graham：What You Can't Say を、原著者の許可を得て翻訳・公開するものです。 <版権表示> 本和訳テキストの複製、変更、再配布は、この版権表示を残す限り、自由に行って結構です。 (「この版権表示」には上の文も含まれます。すなわち、再配布を禁止してはいけません)。 Copyright 2004 by Paul Graham 原文: http://www.paulgraham.com/say.html 日本語訳：Shiro Kawai (shiro ＠ acm.org) <版権表示終り> Paul Graham氏のエッセイをまとめた『ハッカーと画家』の 邦訳版が出版されました
ものつくりのセンス ---Taste for Makers---
ものつくりのセンス ---Taste for Makers--- Paul Graham, February 2002. Copyright 2002 by Paul Graham. これは、Paul Graham：Taste for Makers を、原著者の許可を得て翻訳・公開するものです。 プロジェクト杉田玄白正式参加テキスト。 <版権表示> 本和訳テキストの複製、変更、再配布は、この版権表示を残す限り、自由に行って結構です。 (「この版権表示」には上の文も含まれます。すなわち、再配布を禁止してはいけません)。 Copyright 2002 by Paul Graham 原文: http://www.paulgraham.com/taste.html 日本語訳：Shiro Kawai (shiro ＠ acm.org) <版権表示終り> Paul Graham氏のエッセイをまとめた『
What You'll Wish You'd Known 知っておきたかったこと
知っておきたかったこと --- What You'll Wish You'd Known Paul Graham, January 2005 Copyright 2005 by Paul Graham. これは、Paul Graham：What You'll Wish You'd Known を、原著者の許可を得て翻訳・公開するものです。 <版権表示> 本和訳テキストの複製、変更、再配布は、この版権表示を残す限り、自由に行って結構です。 (「この版権表示」には上の文も含まれます。すなわち、再配布を禁止してはいけません)。 Copyright 2005 by Paul Graham 原文: http://www.paulgraham.com/hs.html 日本語訳：Shiro Kawai (shiro ＠ acm.org) <版権表示終り> Paul Graham氏のエッセイをまとめた『ハ
なぜ衛生的マクロか (Gauche ユーザリファレンス)
5.1 なぜ衛生的マクロか Lispのマクロは、ソースコードをプログラムによって変換するものです。 マクロ変換器(macro transformer)が、ソースコードの部分木を受け取り、 加工したソースコードの部分木を返します。 伝統的なLispマクロでは、入力となるソースコードも、出力されるコードも、単なるS式でした。 Gaucheはそのタイプのマクロもdefine-macro形式でサポートしています。 例えば、whenは伝統的マクロで次のとおり書けます。 このマクロが(when (zero? x) (print "zero") 'zero)のように使われたとすれば、 上記の変換器はそれを(if (zero? x) (begin (print "zero") 'zero))と 書き換えます。一見問題なさそうですね。 けれども、beginやifが通常とは違う意味で束縛されている環境で wh
Gauche - A Scheme Implementation
Gauche(ゴーシュ)は、スクリプトインタプリタとしての使い易さに重点を置いて 開発を行っているR7RS準拠のScheme処理系です。日常業務の中でのちょっとした処理を行う スクリプトを気軽にSchemeで書きたいなあ、という願望のもとに、 起動が速いこと、システムへのアクセスが組み込まれていること、 最初から多国語対応を考慮していること、 リスト処理ライブラリとして他のC/C++プログラムから簡単にリンク可能であること、 などを目標としています。 Gaucheは多くのUnix系プラットフォーム およびWindows上で動作します。 実装されている機能の概要については、 機能のページをご覧ください。 News 詳しい変更はChangeLogをどうぞ。 また、最新の開発状況はGitリポジトリで知ることができます。 2024/1/25 Gauche 0.9.14 リリースノートを参照してくだ
Practical Scheme
Shiro Kawai まだ下書き Schemeの特徴をあげるときに、「継続」や「call/cc」が出て来ないことはない。 でも、R5RSのcall/ccの項をいくら読んでも、どうもよくわからない。 call/ccを使えばC言語のbreakみたいなのとか、コルーチンとかいう スレッドもどきとかが書ける、というのはわかったけど、一体そういうのが書けて 何が嬉しいのか、そこんとこがピンと来ないんだ。 今、そこにある継続 プログラミングの世界の概念には、禅の公案のようなものがある。 それを説明する文章はほんの一文なのに、最初に目にする時、 その文は全く意味をなさない、暗号のように感じられる。 だがひとたびその概念を理解すると、 その概念の説明は確かにその一文で説明されているのがわかるのだ。 そんな、「分かれば分かる」という禅問答の中でも 「継続」は最も謎めいたものの一つと言えるだろう。 文献を紐
Great Hackers
素晴らしきハッカー ---Great Hackers--- Paul Graham, July 2004. Copyright 2004 by Paul Graham. これは、Paul Graham：Great Hackers を、原著者の許可を得て翻訳・公開するものです。 <版権表示> 本和訳テキストの複製、変更、再配布は、この版権表示を残す限り、自由に行って結構です。 (「この版権表示」には上の文も含まれます。すなわち、再配布を禁止してはいけません)。 Copyright 2004 by Paul Graham 原文: http://www.paulgraham.com/gh.html 日本語訳：Shiro Kawai (shiro ＠ acm.org) <版権表示終り> Paul Graham氏のエッセイをまとめた『ハッカーと画家』の 邦訳版が出版されました。 出版社の案内ページ
The Other Road Ahead
もうひとつの未来への道 ---The Other Road Ahead Paul Graham, September 2001 Copyright 2001 by Paul Graham. これは、Paul Graham：The Other Road Ahead を、原著者の許可を得て翻訳・公開するものです[訳註1]。 <版権表示> 本和訳テキストの複製、変更、再配布は、この版権表示を残す限り、自由に行って結構です。 (「この版権表示」には上の文も含まれます。すなわち、再配布を禁止してはいけません)。 Copyright 2001 by Paul Graham 原文: http://www.paulgraham.com/road.html 日本語訳：Shiro Kawai (shiro ＠ acm.org) <版権表示終り> Paul Graham氏のエッセイをまとめた『ハッカーと画家』の
Shiro:OvenPC
一応スペック。 CPUはZ80A (クロック4MHz) だったと思うけど、途中でB (6MHz) にしたかも。 RAMは最終的に256KB積んでいた。BIOSでバンク切替えして、 通常は192KBをRAMディスクとして使っていた。あとドライバを組み込んだ32KBのROMも バンク切り替え。メモリ最上位のスタブルーチンを呼ぶとROMバンクに切り替えて ドライバに制御が渡る。カーネルモードとユーザモードの切り替えみたいなもんだね。 この構造のおかげで、ユーザRAMエリアをかなり広く取れた。 OSはCP/M-80だったけど、全部逆アセンブルして中身を解析し、かなり書き換えて使っていた。 当時学校でUnixを触り始めてそれに憧れていたので、標準入出力のredirectionとか パイプ(MS-DOS時代の疑似パイプね)なんかができるようにしていた。 FDDは5inchの時代。2DDとか2HDとか。
Lisp:よくある正解 - Lispについての正しい認識と、それでもLisperがLispを使う理由
Lispについての正しい認識と、それでもLisperがLispを使う理由 yoriyukiさんのエントリがなかなか 真実を突いていたので、ネタにさせていただきます。 原因のほとんどは経路依存性とかネットワーク効果によるもので、Lisp自体の性質とは無関係だと思います。と言った上で、私が何となくLisp系言語を使わない理由としては、 Too dynamic: 実行時にコードが差し替えられることがすごい利点だ、と言っている人がいましたが、逆に言えば今どのコードが走っているか理解しにくい、という欠点にも繋がる。 Meta programming:S式のおかげでMeta Programmingがしやすいが、Meta Programmingを多用したプログラムは理解しにくい。 動的型付け:利点でもあるけど、特有のバグを引き起こす。 識別子に関数と値の2種類が別々にバインドできる。これは私には非常に美
Lisp:S式の理由
S式は人に優しいか Shiro: Lispの不人気の理由として筆頭に上げられるのが、括弧だらけの 独特の見た目。とっつきにくい、一般的な表記法と違っていてわかりにくい、 等々、様々なことが言われてきました。しかし、 S式を捨てたLispも開発されましたが 流行ったとはいい難く、Lispな人々はいまだに括弧に固執しているかのようです。 S式のメリットをLisperに尋ねれば、エディタがどうの、マクロがどうの、といった 回答が真っ先に返って来ると思うんですが、そういう理屈をいくら理解しても S式がダメな人がS式を好きになったりはしません。どうも、もっと根本的な 感覚に大きな隔たりがあるような気がします。非Lisperから理解しがたい、 Lisperの持つ感覚とはどんなものなんでしょうか。Lisp脳から見た世界は どんなものなのでしょうか。 構文木を人間が書く? S式は言ってみれば言語の構文木そ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Gauche:AOBench
時間的関係 (Gauche ユーザリファレンス)
BugStories
Gauche:text.prettyprint
Gauche:コレクションの探索
Scheme:MOP:パラメタライズドクラス
Shiro:log:2005後半