ruby-on-rails - なぜ Smalltalk の代わりに Ruby を使うのですか?

Question

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

score 88 · Accepted Answer

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

Smalltalk のアーキテクチャはいくぶん閉鎖的ですが、Python と Ruby は統合を容易にするためにゼロから構築されました。Smalltalk は、Python や Ruby のようなハイブリッドアプリケーションのサポートを実際に得たことはありませんでした。

余談ですが、Java は他のコードベースとのインターフェイスが最も簡単ではありませんでしたが (JNI はかなり不器用です)、それがマインドシェアを獲得するのを止めることはありませんでした。IMO インターフェイスの議論は重要です - 埋め込みの容易さは Python を傷つけません - しかし、すべてのアプリケーションがこの機能を必要とするわけではないので、この議論は適度な重みしか持ちません。また、Smalltalk のそれ以降のバージョンでは、孤立性に実質的に対処しました。
主要な smalltalk 実装 (VisualWorks、VisualAge など) のほとんどのクラスライブラリは大きく、学習曲線がかなり急勾配であるという評判がありました。Smalltalk のほとんどの重要な機能は、クラスライブラリのどこかに隠されています。ストリームやコレクションなどの基本的な機能も含まれます。言語パラダイムは、それに慣れていない人にとってはカルチャーショックのようなものでもあり、ブラウザーによって表示されるプログラムの断片的なビューは、ほとんどの人が慣れ親しんだものとはまったく異なります。

全体的な効果として、Smalltalk は習得が難しいという (ある程度当然の) 評判を得ました。本当に熟練した Smalltalk プログラマーになるには、かなりの時間と労力が必要です。Ruby と Python は、習得がはるかに簡単で、新しいプログラマーが習得するのも簡単です。
歴史的に、主流の Smalltalk の実装は非常に高価であり、実行するにはエキゾチックなハードウェアが必要でした。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 は非常に優れたシステムです。

score 79 · Accepted Answer

朝、仕事に行くために家を出るとき、私は車道から左折するか右折するかを決めるのに苦労することがよくあります (私は通りの真ん中に住んでいます)。いずれにせよ、私を目的地に連れて行ってくれます。片道は高速道路に通じていますが、交通状況にもよりますが、おそらく最も早くオフィスに着くことができます。私は少なくとも道の途中で非常に速く運転することができ、仕事に向かう途中でかわいい女の子を1つか2つ見るチャンスがあります:-)

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

どちらの方法が他の方法より優れているということはありません。それぞれに利点とリスクがあり、それぞれが私の目標を達成してくれます。

score 25 · Accepted Answer

あなたの質問は少し的外れだと思います。 どちらかを選ぶのではなく、両方を学ぶべきです！

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

私は smalltalk (大好き) と ruby (大好き) を使ってきました。

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

私は、solaris、linux、および windows(98,2000,xp) の下でほぼ同じように動作するスクリプト言語が必要だったので、(仕事で) ruby を使い始めました。当時、Ruby は平均的なジョーには知られておらず、レールは存在しませんでした。しかし、関係者全員に販売するのは簡単でした。

(どうして python じゃないの? 真実? 端末が私のスペースをタブに変換し、意図が台無しになったときに起こったバグを探すのに 1 週間を費やしたことがあります)。

そのため、空に浮かぶ雲ではなく、とてもリラックスして楽しんでいたので、人々は Ruby でコーディングするようになりました。

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

確かに、ほとんどの人がプログラミング言語をメリットだけで選んでいるわけではありません。ほとんどのプログラマーは、他の誰かからどの言語を使用するかを指示されます。

と

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

そして、Lisp の世界にいたとき、LISP を smalltalk に置き換えようとしました

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

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

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

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

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

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

と

