Smalltalk ではなく Ruby を使用する理由は何ですか?[閉まっている]

https://stackoverflow.com/questions/187380

06-07-2019
|

質問

ルビーはこうなっています人気のある, は主に Ruby on Rails の影響によるものですが、現在は思春期に苦戦しているように感じられます。Ruby と Smalltalk には多くの類似点があります -- リニアモーターカーその証拠です。Smalltalk は、より珍しい構文を持っていますが、Ruby のオブジェクト指向の美しさを (それ以上ではないにしても) すべて備えています。

私が読んだところによると、Smalltalk は Ruby を上回っているようです。

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

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

記録のために：私は Ruby の専門家で、Smalltalk の経験はほとんどありませんが、なぜなのか疑問に思い始めています。

編集： スクリプト作成のしやすさの問題は、次の方法で解決されたと思います。 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オペレーティングシステムを非常によくサポートし、ある程度の牽引力を獲得することに成功しました。残念なことに、これは、プラットフォームとしてのWebの台頭と、Javaに対するマーケティングの大きな推進力と一致しました。 Javaは1990年代後半にほとんどのマインドシェアを獲得し、Smalltalkを少し走らせました。
RubyとPythonはより一般的なツールチェーンで動作し、特定の開発環境と密接に結びついていません。私が使用したSmalltalk IDEは十分に優れていますが、Pythonの開発にPythonWinを使用しているのは、主に構文の強調表示を備えた優れたエディターがあり、足元がつかないためです。

ただし、Smalltalkは、 IDE（実際、Smalltalkは元のグラフィカルIDEでした）には、他のシステムでは複製されない素晴らしい機能がまだいくつかあります。ハイライトと「表示」を使用したコードのテストは、Python IDEで見たことのない非常に優れた機能ですが、Rubyについて話すことはできません。
SmalltalkはWebアプリケーションパーティにやや遅れました。 VisualWaveのような初期の取り組みは決してひどく成功したことはなく、Seasideが発表されるまで、適切なWebフレームワークがSmalltalkサークルで受け入れられました。それまでの間、Java EEは、熱狂的なファンがそれを宣伝し、ついに退屈してRubyに移行することから始まる完全な受け入れライフサイクルを持っています;そのSmを見つけることがあります

他のヒント

午前中に出勤するために家を出るとき、私はしばしばドライブの道を左折するか右折するかの決定に苦労します（私は通りの真ん中に住んでいます）。どちらの方法でも目的地に到着します。ある方法は、私を高速道路に導きます。それは、交通状況によっては、おそらく最も早くオフィスに行くでしょう。少なくとも途中までは非常に速く運転することができ、仕事に行く途中できれいな女の子を見るチャンスがあります：-）

別の方法では、木に覆われた非常に魅力的で風の強い裏道を進むことができます。その道は非常に楽しく、2つのアプローチの中で間違いなくもっと楽しいですが、それは私が高速道路を利用するよりも遅くオフィスに行くことを意味します。どちらの方法にもメリットがあります。急いでいる日は、通常は高速道路を利用しますが、交通渋滞に陥る可能性があり、事故に巻き込まれる可能性も高くなります（急いで注意しないと）。他の日は、木々の道を選んで走り、景色を楽しんで、私は遅れていることに気付くかもしれません。スピードアップを試みて、チケットを取得するか、自分で事故を起こす可能性を高めます。

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

あなたの質問には要点がいくらか欠けていると思います。 あなたは選択すべきではなく、両方を学習すべきです！

本当に次のフレームワーク（vm、インフラストラクチャ）を選択できる立場にある場合は、使用するものを決定する必要があり、アプリケーションの対象となる観点から賛否両論で特定の質問をすることができます

smalltalk（愛）とruby（愛）を使用しました。

自宅またはオープンソースプロジェクトでは、好きな言語をすべて使用できますが、仕事をするときは採用する必要があります。

solaris、linux、windows（98,2000、xp）でほぼ同等に動作するスクリプト言語が必要だったため、（職場で）rubyを使用し始めました。 Rubyは当時、アベレージジョーには知られておらず、レールは存在しませんでした。しかし、関係者全員に簡単に販売できました。

