Smalltalkの代わりにRubyを使用する理由 [閉まっている]

Rubyは、Ruby on Railsの影響から人気が高まっていますが、思春期を経て現在苦労しているようです。RubyとSmalltalkの間には多くの類似点があります- 磁気浮上はその証拠です。より珍しい構文を持っているにもかかわらず、SmalltalkはRubyのオブジェクト指向の美しさのすべて（それ以上ではないにしても）を備えています。

私が読んだことから、SmalltalkはRubyを打ち負かしているようです：

• 成熟度（1970年代に開発）
• 安定
• 商用サポート
• 分散ソース管理（テキストの差分だけでなく、コードの構造を理解します）
• VMのいくつかの実装
• クロスプラットフォームのサポート
• Railsの強力な代替手段としての海辺のWebフレームワーク

Rubyは単に車輪を再発明しているようです。では、なぜRuby開発者はSmallTalkを使用しないのですか？RubyにはSmalltalkにはない何がありますか？

記録のために：私はSmalltalkの経験がほとんどない、またはまったくないRubyの人ですが、なぜだろうと思い始めています。

編集：スクリプトの使いやすさの問題はGNU Smalltalkによって対処されたと思います。私が理解しているように、これによりsmalltalkを通常の古いテキストファイルに書き込むことができ、Smalltalk IDEにいる必要がなくなります。その後、次を使用してスクリプトを実行できます。

gst smalltalk_file

私はRubyユーザーというよりもPythonistaですが、同じ理由でRubyにも同じことが言えます。

• Smalltalkのアーキテクチャはやや孤立していますが、PythonとRubyは統合を容易にするためにゼロから構築されました。Smalltalkは、PythonとRubyが持っているような方法でハイブリッドアプリケーションのサポートの本体を実際に獲得したことがないため、「埋め込まれたスクリプト言語としての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は十分に優れていますが、主にPythonWinをPython開発に使用しています。これは、構文の強調表示を備えた優れたエディターがあり、足元につかないためです。
  
  ただし、SmalltalkはIDEで使用するように設計されており（実際、Smalltalkは元のグラフィカルIDEでした）、他のシステムでは複製されない優れた機能がいくつかあります。強調表示と「表示」を使用してコードをテストすることは、Python IDEでは見たことのない非常に優れた機能ですが、Rubyについて話すことはできません。

• SmalltalkはWebアプリケーションパーティーにやや遅れて到着しました。VisualWaveのような初期の取り組みはひどく成功することはなく、シーサイドが出て初めて、適切なWebフレームワークがSmalltalkサークルに受け入れられるようになりました。その間、Java EEは完全な受け入れライフサイクルを持っており、熱狂的なファンがそれを宣伝し、ついに退屈してRubyに移行します;-}
  
  皮肉なことに、Seasideは認知症の間で少しのマインドシェアを得始めているため、Smalltalkは人気に戻ります。

そうは言っても、Smalltalkは、それをどのように駆動するかを考え出せば、非常に優れたシステムです。

朝、家を出て出勤するとき、車道を左折または右折する決断に苦労することが多い（私は通りの真ん中に住んでいる）。どちらの方法でも目的地に行くことができます。ある方法では、高速道路にたどり着きます。高速道路は、交通状況にもよりますが、おそらく最も早くオフィスに着くでしょう。私は道の少なくとも一部で非常に速く運転することができ、仕事に行く途中のかわいい女の子を見るチャンスがあります:-)

もう1つの方法では、非常に魅惑的で風の強い裏道を、完全な木で覆われた状態で旅行できます。その道は非常に楽しく、2つのアプローチのうち、間違いなく楽しいですが、高速道路を利用した場合よりも遅くオフィスに到着することになります。それぞれの方法にはメリットがあります。急いでいる日は、通常は高速道路を利用しますが、渋滞に巻き込まれたり、事故に遭う可能性が高まります（急いで注意しないと）。他の日、私は木々の道を選んで走り、景色を楽しみ、私が遅れていることに気づくかもしれません。私はスピードを上げて、チケットを手に入れるか、自分で事故を起こす可能性を高めようとするかもしれません。

どちらの方法も他の方法よりも優れています。それぞれに利点とリスクがあり、それぞれが私の目標に到達します。

あなたの質問は少しポイントを欠いていると思います。 あなたは選ぶべきではありません、あなたはそれらの両方を学ぶべきです！

