中古品
¥2,482
中古商品: 良い | 詳細
発売元 にゃんこ堂☆
コンディション: 中古商品: 良い
コメント: 中古品のため多少のスレ、クスミ、ヤケ, 折れ等がある場合が御座いますが概ね良好な状態です。表紙カバーが画像と異なる場合がございます。商品の発送は注文確定後3日から4日程度を要す場合がございます。商品状態の詳細についてはAmazonマーケットプレイスコンディションガイドラインをご参照ください。発送前の点検時に問題が発見された場合はメールにてご連絡をさせていただきます。発送方法はゆうメールにて発送致します。商品到着までに、天候等により多少の遅れが発生する可能性も御座います事をご了願います。
この商品をお持ちですか? マーケットプレイスに出品する
裏表紙を表示 表紙を表示
サンプルを聴く 再生中... 一時停止   Audible オーディオエディションのサンプルをお聴きいただいています。
この画像を表示

著者をフォロー

何か問題が発生しました。後で再度リクエストしてください。


On Lisp (日本語) 単行本 – 2007/3/1

5つ星のうち4.5 9個の評価

その他(2)の形式およびエディションを表示する 他のフォーマットおよびエディションを非表示にする
価格
新品 中古品
Kindle版 (電子書籍)
単行本
¥2,000
click to open popover

Kindle 端末は必要ありません。無料 Kindle アプリのいずれかをダウンロードすると、スマートフォン、タブレットPCで Kindle 本をお読みいただけます。

  • iOSアプリのダウンロードはこちらをクリック
    Apple
  • Androidアプリのダウンロードはこちらをクリック
    Android
  • Amazonアプリストアへはこちらをクリック
    Android

無料アプリを入手するには、Eメールアドレスを入力してください。

kcpAppSendButton

商品の説明

出版社からのコメント

読者の方のご参考のために、Web上にある関連リソースを挙げてお
きます。

著者Paul Graham氏のサイト上のページ(原書PDF, コード, 正誤など)

訳者 野田開氏による翻訳草稿(TeX, PDF, HTML)

出版社のカタログ

抜粋