（なぜpythonではないのか？真実か？ターミナルがスペースをタブに変換し、意図が台無しになったときに発生したバグを1週間探し回ったことがあります。）

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

ポールグラハムがまとめています

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

and

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

そしてLispにいたときLISPをsmalltalkに置き換えてみてください

Rubyのライブラリ、コミュニティ、および勢いは良いです


したがって、LISPがまだより強力な場合   Ruby、LISPを使用してみませんか？典型的な   LISPでのプログラミングに対する異議は次のとおりです。


十分なライブラリがありません。

LISPプログラマを雇うことはできません。

LISPは過去20年でどこにも行きません。


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

and

今、強力な言語、および一般的な言語、それは選ぶのに優れた意味を持ちます強力なもの。しかし、パワーはマイナーで、人気があるのはすべて素晴らしい利点の一種。 2005年、I＆＃8217; d 選ぶ前に長く考えてください Rubyを介したLISP。私はおそらくそうするだけです最適化されたコードが必要な場合、または本格的な役割を果たすマクロコンパイラ。

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

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

Giles Bowkett

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

ドラムロール....

...

答えは... Kent Beck

Stephane Ducasseには、Smalltalkに関する優れた書籍がいくつかあります。

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

したがって、SmalltalkコミュニティはRubyおよびRailsコミュニティほど多くはありませんが、まだ大きな助けがあります。

RubyにあってSmalltalkにないものは何でしょうか?

ライブラリのセットを充実させる主要なプラットフォーム (IronRuby および jRuby) による大規模な最新サポート
デイブ・トーマスのような伝道者は、何年もの間、自分たちの言語の福音を宣べ伝えるために国中を旅してきました。私はデイブを見たことがあります Javaカンファレンス 彼は Java を知らないし、Ruby の方が好きだと述べています。
本棚にある強力な現在の不動産
Ruby の作成者は、プログラマーについて次のように考えていると述べています。Ruby の構文にはこの禅の魅力があるようです。特定するのは難しいですが、ファンを興奮させているようです。
クリエイティブでダイナミックなプレゼンテーションのようなジャイルズそしてこれですマインドシェアを獲得する

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

私を打ちます。私は1年かけてRubyをチェックし、小規模なプロジェクトをいくつか行って、それがどのように気に入ったかを確認しました。私がSmalltalkの偏執者だと思うのは、Rubyと一緒に仕事をするたびに、ため息をつき、「Smalltalkでこれをやりたい」と思うからです。最後に私は屈してSmalltalkに戻った。今、私は幸せです。幸福はより良いです。

もちろん、「なぜ？」という質問があります。順不同：

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

一方、これは単にメインフレームが地球を支配していた時代からプログラミングをしている男のとりとめのないものかもしれません。。私はRuby / Java / C / C ++ /に対して何も持っていません、それらはすべてコンテキストで役に立ちますが、Smalltalkまたは私に...私にLispまたはSchemeを学ぶ必要があります...：-）

スモールトーク： ifTrue：[考える] ifFalse：[考えない]

ルビー：人々は後ろ向きに考えない限り前向きに考えます

1）SmalltalkのメッセージによるRPNのような制御フローはLispに似ています-定期的でクールですが、奇妙な人々が出ています。

2）Rubyでは、人々が話す慣用的な方法を使用してコードを書くことができます。理由はありません。

更新は、Smalltalkサンプルを実際により合法なコードに書き換えました。

Rubyは現在のバズ言語です。 70年代に開発された言語よりも、今すぐ構築されたソフトウェアを販売する方が簡単です。

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

最初の行で質問に答えました：＆quot;ルビーが人気になっています＆quot;

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

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

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

Ruby（またはその他の言語）は、混oticとした宇宙に住んでいるため、Smalltalk（またはその他の言語）よりも人気があります。機知に：

デイブ・トーマス自身から＆quot; [後 the]ビデオの「ブログを構築する方法 Ten Minutes '...ルビーは素敵な小さなニッチ言語、あなたがRailsを書いた言語であることアプリ '＆quot; （ Ruby Conference 2010 基調講演）。
初期のSmalltalkベンダーは法外に請求されました
Smalltalkは、30年前に（当時）発明されたため、多くの人にとっては「死んだ」古いものです。言語（FORTRANなど）
Smalltalkは、使用を非表示にします