ここで、強力な言語と一般的な言語のどちらかを選択する場合、強力な言語を選択することは非常に理にかなっています。しかし、力の差が小さければ、人気があることにはさまざまなメリットがあります。2005 年には、Ruby ではなく LISP を選択する前に、私は長い間真剣に考えました。最適化されたコード、または本格的なコンパイラとして機能するマクロが必要な場合にのみ、おそらくそれを行うでしょう。

score 23 · Accepted Answer

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

score 19 · Accepted Answer

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

ジャイルズ・ボウケット

score 17 · Accepted Answer

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

ドラムロール ....

...

答えは… ケント・ベック

score 15 · Accepted Answer

Ruby には何があり、Smalltalk にはありませんか?

ライブラリセットを強化する主要なプラットフォーム (IronRuby および jRuby) による現在の大規模なサポート
デイブ・トーマスのような伝道者たちは、何年にもわたって国中をツアーし、彼らの言語の福音を説教してきました。Dave がJava カンファレンスで、Javaを知らないが Ruby の方が好きだと言っているのを見たことがあります。
本棚の強力な現在の不動産
Ruby の作成者は、プログラマーのことを考えていると述べています。Ruby の構文には、このような禅の魅力があるようです。特定するのは難しいですが、それでもファンを刺激しているようです。
Gilesのような創造的でダイナミックなプレゼンテーションと、マインドシェアを獲得するこのプレゼンテーション

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

score 15 · Accepted Answer

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

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

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

score 14 · Accepted Answer

私を殴る。私は 1 年かけて Ruby をチェックし、いくつかの小規模なプロジェクトを実行して、Ruby がどのように気に入ったかを確認しました。私は、Ruby を使って作業するたびにため息をつき、「これは Smalltalk でやりたい」と考えていたので、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' 演算子 (^) も同様です。ブロックは角括弧ペア ([ ] ) で囲まれています。そこには 1 つまたは 2 つの他の「魔法の」ビットがあるかもしれません。でもちょっと…）。
ブロック。ええ、私は知っています、それらは Ruby (およびその他) にありますが、ぶっちゃけ、それらを使用せずに Smalltalk で文字通りプログラミングすることはできません。それらの使用方法を学ぶ必要があります。時には強要されることも良いことです。
妥協のないオブジェクト指向プログラミング、またはその代替手段。同じ古いことをやりながら、「オブジェクトをやっている」ふりをすることはできません。
それはあなたの脳を伸ばすからです。私たちが慣れ親しんできた快適な構文 (if-then-else、do-while、for( ; ; ) など) はもはや存在しないため、何か新しいことを学ぶ必要があります。上記のすべて (およびそれ以上) に相当するものがありますが、異なる考え方を学ぶ必要があります。別にいいです。

一方、これは、メインフレームが地球を支配していた時代からプログラミングを続けてきた男のとりとめのないことかもしれません。目がくらむような吹雪の中を 5 マイルも歩かなければならず、上り坂で作業しなければならず、コンピューターは記憶にドーナツを使用していました。私はRuby/Java/C/C++/に反対するものは何もありません.それらはすべて文脈上有用ですが、私にSmalltalkを与えるか.

score 11 · Accepted Answer

Smalltalk: 人は転送する ifTrue: [考える] ifFalse: [考えない]

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

1) メッセージによる Smalltalk の RPN のような制御フローは Lisp に似ています。

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

更新により、Smalltalk サンプルが実際により適切なコードになるように書き直されました。

score 8 · Accepted Answer

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

score 8 · Accepted Answer

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

score 7 · Accepted Answer

あなたは最初の行の質問に答えました：「ルビーは人気が出てきています」

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

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

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

score 7 · Accepted Answer

Ruby (またはその他の言語) は Smalltalk (またはその他の言語) よりも人気があります。ウィット：

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

これらの言語は OO 機能が似ていますが、Smalltalk の決定的な利点は、ライブでオープンな環境 (よく誤解されている「イメージ」) です。この Smalltalk でのプログラミングの例を確認したら、議論は終わりです。

score 5 · Accepted Answer

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