第1章
拡張可能なプログラミング言語
The Extensible Language
遠くない昔,Lisp は何のためのプログラミング言語かと尋ねれば,多くの人が
「人工知能(AI) 用のプログラミング言語」と答えただろう.実際はLisp とAI
との関係は歴史の偶然にすぎない.Lisp の開発者はJohn McCarthy で,彼は
「人工知能」という言葉の提唱者でもある.彼の学生と同僚たちはプログラムを
Lisp で書いた.それがLisp がAI 用のプログラミング言語と言われ出したきっ
かけだ.このつながりは広く取り上げられ,1980 年代の短いAI ブームの間に大
変なほど繰り返されたので,ほとんど迷信のようになってしまった.
幸運なことに,AI だけがLisp の目的でないとの言葉が広まり始めた.最近のハードウェア
とソフトウェアの進歩のおかげで,Lisp は商業的にも成功し始めた:今では最
高のUnix 系テキストエディタGNU Emacs,業界標準のデスクトップCAD ソフト
Autocad,そして先駆的ハイエンド出版ソフトInterleaf で使われている.これ
らのプログラムでのLisp の使われ方はAI とは何も関係ない.
Lisp がAI 用プログラミング言語でないのなら,いったい何なのか? Lisp をその交友関係から
判断するのでなく,言語そのものを見てみよう.他のプログラミング言語ででき
ないことのうち,Lisp には何ができるか? Lisp の最も特徴的な性質の一つ
は,書こうとしているプログラムに合わせてLisp を仕立てることができる点
だ.LispそのものがLisp プログラムであること,Lisp のプログラムはリストと
して表現でき,リストはLisp のデータ構造だということ.これら2 個の原則が
相俟って,組み込みのものと区別のつかないオペレータをどのユーザもLisp に
追加できることになる.
1.1 進化によるデザイン
Lisp では独自のオペレータを
定義する自由がユーザにあるので,Lisp を必要なプログラミング言語にきっち
り仕立てることができる.ユーザがテキストエディタのプログラムを書いている
のなら,Lisp をテキストエディタを書くための言語に変えることができる.ま
たCAD ソフトのプログラムを書いているのなら,Lisp をCAD ソフトを書くため
の言語に変えることもできる.そしてどんなプログラムを書くかまだ確かでない
なら,Lisp で書いておくのが安全な賭けだ.それがどんな種類のプログラムに
なったとしても,それを書いている間に,Lisp はその種類のプログラムを書く
ためのプログラミング言語に進化していることだろう.
どんなプログラムを書く
かまだ確かでないなら? 人によってはこの文は奇妙に響くだろう.これは(1)
これからやることを注意深く計画し,そして(2) それを実行する,というモデル
とは水と油のように相容れない考え方だ.プログラムのすべき動作を決める前に
プログラムを書くことをLisp が勧めているとすれば,このモデルによれば,
Lisp は単に杜撰な考え方を勧めているにすぎないことになる.
だが,そんなこ
とはない.「計画−実装」方式もダム建設や侵略作戦の決行にはいい方法だった
が,人々の経験によればプログラムを書くのにいい方法だったかどうかは定かで
ない.なぜか? きっと,コンピュータは大変正確だからだ.きっと,プログラ
ムはダムや侵略作戦よりもバリエーションが多いからだ.またはきっと,古い
概念における冗長性に相当するものがソフトウェア開発にないせいで,古い方式
が機能しないことによるのだろう:ダムが30% 余分なコンクリートを使っていて
も,それは誤差として許される範囲内だろう.しかしプログラムが30% 余分な動
作をしていたら,それは間違いだ.
古い方式が失敗に終わるのがなぜかを言うの
は難しいかもしれないが,それが確かに失敗しているのは,誰の目にも明らか
だ.ソフトウェアが期日どおりに完成したことがあるだろうか? 熟練プログラ
マは,どれほど慎重にプログラムの計画を立てても,プログラムを書き始める
と,必ず計画にどこか不完全な点が見つかることを知っている.計画が望みのな
いほどまで間違っていることもある.しかし「計画−実装」方式の犠牲者のほと
んどはその基礎の健全さを疑おうとはしない.代わりに彼らは人間の失敗を責め
る:「もう少しいい展望の下に計画を立ててさえいたら,こんな問題はすべて避
けられただろう.」最高レベルのプログラマでさえ実装となれば問題に突き当た
るのだから,人々にそれほどの先見の明を期待するのはどうやら無茶のようだ.
きっと「計画−実装」方式は,我々の持つ限界により適した別のアプローチで置
き換えられるのではないか.
適切なツールがあるならば,プログラミングへの別
のアプローチが可能だ.なぜ実装の前に計画を立てるのか? プロジェクトの立
案にどっぷり浸かり込むことの大きな危険性は,自らを袋小路に追い込んでしま
う可能性がある点だ.もっと柔軟なプログラミング言語があれば,この心配を減
らせるのでは? そのとおり.そしてそういうプログラミング言語がある.Lisp
の柔軟性は全く新しいプログラミングのスタイルを生み出した.Lisp において
は,計画の大部分を立てるのはプログラムを書きながらでいい.
なぜ後知恵が浮
かぶのを待つのか? モンテーニュ?1が気づいたように,考えを明確にするには
それを書き下ろそうとすることが一番だ.自らを袋小路に追い込んでしまうと
の心配からひとたび解放されれば,この可能性を最大限に活用できる.プログラ
ムを書きながら計画を立てる能力は2
つの重要な結果につながる:まず,プログ
ラムを書くのにかかる時間が短くなる.計画を立てると同時にプログラムを書い
ていると,注意を集中すべきプログラムの実物を常に手にしていることになるか
らだ.そしてその方法で出来たプログラムはより良いものになるだろう.プログ
ラムの最終デザインが常に進化の産物として出来上がるからだ.プログラムがあ
るべき姿を探している間に,一つの原則間違っていた部分を,見つけ次第その場
で必ず書き直すを守る限り,最後に出来上がったものは,あらかじめ計画に数週
間を費やした場合よりも優美なプログラムになるだろう.
Lisp が多目的なプロ
グラミング言語だからこそ,この種のプログラミングが実用的な代替手段にな
る.事実,Lisp の持つ最大の危険はLisp がユーザを堕落させてしまうかもしれ
ないことだ.一度Lisp をしばらく使うと,プログラミング言語とアプリケー
ションとの相性に敏感になりすぎ,元々使っていたプログラミング言語に戻って
も,これでは必要な柔軟性が手に入らないという思いに常に囚われるようになり
かねない.
1.2 ボトムアッププログラミング
プログラムの個々の機能的要素をあ
まり大きくしすぎてはならないというのが,プログラミングスタイルの長年の原
則だ.プログラムの構成要素が,読めば理解できる状態を超えて肥大化するな
ら,それは複雑さの塊に成り果て,(大都市が流れ者を隠すように)簡単にエ
ラーを覆い隠す.そういうソフトウェアは読みづらく,テストしづらく,デバッ
グしづらい.
この原則に従い,大規模なプログラムは部品へと分割しなければい
けない.またプログラムが大規模であればあるほど,さらに分割しなければいけ
ない.プログラムを分割する方法とは何か?
伝統的アプローチはトップダウン
デザインと呼ばれる:「このプログラムの目的はこれらの7 個だから,プログラ
ムを7 個の主要サブルーチンに分割することにする.1 個目のサブルーチンはこ
れら4 個のことを行わなければいけないから,それ自身のサブルーチンが今度は
4 個になり,. . . 」といった具合だ.このプロセスはプログラム全体が適切な
粒度すべての部分が意味のある仕事を行えるだけの大きさでありながら,単一の
ユニットとして理解できるくらい小さくなった状態になるまで続く.
熟練Lisp
プログラマがプログラムを分割する方法は違っている.トップダウンデザインと
同様,彼らには従う原則があり,それはボトムアップデザインプログラミング言
語を問題に適するように変えていくと呼ばれる.Lisp
では,プログラムをただ
プログラミング言語に従って書くことはしない.プログラミング言語を自分の書
くプログラムに向けて構築するのだ.プログラムを書いているとき,「Lisp に
○△のオペレータがあればなあ.」と思うことがあるかもしれない.そうしたら
それを書けばいい.後で,新しいオペレータの使用がプログラムの別の部分のデ
ザインを簡潔にまとめることにつながったと気づくだろう.そういった感じでプ
ログラミング言語とプログラムは共に進化する.交戦中の2 国間の国境のよう
に,2 つの境界は何度も書き直される.それが落ち着くのは,山や川(ここでは
ユーザの問題の持つ自然な境界)に辿り着いたときだ.最終的には,ユーザのプ
ログラムではプログラミング言語がそのために設計されたかのような見かけにな
る.そしてプログラミング言語とプログラムが相性良く落ち着いたとき,ユーザ
は明快で小規模で効率的なコードを手にする.
ボトムアップデザインは,同じプ
ログラムをただ別の順番で書くだけのことではないということは,強調しておき
たい.ボトムアップでプログラムを作ると,出来上がるものが違ってくるのだ.
単一の一体となったプログラムではなく,より抽象的なオペレータを持つ大規模
なプログラミング言語と,それで書かれた小規模なプログラムが出来るのだ.
ユーザは戸口に重くかぶさるまぐさ石ではなく,弧を描いて高く立つアーチを手
にする.
典型的なコードでは,瑣末で定型的な処理を一度抽象化すると,残るも
のはずっと短い.プログラミング言語を高く構築すればするほど,トップから降
りてくる道のりは短くなる.これはいくつかの長所をもたらす:
1. プログラミ
ング言語に仕事を任せることで,ボトムアップデザインは小規模で機敏なプログ
ラムを生む.短いプログラムは多数の構成要素に分割する必要がない.そして構
成要素が少ないということは,プログラムが読みやすく修正しやすいものだとい
うことだ.また構成要素が少ないということは,構成要素同士の連結も少ないと
いうことなので,そこでエラーが起きる可能性も少ない.工業デザイナが機械の
可動部分を減らそうと努力するのと同様に,熟練Lispプログラマはボトムアップ
デザインを使ってプログラムの大きさと複雑さを減らそうとする.
2. ボトム
アップデザインはコードの再利用を促進する.プログラムを2 つ以上書くとき,
最初のプログラムのために書いたユーティリティの多くは他のプログラムでも有
用になる.ユーティリティの大規模な基盤を手にしてしまえば,新しいプログラ
ムを書く手間は,Lisp そのもので書かなければならないときにかかる手
間の数分の一にすぎない.
3. ボトムアップデザインはプログラムを読みやすく
する.この種の抽象化に従ったものは,読む人に汎用オペレータを理解するよう
要求する.それに対し機能の抽象化に従ったプログラムは,読む人に特定用途の
サブルーチンを理解するよう要求する1.
4. ユーザにコード内のパターンに常に
関心を払うようにさせる.ボトムアップでの作業はプログラムのデザインに関す
るアイディアを明確にするのに役立つ.一つのプログラムの中で種類の違う2 個
の構成要素が形の上で似ているなら,類似性に気づくよう促されるし,おそらく
単純な方法でプログラムをデザインし直すよう促されるだろう.
ある程度までは,ボトムアップデザインはLisp 以外のプログラミング言語でも可能だ.ライ
ブラリ関数を見ればそこには必ずボトムアップデザインの例がある.しかしLisp
はこの点に関してずっと幅広い力を与え,プログラミング言語がそれに見合った
大きな役割をLisp のスタイルで演じるよう促すその役割があまり大きいので,
Lisp はただのプログラミング言語の一つではなく,全く違ったプログラミング
方法になっている.
このスタイルの開発は,小規模なグループによって書ける程
度のプログラムに適しているというのは確かに真実だ.しかし同時に,このスタ
イルは小規模グループのなし得ることの限界を拡張する.Frederick Brooks が
『人月の神話』(The Mythical Man-Month) の中で示唆したのは,プログラマの
グループの生産性はその規模に対して線形には増大しないということだった.グ
ループのサイズが増大するにつれ,個々のプログラマの生産性は低下してゆく.
Lisp プログラミングの経験は,この法則のポジティブな捉え方を示唆してい
る:グループのサイズが減少するにつれ,個々のプログラマの生産性は向上して
ゆくのだ.相対的に小規模なグループが勝利を収める.理由は単純,小さいか
ら.小規模グループがLisp によって可能になるテクニックを活用するとき,完
全な勝利が待っている.
1 「でも君のユーティリティを全部理解しないことには
プログラムが読めなくなるじゃないか.」そういった言葉は大抵誤りだ.なぜか
については,4.8 節を参照.
1.3
拡張可能なソフトウェア
Lisp スタイルのプロ
グラミングは,ソフトウェアが複雑さを増すにつれ重要性を増してきた.今時の
ユーザからのソフトウェアへの要求はあまりに多く,プログラマにはほとんど予
想しきれない.ユーザ自身も要求のすべてを予想することができなくなってい
る.しかしユーザの望みを完璧に叶えるソフトウェアをプログラマが供給できな
くとも,プログラマには拡張できるソフトウェアを供給することはできる.プロ
グラマが自分のソフトウェアをただのプログラムからプログラミング言語に転換
すれば,技術の高いユーザは必要な付加的機能をその上に作り上げられる.
ボト
ムアップデザインは拡張可能なプログラムに自然につながっていく.ボトムアッ
ププログラムの最も単純なものは,2 層から成る:プログラミング言語とプログ
ラムだ.複雑なプログラムも一連の層として書き上げることができる.それぞれ
の層は1
段下の層に対してプログラミング言語として機能する.この方針が最
上層まで貫かれれば,その層がユーザの使うプログラミング言語となる.そのよ
うなプログラムではあらゆるレベルで拡張が可能になっていて,伝統的なブラッ
クボックスとして書かれ,後から拡張性を付け加えたシステムよりもはるかにい
いプログラミング言語が出来上がることが多い.
X Windows とTEX はこの原則に
基づくプログラムの古い例だ.1980 年代には高性能のハードウェアによって
Lisp を自らの拡張言語とする新世代のプログラムが可能になった.その最初は
有名なUnix のテキストエディタ,GNU Emacs だ.次はAutocad で,これはLisp
を拡張言語とする大規模商用製品としては初になる.1991年にはInterleaf の
新バージョンがリリースされたが,それはLisp を拡張言語に使っていただけで
はなく,かなりの部分がLisp で実装されていた.
Lisp は拡張可能なプログラム
を書くためには素晴らしくいいプログラミング言語だ.それはLisp 自身が
拡張可能なプログラムであるからだ.Lisp の拡張性をユーザにも渡すような
Lisp プログラムを書けば,実質的には何もせずに拡張言語が出来たことにな
る.そしてLisp でLisp プログラムを拡張することと,伝統的なプログラミング
言語でそれを行うこととの違いは,誰かに直接会うことと手紙でやりとりするこ
ととの違いのようなものだ.外部プログラムへのアクセス手段を提供するだけの
拡張方法しか用意していないプログラムでは,あらかじめ決められたチャンネル
を通じて連絡し合う2 つのブラックボックスになるにすぎない.Lisp では,
拡張機能は背後にあるプログラム全体に直接アクセスできる.ユーザにプログラ
ムのあらゆる部分へのアクセスを与えなければならないと言っている訳ではな
い.ただアクセスを与えるか与えないかをあなたが選べるということだ.
このレ
ベルのアクセスがインタラクティブな環境と結び付くと,最高の拡張性が得られ
る.自分のプログラムの拡張機能の基礎として使えるようなプログラムは,どれ
もかなり大規模になりがちだ.おそらく規模が大きすぎて全体的なイメージが掴
めないほどだろう.何か不確かな点があるときどうなるだろう? そのとき元の
プログラムがLisp で書かれていれば,それをインタラクティブに調べることが
できる:データ構造を調査できる.関数を呼び出せる.ソースコードを読むこと
さえできる.この種のフィードバックにより,確かな自信を持ってプログラムを
製作できる.思い切った拡張機能を書けるし,しかもそれが素早くできる.イン
タラクティブな環境は常にプログラミングを容易なものにしてくれるが,拡張機
能を書いているときほどそれがありがたいときはない.
拡張可能なプログラムは
諸刃の剣だが,最近の経験によればユーザはただの剣より諸刃の剣のほうを好
む.どんな危険性が備わっていようとも,拡張可能なプログラムのほうが勝るよ
うだ.
1.4 Lisp の拡張
Lisp
に新しいオペレータを加えるには2 通りの方法があ
る:関数とマクロだ.Lispではユーザの定義した関数は組み込み関数と同じ地位
を占める.もしmapcar の変種が新しく必要になったら,それを自分で定義し,
mapcar を使うのと同じようにそれを使うことができる.例えば,ある関数が1
から10 までの整数に適用されたときにそれが返す値のリストが必要なら,新し
いリストを作ってそれをmapcar に渡すことができる:
(mapcar fn

(do*
((x 1 (1+ x))

(result (list x) (push x result)))


((= x 10) (nreverse result))))
しかしこの方法は格好悪いし非効率だ2. 代わ
りに新しいmap 系関数map1-n(p. 55参照)を定義し,それを次のように呼び出
せばいい:
(map1-n fn 10)
関数を定義するのは比較的真っ当な方法だ.マクロは
新しいオペレータのさらに一般的な(しかしあまり理解されていない)定義
方法を提供する.マクロはプログラムを書くプログラムだ.この文には非常に深
い意味が込められている.そしてその探求はこの本の主目的の一つなのだ.
マク
ロを注意して使えば驚異的に明解でエレガントなプログラムができる.もちろ
ん,これらの宝石のようなプログラムがただで得られる訳ではない.最後にはマ
クロは世界で一番自然なものに思えるだろうが,最初は理解が難しい.これはマ
クロが関数よりも一般的で,書くときに注意すべきことが多いせいもある.しか
しマクロの理解が難しい大きな理由は,それが全く異質(foreign) なものだから
だ.Lisp のマクロのようなものを持つ言語は他にない.だからマクロを学ぶに
は,他のプログラミング言語から気づかずに学んだ先入観を振り捨てることを
要求されるかもしれない.そのなかの主要なものは,死後硬直に悩まされるプロ
グラムという概念だ.なぜデータ構造が流動的で変更可能であるべきなのに,プ
ログラムがそうであってはいけないのだろうか? Lisp ではプログラムがデータ
であるのだが,この事実の持つ意味をモノにするにはしばらく時間がかかる.
2 これは新しいCommon Lisp のシリーズマクロを使ってもっとエレガントに書くこ
ともできる.しかしこれらのマクロ自体がLisp の拡張なので,結局は同じこと
だ.
マクロに慣れるのにしばらく時間がかかっても,それは努力に見合うこと
だ.繰り返しのようなありふれた用途でも,マクロはプログラムを抜群に小型で
きれいなものに変える.ここで,あるプログラムがコード本体をx についてa か
らb まで繰り返さなければならないとしよう.Lisp 組み込みのdo はもっと
一般的な目的のためのものだ.それを単純な繰り返しに使うと一番読みやすい
コードにはならない:
(do ((x a (+ 1 x)))

((> x b))
(print x))

れを,こう書けるとしたらどうだろうか:
(for (x a b)
(print x))
マクロがこ
れを可能にする.6 行のコードで(p. 159 参照)for
文をこのプログラミング
言語に追加できる.そしてそれは初めからあった構文のように機能する.後の章
で見るように,for
の実装はマクロでできることの手始めでしかない.
Lisp の
拡張で一度に使えるのは関数やマクロ1 個ずつに限られる訳ではない.必要とあ
ればあるプログラミング言語全体をLisp の上に構築し,それを使ってプログラ
ミングすることもできる.Lisp
はコンパイラやインタプリタを書くのに最適の
プログラミング言語だが,新しいプログラミング言語を定義する別の方法を提供
する.そのほうがしばしばエレガントだし,労力が少なく済むのは確かだ:それ
はLisp
を修正して新しいプログラミング言語を定義する方法だ.そうすれば
Lisp
の機能のうち新しいプログラミング言語でも変更せずに使える部分(例え
ば算術演算やI/O)はそのまま利用でき,異なっている部分(例えば制御構造)
だけ実装すればいい.このように実装されたプログラミング言語を埋め込み言語
と呼ぶ.
埋め込み言語はボトムアッププログラミングの自然な帰結だ.Common
Lisp には既にいくつか例がある.一番有名なCLOS については後の章で議論す
る.しかし自分だけの埋め込み言語を定義することもできる.自分のプログラム
に適した埋め込み言語を作ることができ,それをLisp とかけ離れたものにする
ことさえ可能だ.
1.5 なぜ(またはいつ)Lisp か
これらの新たな可能性は
魔法の要素たった1 個から生まれる訳ではない.この点を見れば,Lisp はアー
チのようなものだ.楔形の石(迫石?2)のうち,どれがアーチを支えているの
か? これは質問そのものが誤っている:どの石もアーチを支えているのだ.
アーチと同様,Lisp は組み合わさった機能の集合体だ.それらのいくつかをこ
こで挙げることができる動的メモリ割り当てとガーベジコレクション,実行時
型指定,オブジェクトとしての関数,リストを生成する組み込みパーサ,リスト
として表現されたプログラムを受け付けるコンパイラ,インタラクティブな環境
等々しかしどの一つをとってもLisp の持つ力の理由にはならない.Lisp プログ
ラミングをLisp プログラミングたらしめているのは,そのコンビネーション
だ.
過去20 年でプログラミングの方法は変化した.インタラクティブな
環境,動的リンク,オブジェクト指向プログラミングまでこれらの変化の多く
は,Lisp の柔軟性を幾分かでも他のプログラミング言語に与えようとする細切
れの試みだった.アーチの喩えは,それらがどれほど成功を収めたかを示唆して
いる.
Lisp とFortran が現存するプログラミング言語のうち最も古いものだと
いうことは,よく知られている.おそらくもっと意味のある事実は,それらはプ
ログラミング言語のデザインの思想のうち対極にあるものを代表しているという
ことだ.Fortranはアセンブリ言語からの進歩として開発された.Lisp はアルゴ
リズムを表現するプログラミング言語として開発された.そういった異なる意
図は,大きく異なるプログラミング言語を生んだ.Fortran はコンパイラ開発者
の人生を楽にしてくれる.Lispはプログラマの人生を楽にしてくれる.そ
れ以来,大抵のプログラミング言語は2 つの極の間のどこかに位置するものだっ
た.そしてFortran とLisp は真ん中に向かって歩み寄ってきた.Fortran は今
ではずいぶんAlgol に似てきたし,Lisp は若かりし頃の無駄な習慣をいくつ
か諦めた.
最初のFortran とLisp は一種の戦場のようなものを定義した.片方
では鬨の声は「効率~!(それに実装が大変すぎるだろうし)」で,もう片方で
は鬨の声は「抽象化~!(これは商用ソフトじゃないし)」だ.古代ギリシャ
の戦争の結果を神々が高みから決めたように,この戦の結果はハードウェアに
よって決められるようになっている.年を追うごとに情勢はLisp
側に有利に
なってきているようだ.今ではLisp に対する議論は,1970
年代初頭にアセンブ
リ言語プログラマたちが高水準プログラミング言語に対して仕掛けた議論に非常
に似てきた.今や問いはなぜLisp か? ではなくいつLisp か? になっている.
*2 訳注:voussoir: アーチや丸天井に使われる楔形の石材.


