[解決済み] なぜSmalltalkではなくRubyを使うのか？[クローズド］

質問

Rubyが 人気 Ruby on Rails の影響が大きいのですが、現在は青春を謳歌しているように感じられます。RubyとSmalltalkの間には多くの類似点があります。 磁気浮上 がその証です。より変わった構文を持っているにもかかわらず、SmalltalkはRubyのオブジェクト指向の美しさを（それ以上でないにしても）すべて持っています。

私が読んだ限りでは、SmalltalkはRubyに勝っているようです。

• 成熟度 (1970年代に開発された)
• 安定性
• 商用サポート
• 分散型ソース管理 (テキスト差分だけでなく、コードの構造を理解します。）
• いくつかの の実装があります。
• クロスプラットフォームのサポート
• また シーサイドウェブフレームワーク として Rails に代わる強力な

Rubyは車輪の再発明をしているようにしか見えません。では、なぜRubyの開発者はSmallTalkを使わないのでしょうか？ RubyにはSmalltalkにないものがあるのでしょうか？

念のため。私はRuby派でSmalltalkの経験はほとんどないのですが、なぜか気になり始めています。

編集します。 スクリプトの書きやすさの問題については GNU Smalltalk . 私が理解するところでは、これによって普通の古いテキストファイルにスモールトークを書くことができ、もはやスモールトークIDEである必要はありません。そうすると スクリプトを実行する で実行できます。

gst smalltalk_file

どのように解決するのですか？

私はRubyよりもPythonistaですが、Rubyでも同じような理由で同じことが言えます。

• Smalltalk のアーキテクチャは、Python と Ruby が統合を容易にするために基礎から構築されたのに対し、やや偏狭なものです。 Python や Ruby がそうであるように、Smalltalk は決してハイブリッドアプリケーションのサポートを得ることができず、「組み込みスクリプト言語としての Smalltalk」というコンセプトは決して受け入れられませんでした。
  
  
  
  余談ですが、Javaは他のコードベースとインターフェイスするのが最も簡単なものではありませんでしたが（JNIはかなり不器用です）、それがシェアを獲得するのを止めることはありませんでした。 IMOのインターフェイス論は重要です - 組み込みの容易さは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 のような初期の取り組みがひどく成功したことはなく、まともな Web フレームワークが Smalltalk 界隈で受け入れられるようになったのは Seaside が出てきてからでした。 その一方で、Java EE は、熱狂的なファンボーイの宣伝から始まり、最終的に飽きて Ruby に移行するという、完全な受け入れライフサイクルを送っています。｝
  
  
  
  皮肉なことに、Seaside は専門家の間で少し注目を浴び始めているので、Smalltalk がそのサイクルに乗って再び人気を得るかもしれません。

とはいえ、Smalltalkは一度それを動かす方法を見つけてしまえば、非常に素晴らしいシステムです。