言語はオブジェクト指向機能に似ていますが、Smalltalkの killer の利点は、ライブでオープンな環境（多くの誤解されている「イメージ」）です。 Smalltalkでのプログラミングの例をチェックアウトした後、議論は終わった。

私にとっては、Rubyが持っているものではなく、Rubyが持っていないものです。そして、それが持っていないことは、VMと完全な環境の必要性です。

Smalltalkは素晴らしい-オブジェクト指向の概念を学んだ場所ですが、使いやすさのためにRubyに行きます。お気に入りのエディターでRubyコードを作成し、コマンドラインから実行できます。

だから、私にとっては、SmalltalkよりもRubyを選んだのです。

Rubyをしばらく使ってきた人なら誰でも、Smalltalkに対する深い負債を認識していると思います。これらの人々の1人として、Ruby over Smalltalkの何が好きですか？厳密な言語の観点からは、それは砂糖だと思います。 Rubyは意図的に非常に構文が多い言語ですが、Smalltalkは非常に構文が少ない言語です。 Rubyは基本的に、Perlish構文シュガーを使用したSmalltalkオブジェクトモデルです。私はたまたま砂糖が好きで、それがプログラミングをより楽しくすることがわかりました。

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

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

Smalltalkディストリビューションは1000ドルの倍数で販売されていたため、Rubyは無料です。

RubyはSmalltalk、アラビア数字はローマ数字です。同じ数学、簡単な構文。

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

Rubyにはビジネスレッグがあるかもしれませんが、Smalltalkにはないので使用してください。

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

SmalltalkとRubyの両方が大好きですが、Rubyのほうが私が日常的に行うことにより適していて、私の心に近いことがわかりました（実際には）。 Rubyは、Smalltalkが提供しないものを提供しますか？

テキストベースのスクリプト
低い実装要件（より多くの場所で実行）
学習と正当化がより簡単に（PerlとPythonプログラマーは no トラブルを起こしません
プログラムの移動が簡単に-テキストファイル！
ネイティブ環境との良好なインターフェース
Javaが実行されている場所、jRubyが実行されている場所...
より大きく、より活発なコミュニティ

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

より強力で高速になるものなら何でも使用して、チャレンジに打ち勝ちます。

us の小さな家のフレームワークの場合、海辺の上に建てたのはまさに私たちの超大国です。

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

オープンソースのものを使用して、素晴らしいシーサイドWebアプリを作成できます。

dabbledbは海辺をベースにしたサータップでした。今年6月にAviがtwitterで販売しました！

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

それだけでいい。できあがり。動作することを示してください。

あなたは一人ではありません。私たちは同じ船に乗っています。

Robert Martinの興味深い視点（RailsConf 2009から）：＆quot; Smalltalkを殺すとRubyを殺す可能性があり、あまりにも＆quot;

問題の一部は、開発環境が実行時だと思います。これにより多くのパワーが得られますが、学習曲線も大きくなります。

こちらは、Hello Worldチュートリアルです。

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

他のほとんどの言語よりも、物事を進めるだけのコストは間違いなく高い。

ほとんどの言語には、目を引く魅力的なコードがあります。 Smalltalkでそれを見たことはありません。また、Smalltalkにはあまりにも長い間存在しており、まだ比較的あいまいなため、Smalltalkにはいくつかのスティグマがあると思います。

最大の違いは、RubyがUSEAGEの点でperlにはるかに似ていることだと思います。 Smalltalkが「スクリプト」に足場を置くことはありませんでした。言語。

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

Jonkeの答えよりもさらに進んで、今では非常に強力なコミュニティを持つ言語が数多くあり、すべての好みにほぼ対応できるようになっています。これらのサブセットには主流の認識があります職場でも使用してください。）

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

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

議論の後発として、SmalltalkとLispの主な問題は、共有ホスティングでCGIまたはFastCGIを使用して実行できないことです。

洗浄されていない大衆は、VPSまたは専用サーバーを使用してそれらを使用する必要がある場合、それらを使用することはありません。私見シーサイドは、他のものよりも優れていますが、DreamhostまたはWebfactionで実行されますか？

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow