著作一覧 |
みねこあさんの「プログラミングパラダイムについて、つれづれと」を読みながらつらつら考えるに、Smalltalkは命令型言語だが、ステートメントにそれほど依存していない(と調べずに書く)のだから、手続き型言語(もっとも、Rubyだってwhileもifもみんな式であってステートメントではないのだが、それは元々の実装の都合のような気はする)の箱から外して、本文のほうではハイブリッド型というのは技術的な特徴がどうしたと書いているのだから関数がファーストクラスオブジェクトである以上はハイブリッド箱に変えてみて(もっともsumimさんのSmalltalk-76と-80についてのコメントを読むと、「Smalltalk」と一括りにして良いのかどうかも怪しいけど。そこでSmalltalk-76を「Small」、Smalltalk-80を「Talk]とそれぞれ略称することにして、併せて「SmallTalk]と表記することを提案してみたり。でもそうは書かないけど)書き直してみました。
この図自体は、井出先生の本の分類(から読み取った内容。だからオブジェクト指向パラダイムが命令型/関数型に直交しているのはみねこあさんが書いている通り)の上に、現在の言語をマップしたもので、「〜言語」というキャプションが入っていない箱はソースの見た目による括りです(というところで大雑把にAlgol系とLisp系に分けているけど、Rubyは言語仕様という点からは何でも式だからLispに近いと思うし、JavaScriptはクラスベースのOOPLでは無いという点から仲間外れだったりするわけだけど)。
rjb-1.2.2をリリースしたのに、gem install rjbすると1.2.0がインストールされるので不思議だなぁ、ファイルコピーに失敗してるのかな、とダウンロードページからダウンロードして確認してみたり、1.2.0は名前をつけ間違えてrjb-1.2.0ではなく1.2.0というリリース名になっていたので、同じように1.2.2というリリース名に変えてみたりしたが、とにもかくにも変わらない。
で、gemがどこからダウンロードしているのか、gem environmentで見てみると、http://gems.rubyforge.org/ と表示された。
で、そのURIをアクセスすると、gem pushしろと書いてある。
むむ、ってことは1.2.0のリリース後にルールが変わったのだな。気づかなかった。
が、
$ gem19 push rjb-1.2.2.gem ERROR: While executing gem ... (RuntimeError) Unknown command push
なるほど、ではgem update --system してからもう一回試すと、RubyForgeのログインを求められて、無事プッシュできた。
すると、RubyForgeのほうは、一般にgem installされる安定版とは別に、非安定版をばりばりアップロードする使い方ができるのだな。
ジェズイットを見習え |
Smalltalk については、もうひとつ、JavaScript のように関数ライクなクラスを持ち、LISP のようなマクロをも有する Smalltalk-72 というバージョンも欠かせないので、いっそ Sma Llt Alk がよいと思います。^^; http://bit.ly/9dmvOA
-72は、また妙なプログラミング言語ですねぇ。さすが、Sma。ところで、Squeakはどういう位置づけになるんでしょうか? (Capitalizeの話ではなく、Smalltalkの特徴として)
Squeak は、よく、新しい Smalltalk であるかのように紹介されますが、実質としては Alk つまり -80 の、かなり初期のバージョン(v1。ちなみに -80 の商品化時は v2)です。のちの Squeak Etoys(スクリプティング機能付きの教育現場向けオーサーウエア)を作るのに Java などを使うより便利だったので、Apple 社内でうち捨てられて死にかけていたのを息を吹き返させた感じです。あと、サブセットながら XEROX 純正 Smalltalk からの直接のフォーク(直系の子孫)である点も特徴です。 http://bit.ly/bs6k4G<br><br>他方で、Smalltalk-80 の直系としての最新版はというと Cincom Smalltalk(VisualWorks 。http://smalltalk.cincom.jp/)がこれにあたります。とはいえ、言語上の変更としては名前空間の導入くらいで、API の整理や VM のチューンのほうに多くの力がさかれている、というのが個人的な印象です。<br><br>VisualWorks と Squeak は遠いながらも血縁関係にあるので、両者のイメージ(処理系やそれに付随する環境を構成するオブジェクト群を永続化し収めたファイル)には共通する部分もあります。<br><br>その他の世の中の Smalltalk は、オリジナルの Smalltalk-80 に触発されて企業や個人ファンがフルスクラッチで作ったクローンや独自解釈の亜種です。変わり種としては処理系構築の学習用に特化された Little Smalltalk、 UNIX と親和性を高めた GNU Smalltalk、Java HotSpot VM に技術転用された VM と、オプショナルな型チェック機能を有する Strongtalk などがあります。広い解釈では JavaScript に影響を与えた SELF もクラスを捨てた―、さらにうーんと広げれば Ruby もイメージを捨て、文法を ALGOL系に差し替えた―という切り口での Smalltalk 亜種ととらえることも可能かと思います。
ってことはみんなが考えるSmalltalk≒Alkということですね。(するとますますTalk派(いるのか?)は間違っていると)<br>でも、すると「この方向性は Smalltalk-80 ではやりすぎで」は解決されていないということなんですかね? (解決する必要があるかどうか論評できないけど)
やりすぎで―というのは、アラン・ケイが「かくあるべき」「これで十分(工夫次第で他を損なわずに)可能」と考えるところを基準にして、です。しばしば、Smalltalk が何者かをよく理解できていない人も似た表現をしますが、これはケイが言うのとは向いている方向がかなり違うので要注意かとも。<br><br>たとえばメタクラス機構はなくてもクラス(をオブジェクトとし、それ)にそれぞれ独自の振る舞いをさせられるとか、制御構文はあってもかまわない(たとえば条件分岐処理が真偽値へのメッセージングである必要はない)とか、ブロックがファーストクラスでなくてもかまわないというあたりで、Smalltalk-76 の延長上でも Smalltalk は成り立ちうるというのがケイの考えで、だからくしくもこれらを踏襲する Ruby を Smalltalk-76 に似ていて好きだと言ったのではないかと勝手な想像をしています。http://bit.ly/cPrv0L<br><br>ともあれ「やりすぎで―」はまだ解決はされていませんし、おそらく将来もされないでしょう。ケイが Smalltalk を死んだ言語と呼び、ついに最近になって見限るに至ったのは、そんな理由からだと思います。ちなみに彼は今、Smalltalk-72 で失敗した、強力だけれども“バベルの塔状態”を生み出してしまう LISP のマクロ的な機能を巧く御する方法を模索しています。http://bit.ly/6wA8ek