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

ruby ruby-on-rails seaside smalltalk

Rubyは、主にRuby on Railsの影響から popularになりつつありますが、現在は思春期に苦労しているようです。 RubyとSmalltalkの間には多くの類似点があります – maglevはその証拠です。 より珍しい構文を持っているにもかかわらず、SmalltalkはRubyのオブジェクト指向の美しさを(それ以上ではないにしても)持っています。

私が読んだものから、SmalltalkはRubyに勝っているようだ:

Rubyがただ車輪を一新したようです。 それでは、なぜRuby開発者はSmallTalkを使わないのでしょうか。 * RubyにSmalltalkが搭載されていないものは何ですか?*

_記録のために:私はSmalltalkの経験がほとんどない、まったく経験のないRubyの男ですが、なぜか疑問に思い始めます。

” ” ‘

*編集:*スクリプティングのしやすさの問題は GNU Smalltalkによって解決されたと思います。 私が理解しているように、これはあなたが普通の古いテキストファイルでsmalltalkを書くことを可能にし、そしてあなたはもうSmalltalk IDEにいる必要はありません。 それから http://www.gnu.org/software/smalltalk/manual/html_node/Invocation.html#Invocation[スクリプトを実行してください。

gst smalltalk_file

  120  47


ベストアンサー

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

  • Smalltalkのアーキテクチャーはいくぶん独特ですが、PythonとRubyは統合を容易にするためにゼロから構築されました。 SmalltalkがPythonとRubyのようにハイブリッドアプリケーションのサポートを実際に獲得したことは一度もないので、「埋め込みスクリプト言語としてのsmalltalk」の概念はとらえられませんでした。

    余談ですが、Javaは他のコードベースとやり取りするための最も簡単な方法ではありませんでした(JNIはかなり不器用です)が、それがマインドシェアを得るのを妨げるものではありませんでした。 IMOはインターフェースの議論が重要です – 埋め込みの容易さはPythonを傷つけません – しかし、すべてのアプリケーションがこの機能を必要とするわけではないので、この議論は中程度の重みしか持ちません。 また、Smalltalkの最近のバージョンでは、実質的に島の不一致に対処しました。

  • ほとんどの主要なsmalltalk実装(VisualWorks、VisualAgeなど)のクラスライブラリは大きく、かなり急峻な学習曲線で評判がありました。 Smalltalkのほとんどの重要な機能はクラスライブラリのどこかに隠されています。ストリームやコレクションのような基本的なものでさえもです。 言語パラダイムも、それに慣れていない人にとってはカルチャーショックのようなものであり、ブラウザによって提示されるプログラムの断片的な見方は、ほとんどの人が慣れているものとはかなり異なります。

    全体的な効果として、Smalltalkは習得が難しいという(やや当然の)評判を得ました。本当に熟練したSmalltalkプログラマーになるにはかなりの時間と労力が必要です。 RubyとPythonは、習得が簡単で、新しいプログラマーを早く習得することができます。

  • 歴史的に、主流のSmalltalkの実装は非常に高価で、実行するのにエキゾチックなハードウェアを必要としていました。 このnet.lang.st80からの投稿1983 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でした)、それでも他のシステムでは再現されない優れた機能がいくつかあります。 強調表示と ‘それを表示する’でコードをテストすることは、私がまだPython IDEで見たことがない非常に素晴らしい機能です、私はRubyについて話すことができませんが。

  • SmalltalkがWebアプリケーションのパーティーにやや遅れて来ました。 VisualWaveのような初期の試みはそれほど成功しませんでした、そしてSeasideが出てくるまではまともなWebフレームワークがSmalltalkサークルで受け入れられていませんでした。 その間、Java EEは、好評を博していたファンボーイがそれを宣伝し、ついには退屈してRubyに移行するまで、完全に受け入れられるライフサイクルを過ごしました。 – }

    皮肉なことに、Seasideは認識の間でちょっとしたマインドシェアを得始めているので、Smalltalkがそのサイクルを乗り切って人気に戻ることに気付くかもしれません。

そうは言っても、Smalltalkは、そのドライブ方法を理解した後は非常に優れたシステムです。

87


午前中に家を出て仕事に行くとき、私は往々にして私の道を左または右に曲がるという決断に苦労します(私は通りの真ん中に住んでいます)。 どちらにしても私は私の目的地に行くでしょう。 1つの方法は私を高速道路へと導きます、それは交通量次第で、おそらく私を最も早くオフィスに連れて行きます。 私は少なくとも途中で非常に速く運転するようになる、そして私は働くために彼らの方法でかわいい女の子か2人に会う良い機会を持っている:-)

もう一つの方法は私が完全な木の覆いをした非常に魅力的で風が強い裏道を走ることを可能にします。 その道は非常に楽しいですし、2つのアプローチのうちは間違いなくもっと楽しいです、それは私が私が私が高速道路に乗った場合よりも遅くオフィスに着くことを意味します。 それぞれの方法には利点があります。 私が急いでいる日には、私は交通渋滞に遭遇するかもしれないけれども私は通常高速道路を利用するでしょう、そして私は(私が急いで慎重にしていなければ)私は事故に入る可能性も増します。 他の日には私は木の多い道を選び、その道を走りながら景色を楽しみながら、私は遅く走っていることに気づくでしょう。 私はスピードを上げようと試みるかもしれません、私自身がチケットを手に入れたり事故を起こしたりする可能性を高めます。

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

79


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

あなたが本当に次のフレームワーク(vm、インフラストラクチャ)を選ぶことができる立場にあるなら、あなたは何を使うべきかを決める必要があり、あなたのアプリケーションが何をするつもりかという観点から賛否両論で具体的な質問をすることができます。

私はsmalltalk(それを愛する)とruby(それを愛する)を使いました。

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

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

(なぜPythonではないのですか? 真実 ? 私は一度端末が私のスペースをタブに変換し、意図がめちゃくちゃになったときに起こったバグを探すために一週間を費やしました。

それで、人々はますますルビーでコードを書くようになりました。

http://www.paulgraham.com/popular.html [Paul Grahamがそれをまとめた]

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

and

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

http://www.randomhacks.net/articles/2005/12/03/why-ruby-is-an-acceptable-lisp [Lispの国にいたときはいつでもLISPをsmalltalkに置き換えようとしている]

_ — –

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

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

  1. 十分な数のライブラリがありません。

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

  3. LISPは過去20年間どこにも行っていません。

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

 — –
__

and

_
現在、強力な言語と人気のある言語のどちらかを選択できる場合、強力な言語を選択することは非常に理にかなっています。 しかし、権力の違いがわずかであれば、人気があることはあらゆる種類の良い利点を持ちます。 2005年に、私はRubyよりもLISPを選ぶ前に長くて難しいと思います。 最適化されたコード、または本格的なコンパイラとして機能するマクロが必要な場合にのみ、おそらくそれを実行します。
_

25


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

22


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

19


誰がこれを言ったと思いますか? (見積もりは近い、おそらく正確ではない): “私はSmalltalkがJavaに勝るといつも思っていた。 「Ruby」と呼ばれるのかどうか、私は知りませんでした。」

ドラムロール …​.

…​

答えは… ケントベック

17


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

そのため、SmalltalkコミュニティはRubyやRailsコミュニティほど豊富ではありませんが、それでもまだ大きな助けがあります。

15


Smalltalkが持っていないことは、Rubyには何がありますか?

  • 一連のライブラリを充実させる主要プラットフォーム(IronRubyおよびjR​​uby)による現在の大規模なサポート

  • 何年もの間、彼らの言語の福音を説いて全国を巡回してきたDave Thomasのような伝道者。 私は、彼がJavaを知らず、彼がRubyを好むと述べている_Java conferences_でDaveを見ました。

  • 本棚の現在の強い不動産

  • Rubyの作成者は、彼がプログラマーについて考えると言っています:Rubyの構文はこのZenの魅力を持っているようです。 それを突き止めるのは難しいですが、それでもファンを活気づけるようです。

  • Gilesやhttp://www.youtube.com/watch?v=_2VXUQwGHZg[this 1]のようなクリエイティブでダイナミックなプレゼンテーション。

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

15


私を殴る。 私は1年かけてRubyをチェックアウトし、いくつかの小規模なプロジェクトを行って自分の好きなことを確認しました。 私は私がSmalltalkの大好きな人だと思います。Rubyと仕事をするために座るたびにため息をついて、「本当にSmalltalkでこれをやるのだ」と思うからです。 ついに私は諦めてSmalltalkに戻りました。 今幸せです。 幸せはグーダーです。

もちろん、どちらが「なぜ?」という疑問を投げかけます。 順不同:

  1. IDEは私が今まで扱ったことのないものを吹き飛ばすからです。 これには、IBMメインフレーム上のISPFからMicrosoftのVisual(。*)までの一連のプラットフォームが含まれ、Visual Basic 4-6、Visual C(さまざまな化身)、BorlandのTurbo Pascal、およびその子孫などが含まれます。 Delphi)、そして文字モードでもX-WindowsでもDECマシン上のもの。

  2. 画像は住むのに美しい場所だからです。 私はそこに欲しいものを見つけることができます。 どうすればよいかわからない場合は、イメージ内のどこかが、私がやろうとしていることの一例であることがわかっています。 そしてそれは自己文書化されます – あなたが何かがどのように機能するかの詳細を見たいのなら、あなたが興味のあるクラスでブラウザを開くだけで、メソッドを見てください、そしてそれはそれがどのように機能するかです。 (さて、最終的にはプリミティブと呼ばれるものにぶつかるでしょう、そしてそれは “ここにドラゴンがいる”ですが、それは通常文脈から理解可能です)。 Ruby / C / Cでも同様のことができますが、それほど簡単ではありません。 簡単です。

  3. 言語は最小限で一貫しています。 3種類のメッセージ – 単項、二項、そしてキーワード。 それは実行の優先順位についても説明します – 最初に単項メッセージ、次にバイナリメッセージ、そして次にキーワードメッセージ。 手助けするために括弧を使いなさい。 ほんの少しの構文、本当に – それはすべてメッセージ送信で行われます。 (OK、割り当てはメッセージ送信ではなく、オペレーターです。 これは ‘return’演算子(^)です。 ブロックは角かっこ([])で囲みます。 そこに1つか2つの他の「魔法」のビットがあるかもしれませんが、ちょっと気の利いた…​)。

  4. ブロック ええ、私は知っています、彼らはRuby(そして他の人たち)にそこにいます、しかしそれを叩いてください、あなたは文字通りSmalltalkでそれらを使わないでプログラムすることはできません 使い方を学ぶためにあなたは_強制_されています。 時には強制されるのは良いことです。

  5. 妥協のないオブジェクト指向プログラミング – あるいはその代わりに、代替案。 あなたはまだ同じ古いことをしている間、あなたが「物をしている」ことをふりをすることはできません。

  6. それはあなたの脳を伸ばすからです。 私たち全員が慣れ親しんだ快適な構文(if-then-else、do-while、for(;;)など)はもう存在しないので、新しいことを学ぶ必要があります。 上記すべて(およびそれ以上)に相当するものがありますが、違う考え方を学ぶ必要があります。 違って良いです。

その一方で、これはメインフレームが地球を支配していた頃からプログラミングをしていた男のほんの一部であるかもしれません。 私はRuby / Java / C / C /に対して何も持っていません、それらはすべて文脈で有用です、しかし私にSmalltalkを与えてくださいまたは私に…​さて、多分私はLispかSchemeを学ぶべきですか…​ 🙂

14


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

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

1)SmalltalkのメッセージによるRPNのような制御フローはLispのようなものです – それは規則的でクールですが人々を奇妙にします。

2)Rubyは人々が話す慣用的な方法を使ってコードを書くことを可能にします。

  • update * Smalltalkサンプルを実際にもっと合法的なコードに書き換えました。

11


タイトルとURLをコピーしました