私はSmalltalk の復活の波に乗っているので (特に多くの Ruby-on-Rails の人々が Smalltalk を再発見し、次のアップグレードされた Web フレームワークとしてSeasideを見ているため)、次のような質問を受けます。 Smalltalk コードを編集するには?" または「Smalltalk はまだ独自の世界に住むことを主張していますか?」。
さて、1981 年に初めて Smalltalk を体験した私には、これらの質問がよくわかりません。エディターとデバッガーが私の現在のコード状態に精通しており、Smalltalk 対応の変更管理システムと統合することを望むのはかなり自然なことのように思えます。外部のエディター、デバッガー、または変更管理マネージャーを使用すると、非常に厄介に思えます。
では、お気に入りのエディターで Smalltalk の 5 行のメソッドを編集できないこと、またはお気に入りの Smalltalk を認識しない変更管理システムを使用できないことについて、最も恐れていることは何ですか?
すべてが違います。行の最後に行きたいですか？Ctrl-じゃないE。いくつかの単語を単語ごとにジャンプしたいですか？メタFじゃない…。
テキスト編集は基本的なプログラミング作業です。それらの入力をいじることは、私の心の奥底にある何かをいじることです。
編集: そして、 1987 年に comp.lang.smalltalk でemacs のキー バインドを求めている人がいます。
私がこれまで使ったことのある Smalltalk は Squeak だけなので、私の見解は他の Smalltalk 環境には当てはまらないかもしれません。
画像ベースのアプローチについて私が懸念しているのは、Smalltalk 環境には素晴らしいものがありますが、その環境の外にあるものとの相互運用を困難にするウォールド ガーデンであるということです。たとえば、Yacc や Lex などの外部ツールを使用したい場合はどうすればよいでしょうか? C または Python プログラムを使用して Smalltalk コードを生成したい場合はどうすればよいですか? Smalltalk を他の言語で書かれた大量のコードと混ぜて、これらすべての言語のコードを 1 つのエディターで編集し、すべてを同じソース コード ツリーに保存したい場合はどうすればよいでしょうか?
Smalltalk 環境でシステム関数を呼び出して外部ツールを制御することで、これらすべての問題に対処できると確信しています。しかし、外部ツールに Smalltalk 環境を制御させるのはどれほど簡単なのでしょうか? つまり、Smalltalk をすべてのマスターではなく、単なるコンポーネントの 1 つにしたい場合はどうすればよいでしょうか?
特に怖がることはありませんが、他の smalltalk を使用していたとしても、VW で API を操作するのは少し面倒であることがわかりました。ブラウザーの効果として、API を一度に少しずつ見る傾向があり、特定の機能をどこで探すべきかがすぐにはわからないことがよくあります。
Smalltalk はまた、パラダイム シフトがどのように機能するかを理解するために少し苦しんでいます。私が大学で学士号を取得していたとき (初めて Smalltalk に出会ってからしばらくしてから)、クラスの他の全員が最初のパラダイムのこぶを乗り越えてシステム (Squeak) を初めて学習するのを見て、ちょっとした Schadenfraude を楽しむことができました。時間。
パラダイム シフトとクラス ライブラリに埋もれている機能の組み合わせにより、学習曲線が少し急勾配になっていると思います。ST は、実際に習得するまでにかなり急勾配の学習曲線を必要とするという評判がありました。これは、大規模なクラス ライブラリと、ほとんどの言語機能がライブラリのどこかに埋もれているという事実によるものです。
また (悲しいことに)、Java は 1990 年代半ばに登場し、すべてのマインドシェアを獲得しました。主要な Smalltalks は、完全に消滅するか、ニッチなプレーヤーに売却されました。Ruby が Smalltalk への関心を再び呼び覚ますのに役立ったのは (嬉しい意味で) 皮肉なことですが、「も実行された」陳腐化の認識が長引いていることは役に立ちません。
この時代に Smalltalk に深く関わることの利点 (私が見ている) についてのいくらかの正当 化については、私のこの投稿を参照してください。
機会があれば、Smalltalk に戻りたいと思っています。
私にとって大きな目玉の1つは、私が1つのSmalltalk VMを作成するコードは、これらすべての年月を経ても、他のSmalltalkVMと互換性がないということです。
その理由を理解しています。Smalltalkのコアは、非常に小さな公理とキーワードのセットです。これは、Smalltalkを30分間学習した後、言語自体ではなくAPIライブラリをすでに学習していることを意味します。私は言語デザインへのそのアプローチが好きです。
ただし、Smalltalkの世界では、すべてのVMベンダー間で共通のベース標準APIを使用するというコンセンサスが得られない限り、あるVM用に記述されたSmalltalkコードは、他のVMで実行されないことがほぼ確実です。切り替えることにしました。
これには、VMを切り替えるときにスペースに関する知識の一部が廃止されるという当然の結果もあります。
私は人生でSmalltalkをほとんど試したことがないことに注意してください。私は専門家にはほど遠いです。この理解は、約1か月前にJamesRobertsonと話をしたことから来ています。
私が言いたいもう1つのポイントは、Seasideは実際に最も人気のあるSmalltalkVMで実行されるということです。その偉業を達成するために、彼らが自分たちのために構築しなければならなかった標準APIの量（あるべきだった）はどれくらいだろうか。
そうは言っても、私は常にSmalltalkの状態についてもっと耳を傾けています。Smalltalkの非常に強力な開発環境（およびその他の優れた機能）を試してみたいと思います。
遅いことはわかっていますが、私にとって最大の迷惑は、どのスモールトークにも優れた編集者がいないことです。理解できない話です。テキストの操作は非常に重要であり、「サポート」が少ない....
これは常に 1 つのメソッドをじっと見つめているだけであり、別のメソッドをチェックするためだけにメソッド ファインダーまたは別のブラウザーを用意する必要があります。これが本当に嫌だ……。
キーボードを使用したナビゲーションや、プラットフォーム UI の動作をサポートするための有用なサポートはありません。
確かに、(よくできた) Smalltalk にはすばらしいテキスト エディタは必要ありませんが、キーボードに手を置いたまま環境内を移動できることは非常に便利です (私の場合は、RSI を減らすために不可欠です)。VisualWorks のインスペクタを試してみたところ、矢印キーでリストを上下に移動することさえできませんでした。スペースバーを押すと、ウォークバックしました。はぁ。
制限された Smalltalk 環境により、他の言語がまだ適切なエディターを使用するのに苦労していた時期に、データベース駆動型のソース管理システムに依存することが可能になりましたが、今日では統合が非常に困難になっています。
Eclipse や Team Foundation Server などのツールを使用すると、すべてのツールが相互に統合されることに慣れてしまいます。たとえば、要件が作成されると、プログラマがその要件を実装するためにコミットする変更セットに自動的にリンクされます。Smalltalk の世界では、以前は異なっていたツール間の「境界を破る」ことはほとんど不可能ですが、より大きなプロジェクト、より大きなチーム、より高いレベルの抽象化などでは、派手なエディター以上のツールが必要になり、完全なソフトウェア開発全体を通して役立ちます。ライフサイクル。
Windows の世界では、Dolphin Smalltalk に勝るものはありません。IDE は素晴らしいです。試してみたいもう 1 つの高品質の製品は Visualworks です。これはうまく機能し、非常に高速な VM を備えており、ドキュメントもかなり充実しています。
私は過去に両方を使用しましたが、恐れることは何もありません。