☰

Smalltalk ではなく Ruby を使用する理由 [closed] 質問する

tag-icon • tag-icon ruby-on-rails ruby smalltalk seaside
Smalltalk ではなく Ruby を使用する理由 [closed] 質問する

ルビーは人気のある主にRuby on Railsの影響によるものですが、現在は思春期を乗り切ろうとしているように感じます。RubyとSmalltalkには多くの類似点があります。磁気浮上式鉄道はそれを証明しています。Smalltalk は、より珍しい構文を持っているにもかかわらず、Ruby のオブジェクト指向の美しさをすべて（あるいはそれ以上に）備えています。

私が読んだところによると、Smalltalk は Ruby よりも優れているようです。

Ruby は車輪の再発明をしているだけのように思えます。では、なぜ Ruby 開発者は SmallTalk を使用しないのでしょうか?Ruby にはあって Smalltalk にはないものは何ですか?

記録のために言うと、私は Ruby の人間ですが、Smalltalk の経験はほとんどまたはまったくありません。しかし、その理由が気になり始めています。

編集：スクリプトの容易さの問題は、GNUスモールトーク私の理解では、これにより、通常の古いテキストファイルでSmalltalkを記述できるようになり、Smalltalk IDEを使用する必要がなくなります。スクリプトを実行すると：

gst smalltalk_file

ベストアンサー1

私は Ruby ユーザーというよりは Python ユーザーですが、ほぼ同じ理由で Ruby でも同じことが当てはまります。

  • Smalltalk のアーキテクチャはいくぶん孤立しているのに対し、Python と Ruby は統合を容易にするためにゼロから構築されました。Smalltalk は、Python や Ruby のようにハイブリッド アプリケーションのサポートを実際に獲得することはなかったので、「組み込みスクリプト言語としての Smalltalk」という概念は普及しませんでした。

    余談ですが、Java は他のコード ベースとインターフェイスするのが最も簡単なものではありませんでした (JNI はかなり扱いにくい) が、それが Java がマインドシェアを獲得する妨げにはなりませんでした。私の意見では、インターフェイスの議論は重要です (組み込みの容易さは Python に悪影響を及ぼしていません)。ただし、すべてのアプリケーションがこの機能を必要とするわけではないため、この議論は中程度の重みしかありません。また、Smalltalk の後のバージョンでは、この孤立性が大幅に改善されました。

  • 主要な Smalltalk 実装 (VisualWorks、VisualAge など) のクラス ライブラリは大きく、学習曲線がかなり急であるという評判がありました。Smalltalk のほとんどの主要な機能は、ストリームやコレクションなどの基本的な機能でさえ、クラス ライブラリのどこかに隠されています。言語パラダイムも、慣れていない人にとってはカルチャー ショックのようなもので、ブラウザーに表示されるプログラムの断片的な表示は、ほとんどの人が慣れているものとはまったく異なります。

    全体的な影響として、Smalltalk は (ある程度当然ですが) 学習が難しいという評判を得ています。本当に熟練した Smalltalk プログラマーになるには、かなりの時間と労力が必要です。Ruby と Python は、学習しやすく、新しいプログラマーをすぐに使いこなせるようにするのがはるかに簡単です。

  • 歴史的に、主流のSmalltalk実装は非常に高価であり、実行するために特殊なハードウェアが必要でした。1983 年の net.lang.st80 の投稿Windows 3.1、NT、'95、OS/2 は、メインストリーム ハードウェア上で Smalltalk 実装をサポートし、ネイティブ システム統合が適切に行える最初の量産オペレーティング システムでした。以前は、Mac またはワークステーション ハードウェアが Smalltalk を効果的に実行できる最も安価なプラットフォームでした。一部の実装 (特に Digitalk) は PC オペレーティング システムを非常にうまくサポートし、ある程度の支持を得ることに成功しました。

    しかし、OS/2 はそれほど成功せず、Windows は 1990 年代中頃までメインストリームに受け入れられませんでした。残念ながら、これは Web がプラットフォームとして台頭し、Java がマーケティングで大々的に宣伝された時期と一致していました。Java は 1990 年代後半にほとんどのシェアを獲得し、Smalltalk はやや後進的になりました。

  • Ruby と Python は、より従来的なツールチェーンで動作し、特定の開発環境に密接に結び付いていません。私が使用した Smalltalk IDE は十分に優れていますが、Python 開発には主に構文の強調表示機能を備えた優れたエディターを備え、邪魔にならないという理由で PythonWin を使用しています。

    ただし、Smalltalk は IDE で使用するように設計されており (実際、Smalltalk は最初のグラフィカル IDE でした)、他のシステムでは再現されていない優れた機能もいくつかあります。強調表示と「表示」を使用してコードをテストすることは、Ruby についてはわかりませんが、Python IDE では見たことのない非常に優れた機能です。

  • Smalltalk は、Web アプリケーション パーティに遅れて参加しました。VisualWave などの初期の取り組みは、決して大成功することはなく、Seaside が登場するまで、まともな Web フレームワークは Smalltalk 界で受け入れられませんでした。その間、Java EE は、熱狂的なファンボーイが宣伝し、最終的に飽きて Ruby に移行するという、完全な受け入れライフサイクルを経験しました ;-}

    皮肉なことに、Seaside は専門家の間で少しマインドシェアを獲得し始めているので、Smalltalk がそのサイクルに乗って再び人気を取り戻すかもしれません。

そうは言っても、Smalltalk は、使い方さえ理解してしまえば、非常に優れたシステムです。

おすすめ記事