他のすべての理由は、言語を適切に学ぶために実際の仕事に集中して多くの時間を費やす必要があるため、取るに足らないものになります。あなたが独立して裕福でないなら、それをする最良の方法は仕事でそれを暴露することです。

score 5 · Accepted Answer

私にとっては、Ruby にあるものではなく、Ruby にないものです。また、VM と完全な環境が必要ないこともありません。

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

そういうわけで、私は Smalltalk よりも Ruby を選びました。

score 5 · Accepted Answer

しばらく Ruby を使ってきた人なら誰でも、Ruby が Smalltalk に深い恩義があることを認識していると思います。これらの人々の 1 人として、Ruby と Smalltalk のどこが好きですか? 厳密に言語の観点から考えると、それは砂糖です。Ruby は意図的に非常に構文が甘い言語ですが、Smalltalk は非常に構文が最小限の言語です。Ruby は基本的に、Perlish 構文シュガーを使用した Smalltalk オブジェクトモデルです。私はたまたま砂糖が好きで、プログラミングがもっと楽しくなることがわかりました。

score 4 · Accepted Answer

アラビア数字がローマ数字であるように、Ruby は Smalltalk にあります。同じ数学、より簡単な構文。

score 4 · Accepted Answer

Ruby が無料であるのに対し、Smalltalk ディストリビューションは 1000 米ドルの倍数で価格設定されていたためです。

score 3 · Accepted Answer

私は Smalltalk を少しやったことがあります - IDE は私が覚えているものの 1 つです - Ruby は優れた IDE サポートを持っていますか?

score 3 · Accepted Answer

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 は合併し、その後廃業しました。

score 2 · Accepted Answer

Robert Martinからの興味深い視点（RailsConf 2009から）：「Smalltalkを殺したものがRubyも殺す可能性がある」

score 2 · Accepted Answer

私は Smalltalk と Ruby の両方を愛しています。しかし、Ruby は私の日常業務により適していて、(実際的に言えば) 私の心に近いものであることがわかりました。Ruby が提供して Smalltalk が提供していないものは何ですか?

テキストベースのスクリプト
低い実装要件 (より多くの場所で実行)
習得と正当化が容易 (Perl および Python プログラマーは問題なく使用できます)
プログラムの移動がより簡単に - テキストファイル！
ネイティブ環境との良好なインターフェース
どこでも Java が実行され、jRuby が実行されます...
より大きく、より活発なコミュニティ

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

score 2 · Accepted Answer

挑戦を打ち負かすために、あなたをより強力に、より速くするものは何でも使用してください。

私たちにとって、海辺の上に構築された社内フレームワークは、本当に私たちのスーパーパワーです。

私は RoR コミュニティが大好きです。正しい姿勢を持っています。それはとても価値のあることです。しかし同時に、技術的には、海辺はより複雑な問題に対してあなたを強くします。

オープンソースのものを使用して、優れた海辺の Web アプリを作成できます。

dabbledb は seaside に基づいた sartup でした。今年の6月にAviがツイッターに売りました！

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

ただそれのために行きます。やり遂げる。それが機能することを示してください。

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

score 0 · Accepted Answer

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

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

score 0 · Accepted Answer

問題の一部は、開発環境が実行時間であるということだと思います。これは多くの力を与えますが、それはまたより大きな学習曲線を提示します。

これがHelloWorldチュートリアルです。

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

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

ほとんどの言語には、目を見張るようなコードがいくつかあります。Smalltalkでは見たことがありません。また、Smalltalkは非常に長い間使用されており、まだ比較的あいまいなため、スティグマがあると思います。

score 0 · Accepted Answer

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

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

score 0 · Accepted Answer

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

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

これらのことを考えると、LISP や Smalltalk のような言語に多くの時間を費やすことを正当化するのは困難です。

ruby-on-rails - なぜ Smalltalk の代わりに Ruby を使うのですか?

28 に答える 28

Related

Reference