本当に次のフレームワーク（vm、インフラストラクチャ）を選択できる立場にある場合は、何を使用するかを決定する必要があり、アプリケーションが何をすべきかという観点から、長所と短所について特定の質問をすることができます。

私はsmalltalk（それを愛する）とruby（それを愛する）を使用しました。

自宅でもオープンソースプロジェクトでも、好きな言語をすべて使用できますが、仕事をするときは採用しなければなりません。

仕事でルビーを使い始めたのは、solaris、linux、windows（98,2000、xp）でほぼ同じように動作するスクリプト言語が必要だったからです。Rubyは当時、average-joeには知られていなかったため、レールは存在しませんでした。しかし、関係者全員に販売するのは簡単でした。

（なぜpythonではないのか？真実？私は1週間に1回、ターミナルが私のスペースをタブに変換して意図がめちゃくちゃになったときに起こったバグを探していた）。

それで人々はルビーでますますコードを書き始めました。なぜならそれはとてもリラックスして楽しんでいて、空の雲ではなかったからです。

ポール・グラハムはそれを要約します

確かに、ほとんどの人は単にメリットに基づいてプログラミング言語を選択しないのは事実です。ほとんどのプログラマーは、他の誰かが使用する言語を教えられます。

そして

ハッカーにとって魅力的であるためには、言語は、彼らが書きたい種類のプログラムを書くのに良いものでなければなりません。そしてそれは、おそらく驚くべきことに、使い捨てプログラムを書くのに適していなければならないことを意味します。

そして、Lispの土地にいたとき、LISPをsmalltalkに置き換えようとする

Rubyのライブラリ、コミュニティ、勢いは良い

LISPがRubyよりも強力な場合は、LISPを使用しないのはなぜですか？LISPでのプログラミングに対する一般的な反対意見は次のとおりです。

1. ライブラリが足りません。
2. LISPプログラマーを雇うことはできません。
3. LISPは過去20年間、どこにも行きませんでした。

これらは圧倒的な異論ではありませんが、確かに検討する価値があります。

そして

さて、強力な言語と一般的な言語のどちらかを選択すると、強力な言語を選択することは非常に意味があります。しかし、権力の差が小さい場合、人気があることにはあらゆる種類の素晴らしい利点があります。2005年に、RubyではなくLISPを選択する前に、私は長い間懸命に考えていました。最適化されたコード、または本格的なコンパイラーとして機能するマクロが必要な場合にのみ、おそらくそれを行います。

私は反対です。Smalltalk構文は、最も単純で強力なプログラミング言語構文の1つです。

言語が非常に似ているのは事実です。それを解釈する浅い方法は、RubyをSmalltalkカバーバンドと呼ぶことです。より合理的な解釈は、Smalltalkのクローズドシステムがそれを分離したということです。一方、RubyはUnixエコロジーに参加し、あらゆる言語の機能を太陽の下で流用する習慣により、無限に穏やかな採用曲線とGitなどのキッカスツールとの楽な統合を実現しています。

ジャイルズバウケット

誰がこれを言ったと思いますか？（引用は近いですが、正確ではないかもしれません）：「SmalltalkがJavaに勝ると思っていました。そうしたときに「Ruby」と呼ばれるかどうかわかりませんでした。」

ドラムロール ....

...

答えは...ケントベック

ステファンデュカスには、Smalltalkのすばらしい本がいくつかあります。

http://stephane.ducasse.free.fr/FreeBooks.html

そのため、SmalltalkコミュニティーはRubyやRailsコミュニティーほど多作ではありませんが、それでもなお大きな助けがいくつかあります。

RubyにはSmalltalkにはない何がありますか？

• ライブラリのセットを充実させる主要なプラットフォーム（IronRubyおよびjR​​uby）による現在の大規模なサポート
• デイブ・トーマスのような伝道者は、何年もの間、国中を旅して自分たちの言語の福音を説教してきました。私はデイブを見ました Javaカンファレンスで Javaを知らないことと、Rubyを好むことを見たことがあります。
• 本棚の現在の強力な不動産
• Rubyの作成者は、プログラマについて考えていると述べています。Rubyの構文には、このZenの魅力があるようです。固定するのは難しいですが、ファンを活性化するようです。
• クリエイティブ、のようなダイナミックなプレゼンテーションジャイルズと、この1つのそのゲインマインドシェア

あなたの主張はよく理解されていると思います。かつて友人が言ったように、RubyはSmalltalkに対して「新しいボトルに入った古いワイン」かもしれません。しかし、時には新しいボトルが重要になります。ワインは適切なタイミングで適切な場所になければなりません。

私を殴る。1年間かけてRubyをチェックし、小さなプロジェクトをいくつか行って自分の好みを確認しました。Rubyで作業するたびに腰を下ろして「私は本当にSmalltalkでこれをやる」と思っているので、私はSmalltalkの大物だと思います。最後に私は諦めてSmalltalkに戻りました。今、私は幸せです。幸せは良いです。

もちろん、「なぜ？」という疑問を投げかけます。順不同：

1. IDEが私がこれまで作業した他のものを吹き飛ばすからです。これには、IBMメインフレームのISPFからMicrosoftのVisual（。*）までの一連のプラットフォームが含まれ、Visual Basic 4-6、Visual C ++（さまざまな化身）、BorlandのTurbo Pascalおよび子孫（Delphiなど）、およびDECに関するものなどが含まれます。キャラクタモードとX-Windowsの両方のマシン。
2. 画像が美しい住む場所だからです。欲しいものが見つかります。何かを行う方法がわからない場合は、画像のどこかに私がやろうとしていることの例であることを知っています。私がしなければならないことは、それが見つかるまで探すことだけです。そして、それは自己文書化されています-何かがどのように動作するかの詳細を確認したい場合は、興味のあるクラスでブラウザを開くだけで、メソッドを見て、それが動作します。（結局、プリミティブと呼ばれるものにぶつかると、「ドラゴンがいる」ということになりますが、通常はコンテキストから理解できます）。Ruby / C ++ / Cで同様のことを行うことは可能ですが、それほど簡単ではありません。簡単が良いです。
3. 言語は最小限で一貫しています。3種類のメッセージ-単項、バイナリ、キーワード。これは、実行の優先度も表します-最初に単項メッセージ、次にバイナリメッセージ、次にキーワードメッセージ。かっこを使って物事を助けます。少しだけ構文を理解してください-それはすべてメッセージ送信で行われます。（OK、割り当てはメッセージの送信ではなく、演算子です。したがって、「戻り」演算子（^）です。ブロックは角括弧（[]）で囲まれています。その中の1つまたは2つの「マジック」ビットの可能性があります。しかし、少しくそ...）。
4. ブロック。ええ、私は知っています。それらはRuby（およびその他）に存在しますが、それをぶつけて、文字通りそれらを使用せずにSmalltalkでプログラミングすることはできません。あなたはしている強制的にそれらを使用する方法を学びます。時々強制されることは良いことです。
5. 妥協のないオブジェクト指向プログラミング、またはその代わりの代替案。同じことをしながら、「オブジェクトを実行」しているふりをすることはできません。
6. それはあなたの脳を伸ばすからです。私たちが慣れ親しんできた快適な構成要素（if-then-else、do-while、for（;;）など）はもう存在しないため、何か新しいことを学ぶ必要があります。上記のすべて（およびそれ以上）と同等のものがありますが、別の考え方を学ぶ必要があります。別に良いです。

一方、これはメインフレームが地球を支配していた頃からプログラミングをしている男のとりとめのない話かもしれません。私たちは5マイルも歩いて、目をくらませる吹雪を乗り越え、上り坂を上り、コンピュータはメモリにドーナツを使用していました。私はRuby / Java / C / C ++ /に対して何も持っていません、それらはすべてコンテキストで有用ですが、Smalltalkを与えるか、私に与えます...まあ、おそらくLispまたはSchemeを学ぶ必要があります... :-)

Smalltalk：人々が転送するifTrue：[考える] ifFalse：[考えない]

Ruby：後ろ向きに考えない限り、人は前向きに考える

1）メッセージによるSmalltalkのRPNのような制御フローはLispのようなものです。これは定期的でクールですが、人々を奇妙なものにします。

2）Rubyでは、慣用的な方法で人々がコードを書くことができます- 特に理由がない限り、何とかしてください。

updateは、Smalltalkサンプルを実際にはより正当なコードに書き換えました。

Rubyは現在のバズ言語です。70年代に開発された言語よりも、現在それを使用して構築されたソフトウェアの販売が容易です。

コミュニティ！Ruby、特にRailsにはすばらしいコミュニティがあります。smalltalkをいじってみると、Smalltalkについて書かれたスクリーンキャスト、記事、ブログ投稿などはそれほど多くないようでした。

最初の行の質問に答えました：「Rubyが人気になりつつある」

• たくさんありますRubyをベースにした興味深いモジュール、プロジェクトなどあります。
• Rubyで何か問題が発生した場合、どこかでヘルプを見つけるのは簡単です。
• Rubyは現在多くのコンピューターにインストールされています（OS Xには多くのLinuxディストリビューションにデフォルトで含まれており、Windowsには優れたインストーラーがあります）-使用したどのマシンにもデフォルトでsmalltalkがインストールされているのを見たことはありません。

ある言語が他の言語よりも優れているかどうかは関係ありません。例として、PHPはこれまでで「最高」の言語ではないかもしれませんが、Ruby on Rails（作成のための「より良い」ツール）でそれを使用することを検討します。ウェブサイト）それはとても広まっているからです。

基本的に、言語の特定の長所と短所は、それを取り巻くすべてのもの、つまりコミュニティよりもはるかに重要ではありません。

Ruby（またはその他の言語）は、Smalltalk（またはその他の言語）よりも人気があります。ウィットするには：

• Dave Thomas自身、「[10分でブログを作成する方法]のビデオ... Rubyは小さなニッチ言語から、「Railsアプリケーションを作成した言語」になりました（Ruby Conference 2010基調講演）。
• 初期のSmalltalkベンダーは法外な料金を請求しました
• Smalltalkは（その時代に先立って）30年前に発明されたため、古く「死んだ」言語（FORTRANのような）の多くに発生します。
• 企業はSmalltalkをその使用を隠すほどの競争上の優位性と見なしています

言語はOO機能で類似していますが、Smalltalkのキラーな利点は、ライブでオープンな環境です（誤解されている「イメージ」）。このSmalltalkでのプログラミング例を確認すると、議論は終わりです。

私にとっては、Rubyが持っているものはそれほど多くありませんが、Rubyが持っていないものはそうです。また、VMと完全な環境の必要性もありません。

Smalltalkは素晴らしいです。ここでOOの概念を学びましたが、使いやすさのためにRubyを使用します。お気に入りのエディターでRubyコードを記述して、コマンドラインから実行できます。

それで、私にとっては、それがSmalltalkよりもRubyを選択することです。

Rubyをしばらく使用してきたすべての人は、Smalltalkに対する深い責任を認識しています。これらの人々の1人として、SmalltalkでのRubyの何が好きですか？厳密に言えば、それは砂糖です。Rubyは意図的に非常に構文に忠実な言語ですが、Smalltalkは非常に構文が最小の言語です。Rubyは、基本的にPerlish構文シュガーを備えたSmalltalkオブジェクトモデルです。私はたまたま砂糖が好きで、プログラミングがもっと楽しくなると思います。

Rubyを使って簡単に仕事を見つけることができます。私は本当にSmalltalkが大好きですが、Smalltalkニッチに入るのは事実上不可能です。そこには回避策がありますが、人気があったときに入らなかった場合、今では事実上不可能です。

他のすべての理由は、言語を適切に学習するために実際の仕事に集中して、十分な時間を費やす必要があるため、取るに足りないものになります。あなたが独立して裕福でない場合、それを行うための最良の方法は、職場でそれに触れることです。

Smalltalkディストリビューションの価格は$ 1000USDの倍数でしたが、Rubyは無料です。

RubyはSmalltalkに対応し、アラビア数字はローマ数字に対応します。同じ数学、より簡単な構文。

少しSmalltalkを実行しました。IDEは覚えていることの1つです。RubyはIDEを適切にサポートしていますか？

Rubyはビジネスレッグを持つ可能性があるため使用しますが、Smalltalkはそうではありません。

個人的な経験からお伝えできます。まだSmalltalkを使用していて、大好きで、いくつかのフレーバーを使用しています。Smalltalkは素晴らしい言語であり、あなたが言及したすべてのものですが、平均的なCIO / CTOが新しいプロジェクトでSmalltalkを使用するように説得することはおそらくないでしょう。もちろん、控えめなCIO / CTOがRubyを使用するように説得するのは難しいかもしれません。最終的には、長期的な商用サポートと、将来システムをサポートできるオフストリートの従業員を見つける能力が必要な場合は、非常に注意する必要があります。例として、Smalltalkは90年代前半には非常に大きなものでしたが、IBMは90年代後半にそれに大きな投資をしました。IBM Smalltalkは、すべてのビジネスアプリケーションの次の言語になるでしょう。IBMは、Smalltalkをメインフレームシステムを含むすべてのものに適用しました。Javaが普及し、市場を席巻し、そしてSmalltalkはニッチプレーヤーになりました。1年以上前、IBMはその言語を捨てました（現在の用語は日没です）。また、歴史を見てください。Smalltalkアリーナで最初の主要な商業的プレーヤーであったParkPlaceとDigitalkは、合併して廃業しました。

私はSmalltalkとRubyの両方を愛していますが、Rubyは私が日常的に行うことに適用可能であり、（実際に言えば）私の心に近いことがわかりました。Smalltalkが提供しないRubyの機能は何ですか？

• テキストベースのスクリプト
• 低い実装要件（より多くの場所で実行）
• 学習と正当化がより簡単になりました（PerlおよびPythonプログラマーは問題ありません）
• プログラムの移動が簡単-テキストファイル！
• ネイティブ環境とうまく連動
• どこでもJavaが実行され、jRubyが実行されます...
• より大きく、よりアクティブなコミュニティ

gst（GNU Smalltalk）について言及している人もいます。問題はまだ残っています。

あなたの挑戦に打ち勝つためにあなたをより強力でより速くするものを何でも使ってください。

私たちのために、小さな家の枠組みの中で、私たちは海辺の頂上に建てられた、本当に私たちの超大国です。

私はRoRコミュニティが大好きです。それは正しい態度を持っています。それは非常に貴重です。しかし、同時に、技術的には、海辺はより複雑な問題に対してより強くなります。

あなたはオープンソースのものを使って素晴らしい海辺のウェブアプリを作ることができます。

dabbledbは、シーサイドをベースにしたサートアップでした。今年6月にAviがtwitterに売りました！

他の人があなたのイニシアチブを承認するのを待つ必要はありません。

ちょうどそれのために行きます。それを成し遂げなさい。うまくいくことを見せてください。

あなたは一人じゃない。私たちは同じ船に乗っています。

（RailsConf 2009からの）Robert Martinからの興味深い見解：「Smalltalkを殺したことでRubyも殺したかもしれない」

問題の一部は、開発環境がランタイムです。これにより、多くの能力が得られますが、学習曲線も大きくなります。

ここでは、ハローワールドチュートリアルがあります。

これは、テキストエディターを開いてテキストをコピーして貼り付け、保存してコンパイラーを実行する方法を知る必要がある他の言語とは大きく異なります。私は環境の使い方を知っている必要があります。そのチュートリアルでは、実行できる基本的なプログラム（おそらくそのチュートリアルの欠点である可能性が高い）を作成する方法すら示していません。

物事を進めるだけのコストは、他のほとんどの言語よりも明らかに高くなります。

ほとんどの言語には、人目を引く素晴らしいコードがいくつかあります。Smalltalkでこれを見たことはありません。また、Smalltalkは非常に長い間使用されており、まだあいまいであるため、Smalltalkに対する不名誉もあると思います。

最も大きな違いは、RubyはUSEAGEの点でperlに非常に似ているということです。Smalltalkが「スクリプト」言語に足場を築くことはありませんでした。

VMは本当にかっこいいですし、ルビーがそれに似たものになっていて、ルビーで書かれたOS上のすべてをメモリ空間のオブジェクトとして扱うことができるといいのですが、それまでは、Rubyの簡潔で短い構文、小さなスクリプトを書いて、後で再利用します。Rubyにはperlのすべての利点があり、OOPはperlのOOPハックよりもsmalltalkにはるかに似ています。

私はジョンケの答えよりもさらに進んで、非常に強力なコミュニティを持つ多数の言語があり、ほとんどすべての好みに合うのに十分であり、これらのサブセットには主流の認識があります（つまり、マネージャーはそれらを使用することを許可します）も動作します）。

言語の基本を学ぶのは簡単ですが、実際にそれを効果的に使用するには、プラットフォームとツール、および構文とイディオムを学ぶのに十分な時間を費やす必要があります。IIRC、McConnellは、本当に上手になるには約3年かかると主張しています。

これらのことを考えると、LISPやSmalltalkのような言語に多くの時間を費やすことを正当化するのは困難ですが、それらは興味深いものであり、おそらく教育的なものです。

SmalltalkとLispの主な問題は、ディスカッションの後発者として、共有ホスティングでCGIまたはFastCGIを使用してそれらを実行できないことです。

それらを使用するためにVPSまたは専用サーバーが必要な場合、洗浄されていないマスは決して使用されません。IMHO Seasideは他のほとんど何よりも優れていますが、DreamhostまたはWebfactionで動作しますか？