登録情報

  • 単行本: 440ページ
  • 出版社: オーム社 (2007/3/1)
  • 言語: 日本語
  • ISBN-10: 4274066371
  • ISBN-13: 978-4274066375
  • 発売日: 2007/3/1
  • 梱包サイズ: 21 x 15 x 2.8 cm
  • カスタマーレビュー:
  • Amazon 売れ筋ランキング: 本 - 254,404位 (本の売れ筋ランキングを見る)
  • さらに安い価格について知らせる
    この商品を出品する場合、出品者サポートを通じて更新を提案したいですか?

  • 目次を見る

カスタマーレビュー

5つ星のうち4.5
星5つ中の4.5
評価の数 9
星5つ
65%
星4つ
24%
星3つ
11%
星2つ 0% (0%) 0%
星1つ 0% (0%) 0%
Amazonは星評価をどのように計算しますか?

この商品をレビュー

他のお客様にも意見を伝えましょう
2018年4月13日に日本でレビュー済み
形式: 単行本Amazonで購入
1人のお客様がこれが役に立ったと考えています
コメント 違反を報告
2014年3月5日に日本でレビュー済み
形式: 単行本Amazonで購入
33人のお客様がこれが役に立ったと考えています
コメント 違反を報告
2016年2月25日に日本でレビュー済み
形式: 単行本Amazonで購入
2人のお客様がこれが役に立ったと考えています
コメント 違反を報告
2013年10月26日に日本でレビュー済み
形式: 単行本
4人のお客様がこれが役に立ったと考えています
コメント 違反を報告
2013年6月14日に日本でレビュー済み
形式: 単行本
3人のお客様がこれが役に立ったと考えています
コメント 違反を報告
2007年6月15日に日本でレビュー済み
形式: 単行本
45人のお客様がこれが役に立ったと考えています
コメント 違反を報告
2008年2月27日に日本でレビュー済み
形式: 単行本
22人のお客様がこれが役に立ったと考えています
コメント 違反を報告
2013年1月5日に日本でレビュー済み
形式: 単行本
19人のお客様がこれが役に立ったと考えています
コメント 違反を報告