Smalltalkの代わりにRuby=を使用するのはなぜですか？
Rubyは popular になりつつあり、主にRailsへの影響Rubyから影響を受けていますが、現在は思春期に苦労しているように感じます。 RubyとSmalltalkには多くの類似点があります- maglev はその証拠です。より珍しい構文を持っているにも関わらず、SmalltalkはRubyのオブジェクト指向の美のすべてを（それ以上ではないにしても）持っています。
私が読んだことから、SmalltalkはRubyビートを持っているようです：
- 成熟度（1970年代に開発された）
- 安定
- 商用サポート
- 分散ソース管理 （テキストの違いだけでなく、コードの構造を理解します）
- いくつかの VMの実装
- クロスプラットフォームのサポート
- シーサイドWebフレームワーク as Railsの強力な代替
Rubyは車輪を再発明しているようです。では、なぜRuby開発者がSmallTalkを使用しないのですか？ RubyにはSmalltalkにはないものがありますか？
記録のために：私はSmalltalkの経験がほとんどないRubyの男ですが、なぜだろうと思い始めています。
編集：スクリプト作成の容易さの問題は GNU Smalltalk によって対処されたと思います。私が理解しているように、これにより、Smalltalkを通常の古いテキストファイルに書き込むことができ、Smalltalk IDEにいる必要がなくなります。その後、 スクリプトを実行 で次のことができます：
gst Smalltalk_file
私はRubyユーザーというよりはPythonistaですが、同じ理由がRubyにも当てはまります。
PythonおよびRubyは、統合を容易にするためにゼロから構築されたのに対し、Smalltalkのアーキテクチャはやや孤立しています。 Smalltalkは、PythonとRubyが持つような方法で、ハイブリッドアプリケーションのサポートを実際に獲得することはなかったため、「組み込みスクリプト言語としてのSmalltalk」の概念は決して受け入れられませんでした。
余談ですが、Javaは他のコードベースとのインターフェースをとるのに最も簡単なものではありませんでした（JNIはかなり不器用です）が、それはマインドシェアの獲得を止めませんでした。 IMOのインターフェース引数は重要です-埋め込みの容易さはPythonを傷つけませんが、すべてのアプリケーションがこの機能を必要とするわけではないため、この引数は中程度の重みしか持ちません。また、Smalltalkの以降のバージョンでは、この問題に実質的に対処しました。ほとんどの主要なSmalltalk実装（VisualWorks、VisualAgeなど）のクラスライブラリは大きく、学習曲線がかなり急であるという評判がありました。 Smalltalkの主要な機能のほとんどは、クラスライブラリのどこかに隠されています。ストリームやコレクションなどの基本的なものも含まれています。言語のパラダイムは、それをよく知らない人にとってはカルチャーショックのようなものであり、ブラウザによって表示されるプログラムの断片的な見方は、ほとんどの人が慣れているものとはまったく異なります。
全体的な効果は、Smalltalkが学習するのが難しいという評判（やや相応しい）を得たことです。本当に熟練したSmalltalkプログラマーになるには、かなりの時間と労力が必要です。 RubyおよびPythonは、習得が容易であり、新しいプログラマーをスピードアップするのに非常に簡単です。歴史的に見ると、主流のSmalltalk実装は非常に高価であり、実行にエキゾチックなハードウェアが必要でした 1983年から投稿されたこのnet.lang.st8 。 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開発に使用していますが、それは主にシンタックスハイライトを備えたNiceエディタを備えており、足元にないからです。
ただし、SmalltalkはIDE（実際、Smalltalkは元のグラフィカルIDEである）で使用するように設計されており、他のシステムでは複製されないNice機能がまだあります。ハイライトと「表示」を使用したコードのテストは、Python IDEで見たことのない非常に優れた機能ですが、Rubyのことは話せません。SmalltalkはWebアプリケーションパーティーにやや遅れました。 VisualWaveのような初期の取り組みは決してひどく成功したことはなく、Seasideが発表されるまで、適切なWebフレームワークがSmalltalkサークルで受け入れられました。その間、Java EEは、それを宣伝する熱狂的なファンボーイから始まり、最終的に退屈してRuby;-}に移行することから始まる完全な受け入れライフサイクルを持ちました。
皮肉なことに、シーサイドは認知機能の間で少しの間マインドシェアを獲得し始めているので、Smalltalkがサイクルに乗って人気に戻っていることがわかります。
そうは言っても、Smalltalkは、それを駆動する方法を考え出したら非常に素晴らしいシステムです。
午前中に家を出て仕事に行くとき、私はしばしばドライブウェイを左または右に曲がる決定に苦労します（私は通りの真ん中に住んでいます）。どちらの方法でも目的地に到着します。ある方法で高速道路に行くことができますが、交通量によっては、おそらく最も早くオフィスに行くことができます。私は少なくとも途中までは非常に速く運転するようになり、仕事に行く途中でかわいい女の子を見る可能性が十分にあります:-)
もう1つの方法は、木に完全に覆われた非常に魅力的で風の強い裏道を走行することです。その道は非常に楽しいものであり、2つのアプローチのうち、間違いなくもっと楽しいものです。ただし、高速道路を利用した場合よりも遅くオフィスに着くということです。どちらの方法にもメリットがあります。急いでいる日は、通常は高速道路を利用しますが、交通に出くわす可能性があり、事故に巻き込まれる可能性も高くなります（急いで注意しないと）。他の日は、木々の道を選んで走り、景色を楽しみながら、私が遅れていることに気付くかもしれません。自分でスピードアップを試みて、チケットを取得したり、事故を起こしたりする可能性を高めます。
どちらの方法も他の方法より優れているわけではありません。それぞれに利点とリスクがあり、それぞれが私の目標に到達します。
あなたの質問にはその点がいくらか欠けていると思います。 あなたは選択すべきではない、あなたは学ぶそれら両方！
本当に次のフレームワーク（vm、インフラストラクチャ）を選択できる立場にある場合は、使用するものを決定する必要があり、アプリケーションが何をしようとしているのかという観点から賛否両論で特定の質問をすることができます。
私はSmalltalk（それを愛している）とRuby（それを愛している）を使用しました。
自宅でもオープンソースプロジェクトでも、好きな言語をすべて使用できますが、仕事をするときには採用しなければなりません。
Solaris、linuxおよびwindows（98,2000、xp）の下でほぼ同等に動作するスクリプト言語が必要だったため、私はRuby（作業中）を使用し始めました。Rubyは当時、average-joeには知られておらず、Railsは存在しませんでした。しかし、関係者全員に簡単に販売できました。
（なぜpythonではないのですか？真実ですか？ターミナルがスペースをタブに変換し、意図が台無しになったときに起こったバグを探して1週間過ごしました）。
だから、人々はRubyでコードを作成し始めました。これは、空の雲ではなく、リラックスして楽しんでいたからです。
確かに、ほとんどの人は単にメリットに基づいてプログラミング言語を選択しないのは事実です。ほとんどのプログラマーは、他の誰かがどの言語を使用するかを教えられます。
そして
ハッカーにとって魅力的であるためには、言語は彼らが書きたい種類のプログラムを書くのに適していなければなりません。そして、それは、おそらく驚くべきことに、使い捨てプログラムを書くのに適していなければならないことを意味します。
LISPの土地にいたとき、LISPをSmalltalkに置き換えようとします
Rubyのライブラリ、コミュニティ、および勢いは良い
それでは、LISPがRubyよりもさらに強力であれば、LISPを使用してみませんか？ LISPでのプログラミングに対する典型的な反対意見は次のとおりです。
- 十分なライブラリがありません。
- LISPプログラマを雇うことはできません。
- LISPは過去20年でどこにも行きません。
これらは圧倒的な異論ではありませんが、検討する価値があることは確かです。
そして
現在、強力な言語と人気のある言語のどちらかを選択できる場合、強力な言語を選択することは非常に理にかなっています。しかし、力の差が小さい場合、人気があることはあらゆる種類の素晴らしい利点があります。 2005年、RubyよりもLISPを選択する前に、私は長い間一生懸命に考えていました。最適化されたコード、または本格的なコンパイラとして機能するマクロが必要な場合にのみ、おそらくそれを行います。
私は反対のことを言います。Smalltalk構文は、最も単純で強力なプログラミング言語構文の1つです。
言語が非常に似ているのは事実です。それを解釈する浅い方法は、Ruby Smalltalkカバーバンド。 Sunの下の言語は、Gitなどのkickassツールとの無限の穏やかな採用曲線と楽な統合を提供します。
誰がこれを言ったと思う？ （引用は近いかもしれませんが、正確ではないかもしれません）：「私は常にSmalltalkがJavaを打ち負かすと思っていました。
ドラムロール ....
...
答えは...ケントベック
Ruby Smalltalkにはないものは何ですか？
- ライブラリのセットを充実させる主要プラットフォーム（IronRubyおよびjRuby）による現在の大規模なサポート
- デイブ・トーマスのような福音伝道者は、長年にわたり、彼らの言語の福音を宣べ伝えて全国をツアーしてきました。私はJava会議でDaveを見て、Javaと彼はRubyを好むことを知らない。
- 本棚にある現在の強力な不動産
- Rubyの作成者は、彼がプログラマーについて考えていると言っています。Rubyの構文は、このZenの魅力を持っているようです。
- Giles や this one のような創造的でダイナミックなプレゼンテーションがマインドシェアを獲得します
あなたの主張はよくできていると思います。友人がかつて言ったように、RubyはSmalltalkに対して「新しいボトルの古いワイン」かもしれません。しかし、時々新しいボトルが重要です。ワインは適切な場所になければなりません。正確な時に。
Stephane Ducasseには、Smalltalkのすばらしい書籍がいくつかあります。
http://stephane.ducasse.free.fr/FreeBooks.html
そのため、SmalltalkコミュニティはRubyおよびRailsコミュニティほど多産ではありませんが、まだ大きな助けがあります。
私を殴る。私は1年かけてRubyをチェックアウトし、小規模なプロジェクトをいくつかやって、自分がどのように気に入ったかを確認しました。 Rubyと仕事をするたびに「Smalltalkでこれをやりたい」とため息をつき、思うので、私はSmalltalkの偏執者だと思います。最後に私は屈して、Smalltalkに戻りました。今、私は幸せです。幸福は良いです。
もちろん、「なぜ？」という質問があります。順不同：
- IDEは私がこれまでに扱った他のものをすべて吹き飛ばすからです。これには、IBMメインフレームのISPFからMicrosoftのVisual（。*）までの一連のプラットフォーム、Visual Basic 4-6、Visual C++（さまざまな化身）、BorlandのTurbo Pascalおよび子孫（Delphiなど）、およびDECのものが含まれます。文字モードとX-Windowsの両方のマシン。
- イメージは生きる美しい場所だからです。欲しいものを見つけることができます。画像のsomewhereが、私がやろうとしていることの例-すべて私がそれを見つけるまで狩りです。そして、それは自己文書化です-何かがどのように機能するかの詳細を見たいなら、興味のあるクラスでブラウザを開くだけで、メソッドを見て、それがどのように機能するかです。 （OK、最終的にはプリミティブと呼ばれるものをヒットし、それは「ここにドラゴンがいる」ですが、通常はコンテキストから理解できます）。 Ruby/C++/Cでも同様のことができますが、それほど簡単ではありません。簡単な方が良いです。
- 言語は最小限で一貫しています。 3種類のメッセージ-単項、バイナリ、およびキーワード。それは、実行の優先度についても説明しています-最初に単項メッセージ、次にバイナリメッセージ、次にキーワードメッセージ。括弧を使用して物事を助けます。ほんとうに小さな構文でした-それはすべてメッセージ送信で行われました。 （OK、割り当てはメッセージ送信ではなく、演算子です。'return '演算子（^）も同じです。ブロックは、角括弧のペア（[]）で囲まれています。でもちょっと…）。
- ブロック。ええ、私は知っています、それらはRuby（およびその他）にありますが、それをぶら下げて、文字通りそれらを使わずにSmalltalkでプログラムすることはできません。あなたはそれらを使用する方法を学ぶためにforcedです。時々強制されるのは良いことです。
- 妥協のないオブジェクト指向プログラミング-またはその代替案。同じ古いことをしている間に「オブジェクトを実行している」というふりをすることはできません。
- それはあなたの脳を伸ばすからです。慣れ親しんだ快適な構成要素（if-then-else、do-while、for（;;）など）はもう存在しないため、新しいことを学ぶ必要があります。上記（およびそれ以上）に相当するものがありますが、異なる考え方を学ぶ必要があります。別に良いです。
一方、これは、メインフレームが地球を支配していた時代からプログラミングをしている男のとりとめのないものかもしれません。目がくらむような吹雪を通り抜け、両方向に上り坂を走り、コンピューターが記憶にドーナツを使用するために5マイル歩く必要がありました。私はRuby/Java/C/C++ /に対して何も持っていません、それらはすべてコンテキストで便利ですが、Smalltalkまたは私に...私にLISPまたはSchemeを学ぶ必要があります... :-)
Smalltalk：人々はifTrueを転送します：[考える] ifFalse：[考えない]
ルビー：後ろ向きに考えない限り、人々は前向きに考える
1）SmalltalkのメッセージによるRPNのような制御フローはLISPのようなものです-それは定期的でクールですが、奇妙な人々が出ています。
2）Rubyは人々が慣用的な方法でコードを書くことを可能にします-なんとかするしない限りしない理由があります。
更新 Smalltalkサンプルを実際により適切なコードに書き換えました。
Rubyは現在の話題の言語です。 70年代に開発された言語よりも、それで構築されたソフトウェアを今すぐ販売する方が簡単です。
コミュニティ！ Rubyと特にRailsには素晴らしいコミュニティがあります。Smalltalkをいじくり回すと、スクリーンキャスト、記事、ブログ投稿などはあまりないように見えました。 。Smalltalkについて書かれています。
私たちは混chaとした宇宙に住んでいるので、Ruby（または他の言語）はSmalltalk（または他の言語）よりも人気があります。機知に：
- デイブ・トーマス自身から、「[後]ビデオを「10分間でブログを作成する方法」... Ruby= written Rails apps in '"（ Ruby Conference 2010 keynote ）。
- 初期のSmalltalkベンダーは法外に課金
- Smalltalkは、30年前に（その時代に）発明されたため、古くて「死んだ」言語（FORTRANなど）の多くに発生しています。
- 企業は、Smalltalkを競争力のある優位性とみなしています- 彼らはその使用を隠しています
言語はOO機能で似ていますが、Smalltalkのkillerの利点はライブでオープンな環境です（非常に誤解されています） 'image'）。 Smalltalkでのプログラミングのこの例 をチェックアウトした後、議論は終わりました。
あなたはあなたの最初の行で質問に答えました：「ルビーはポピュラーになっています」
- lotには、Rubyに基づいた興味深いモジュール、プロジェクトなどがあります。
- Rubyで何かを実行できない場合は、どこかで助けを見つけるのは簡単です。
- Rubyは現在、コンピューターのlotにインストールされています（OS X、多くのLinuxディストリビューションにはデフォルトで含まれており、Windows用の優れたインストーラーがあります）-Smalltalkはデフォルトでどのマシンにもインストールされていません私は使った..
たとえば、ある言語が他の言語より優れているかどうかは関係ありません。例として、PHPは「最高の」言語ではないかもしれませんが、RubyでRails（ウェブサイトを作成するための「より良い」ツール）は非常に普及しているためです。
基本的に、言語の特定の長所と短所は、それを取り巻くすべてのもの、つまりコミュニティよりもはるかに重要ではありません。
私にとっては、Rubyが持っているもののケースではありませんが、Rubyは持っていません。そして、持っていないものは必要ですVMおよび完全な環境。
Smalltalkは素晴らしい-私が学んだ場所OOコンセプトですが、使いやすさのためにRubyに行きます。好きなエディタでRubyコードを書いて実行できますコマンドラインを形成します。
だから、私にとって、それは私がRuby Smalltalkの上に選択するものです。
Rubyでしばらく働いてきた人は皆、Smalltalkに対する深い負債を認識していると思います。これらの人々の1人として、私はRuby over Smalltalk？厳密に言語の観点からは、それは砂糖だと思います。Ruby=は意図的に非常に構文糖質の言語ですが、Smalltalkは非常に構文最小の言語です。Rubyは本質的にPerlish構文シュガーを使用したSmalltalkオブジェクトモデルであり、シュガーが好きで、プログラミングがより楽しくなることがわかりました。
Rubyを簡単に実行できる仕事を見つけることができます。私はSmalltalkが大好きですが、Smalltalkのニッチに入ることは事実上不可能です。その中に回避策がありますが、人気があったときにあなたが入らなかったら、それは事実上不可能です。
他のすべての理由は、言語を適切に学習するために実際の作業に集中するために十分な時間を費やす必要があるため、取るに足らないものになります。あなたが独立して裕福ではない場合、それを行うための最良の方法は職場でそれにさらされています。
アラビア数字がローマ数字に対するものであるように、RubyはSmalltalkに対するものです。同じ数学、簡単な構文。
Smalltalkディストリビューションの価格は$ 1000USDの倍数でしたが、Rubyは無料です。
私は少し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アリーナの最初の主要な商業プレーヤーであったDigitalkは、合併して廃業しました。
Robert Martinの興味深い視点（RailsConf 2009から）： "Smalltalkを殺したものはRubyも殺すことができた"
より強力で高速なものを使用して、チャレンジに打ち勝ちましょう。
s の場合、家の中の小さなフレームワークで、海辺の上に建てられたのは、まさに私たちの超大国です。
私はRoRコミュニティが大好きで、正しい姿勢を持っています。それは非常に貴重です。しかし、同時に、技術的には、海辺はより複雑な問題に対して強くなります。
オープンソースのものを使用して、素晴らしいシーサイドWebアプリを作成できます。
dabbledbは海辺をベースにしたsartupでした。 Aviは今年6月にTwitterにそれを売りました！
他の人があなたのイニシアチブを承認するのを待つ必要はないと言います。
ちょうどそれのために行きます。できあがり。動作することを示してください。
あなたは一人じゃない。私たちは同じ船に乗っています。
私はSmalltalkとRubyの両方が大好きです。しかし、Rubyは私が毎日やることにもっと当てはまり、心に近い（実際に言えば）。 Ruby Smalltalkが提供しないものは何ですか？
- テキストベースのスクリプト
- 低い実装要件（より多くの場所で実行）
- 習得と正当化がより簡単に（PerlおよびPythonプログラマーはnoトラブルを抱えること
- プログラムを簡単に移動-テキストファイル！
- ネイティブ環境とのインターフェース
- どこでもJava実行、jRuby実行...
- より大きく、より活発なコミュニティ
いくつかはgst（GNU Smalltalk）に言及しています。問題はまだ残っています。
問題の一部は、開発環境が実行時だと思います。これにより多くのパワーが得られますが、学習曲線も大きくなります。
こちら は、Hello Worldチュートリアルです。
これは、テキストエディターを開き、テキストをコピーして貼り付け、保存を押し、コンパイラーを実行する方法を知る必要がある他の言語とは大きく異なります。環境の使い方を知っています。このチュートリアルでは、実行可能な基本プログラム（おそらく、このチュートリアルの欠点）を作成する方法も示していません。
他のほとんどの言語よりも、物事を進めるだけのコストは間違いなく高くなります。
ほとんどの言語には、目を引く素敵なコードがあります。 Smalltalkでそれを見たことはありません。また、Smalltalkは非常に長い間存在しており、まだ比較的あいまいなため、Smalltalkにはいくつかの汚名があると思います。
最大の違いは、RubyはUSEAGEの点でPerlにはるかに似ているということです。Smalltalkは「スクリプト」言語に足場を築きませんでした。
VMは本当にクールで、Ruby=に似たものができれば、Rubyはメモリ空間のオブジェクトですが、それまでは、Rubyの簡潔で短い構文、小さなスクリプトを記述して後で再利用する機能を楽しんでいます。Ruby PerlのOOPは、PerlのOOPハックよりも、Smalltalkにはるかに似ています。
議論の遅れとして、SmalltalkとLISPの主な問題は、共有ホスティングでCGIまたはFastCGIを使用して実行できないことです。
洗浄されていない大衆は、それらを使用するためにVPSまたは専用サーバーが必要な場合、それらを使用することはありません。私見シーサイドは、他のものよりも優れていますが、DreamhostまたはWebfactionで実行できますか？
Jonkeの答えよりもさらに進んで、今では非常に強力なコミュニティを持ち、あらゆる好みにほぼ十分な言語がたくさんあり、これらのサブセットは主流の認識を持っていると言います（つまり、あなたのマネージャーは同様に動作します）。
言語の基本を学ぶのは簡単ですが、実際にそれを効果的に使用するには、プラットフォームとツール、構文とイディオムを学ぶのに十分な時間をかける必要があります。 IIRC、McConnellは、真に熟練するまで約3年かかると主張しています。
これらのことを考えると、LISPやSmalltalkなどの言語に多くの時間を費やすことを正当化することは困難ですが、それらは興味深いものであり、おそらく教育的なものです。