Warum Ruby anstelle von Smalltalk verwenden? [geschlossen]

121

Ruby wird immer beliebter , vor allem aufgrund des Einflusses von Ruby auf Rails, aber es scheint, als würde es sich derzeit durch seine Jugend kämpfen. Es gibt viele Ähnlichkeiten zwischen Ruby und Smalltalk - Magnetschwebebahn ist ein Beweis dafür. Trotz einer ungewöhnlicheren Syntax hat Smalltalk die objektorientierte Schönheit von Ruby (wenn nicht sogar mehr).

Nach dem, was ich gelesen habe, scheint Smalltalk Ruby angeschlagen zu haben:

Es scheint, als würde Ruby das Rad nur neu erfinden. Warum verwenden Ruby-Entwickler SmallTalk nicht? Was hat Ruby beim Smalltalk nicht?

Fürs Protokoll: Ich bin ein Ruby-Typ mit wenig bis gar keiner Erfahrung in Smalltalk, aber ich frage mich, warum.


Bearbeiten: Ich denke, das Problem der einfachen Skripterstellung wurde von GNU Smalltalk behoben . So wie ich es verstehe, können Sie Smalltalk in normale alte Textdateien schreiben, und Sie müssen sich nicht mehr in der Smalltalk-IDE befinden. Sie können Ihre Skripte dann ausführen mit:

gst smalltalk_file
Zwei-Bit-Narr
quelle
47
Weil alle noch auf "Smalltalk on Snails" warten?
Mark Rushakoff
10
Technisch heißt es 'Seaside' (www.seaside.st) und läuft ziemlich schnell auf der Gemstone VM, die einen JIT-Compiler hat. Es gibt auch einen Ruby-Port zur Gemstone-VM namens Maglev.
ConcernedOfTunbridgeWells
3
Nachdem ich all diese Kommentare unten durchgesehen habe und seit 5 Jahren ein Ruby-Fan bin, bin ich jetzt versucht, so schnell wie möglich Smalltalk zu lernen
Amol Pujari
1
GNU Smalltalk ist fast die einzige kostenlose Implementierung, die nicht fest mit der GUI verbunden ist. Ich denke, das ist immer noch kritisch.
Eonil
Der Link "Distributed Source Control" ist unterbrochen.
Piovezan

Antworten:

88

Ich bin eher ein Pythonista als ein Ruby-Benutzer, aber die gleichen Dinge gelten für Ruby aus den gleichen Gründen.

  • Die Architektur von Smalltalk ist etwas inselförmig, während Python und Ruby von Grund auf neu entwickelt wurden, um die Integration zu erleichtern. Smalltalk hat nie wirklich eine umfassende Unterstützung für Hybridanwendungen erhalten, wie dies Python und Ruby getan haben, sodass sich das Konzept von "Smalltalk als eingebettete Skriptsprache" nie durchgesetzt hat.

    Abgesehen davon war Java nicht die einfachste Möglichkeit, sich mit anderen Codebasen zu verbinden (JNI ist ziemlich ungeschickt), aber das hinderte es nicht daran, Mindshare zu erlangen. IMO ist das Schnittstellenargument von Bedeutung - die einfache Einbettung hat Python nicht geschadet -, aber dieses Argument hat nur ein mäßiges Gewicht, da nicht alle Anwendungen diese Funktion erfordern. Auch spätere Versionen von Smalltalk haben sich wesentlich mit der Insellage befasst.

  • Die Klassenbibliothek der meisten wichtigen Smalltalk-Implementierungen (VisualWorks, VisualAge usw.) war groß und hatte den Ruf einer ziemlich steilen Lernkurve. Die meisten wichtigen Funktionen in Smalltalk sind irgendwo in der Klassenbibliothek versteckt, selbst grundlegende Dinge wie Streams und Sammlungen. Das Sprachparadigma ist auch für jemanden, der es nicht kennt, ein Kulturschock, und die stückweise Ansicht des vom Browser präsentierten Programms unterscheidet sich erheblich von der, an die die meisten Menschen gewöhnt waren.

    Der Gesamteffekt ist, dass Smalltalk den (etwas verdienten) Ruf hat, schwer zu lernen zu sein. Es braucht viel Zeit und Mühe, um ein wirklich kompetenter Smalltalk-Programmierer zu werden. Ruby und Python sind viel einfacher zu erlernen und neue Programmierer auf den neuesten Stand zu bringen.

  • In der Vergangenheit waren Mainstream-Smalltalk-Implementierungen recht teuer und benötigten exotische Hardware, um ausgeführt zu werden, wie aus dieser Veröffentlichung von net.lang.st80 aus dem Jahr 1983 hervorgeht . Windows 3.1, NT und '95 sowie OS / 2 waren die ersten Massenmarktbetriebssysteme auf Mainstream-Hardware, die eine Smalltalk-Implementierung mit anständiger nativer Systemintegration unterstützen konnten. Bisher waren Mac- oder Workstation-Hardware die billigsten Plattformen, auf denen Smalltalk effektiv ausgeführt werden konnte. Einige Implementierungen (insbesondere Digitalk) unterstützten PC-Betriebssysteme recht gut und konnten sich durchsetzen.

    OS / 2 war jedoch noch nie so erfolgreich und Windows erreichte erst Mitte der neunziger Jahre die Akzeptanz des Mainstreams. Leider fiel dies mit dem Aufstieg des Web als Plattform und einem großen Marketingschub hinter Java zusammen. Java hat in der zweiten Hälfte der neunziger Jahre den größten Teil des Mindshare übernommen und Smalltalk ein wenig zu einem Mitläufer gemacht.

  • Ruby und Python arbeiten in einer konventionelleren Toolchain und sind nicht eng an eine bestimmte Entwicklungsumgebung gekoppelt. Während die von mir verwendeten Smalltalk-IDEs nett genug sind, verwende ich PythonWin für die Python-Entwicklung hauptsächlich, weil es einen netten Editor mit Syntaxhervorhebung hat und nicht unter die Füße kommt.

    Smalltalk wurde jedoch für die Verwendung mit einer IDE entwickelt (tatsächlich war Smalltalk die ursprüngliche grafische IDE) und verfügt dennoch über einige nette Funktionen, die von anderen Systemen nicht repliziert wurden. Das Testen von Code mit Highlight und 'Show it' ist immer noch eine sehr schöne Funktion, die ich noch nie in einer Python-IDE gesehen habe, obwohl ich nicht für Ruby sprechen kann.

  • Smalltalk kam etwas spät zur Webanwendungsparty. Frühe Bemühungen wie VisualWave waren nie besonders erfolgreich und erst als Seaside herauskam, wurde ein anständiges Webframework in Smalltalk-Kreisen akzeptiert. In der Zwischenzeit hat Java EE eine vollständige Akzeptanz Lebenszyklus , beginnend mit Toben Fanboys Förderung hatte und schließlich zu langweilen und Bewegen auf Rubin; -}

    Ironischerweise ist Meer beginnen ein wenig Mindshare unter den Kennern zu bekommen , damit wir , dass Smalltalk Fahrten können feststellen , dass Rad zurück in die Popularität.

Trotzdem ist Smalltalk ein sehr schönes System, wenn Sie erst einmal herausgefunden haben, wie man es fährt.

ConcernedOfTunbridgeWells
quelle
1
Ich denke, der Klassenbibliothekspunkt liegt außerhalb der Basis. Ich weiß, dass sowohl Smalltalk als auch Ruby und die Klassenbibliotheken sehr ähnlich sind. Bei allen Problemen, bei denen ich eines gelernt hatte, hätte ich das andere gelernt. Nachdem zuerst mehr Rubin gemacht wurde, waren die Smalltalk-Bibliotheken viel einfacher zu erlernen. Sie sind an den meisten Orten bemerkenswert ähnlich. Ich denke nicht, dass irgendetwas über die Klassenbibliothek oder die Sprache selbst Smalltalk schwieriger macht als Ruby.
Sean T Allen
2
Sowohl VW als auch VA Smalltalk hatten aufgrund der Größe der Klassenbibliotheken den Ruf einer steilen Lernkurve. Dies wurde zu dieser Zeit ziemlich weithin anerkannt. Ich habe Smalltalk von einer alten DOS-Version von Digitalk Smalltalk / V gelernt, die eine viel kleinere Klassenbibliothek hatte. Das Handbuch dafür hatte ungefähr die gleiche Größe wie das PP Ruby-Buch, und wie dieses Buch betrug die Klassenbibliotheksreferenz etwa die Hälfte der gesamten Seitenzahl. Die Klassenbibliotheken für VW und VA sind jedoch sehr viel größer.
ConcernedOfTunbridgeWells
79

Wenn ich morgens mein Haus verlasse, um zur Arbeit zu gehen, habe ich oft Probleme mit der Entscheidung, von meiner Einfahrt nach links oder rechts abzubiegen (ich wohne mitten auf einer Straße). In beiden Fällen komme ich an mein Ziel. Ein Weg führt mich zur Autobahn, die mich je nach Verkehr wahrscheinlich am schnellsten ins Büro bringt. Ich fahre zumindest teilweise sehr schnell und habe gute Chancen, ein oder zwei hübsche Mädchen auf dem Weg zur Arbeit zu sehen :-)

Der andere Weg ermöglicht es mir, eine sehr bezaubernde, windige Nebenstraße mit vollständigem Baumbestand hinunterzufahren. Dieser Weg ist sehr unterhaltsam und von den beiden Ansätzen macht er definitiv mehr Spaß, obwohl er später ins Büro kommt, als wenn ich die Autobahn genommen hätte. Jeder Weg hat seine Vorzüge. An Tagen, an denen ich es eilig habe, fahre ich normalerweise auf der Autobahn, obwohl ich möglicherweise auf Verkehr stoße, und ich erhöhe auch die Wahrscheinlichkeit eines Unfalls (wenn ich in meiner Eile nicht aufpasse). An anderen Tagen kann ich den Waldweg wählen und entlang fahren, die Landschaft genießen und feststellen, dass ich zu spät komme. Ich kann versuchen, schneller zu werden, meine Chancen zu erhöhen, ein Ticket zu bekommen oder selbst einen Unfall zu verursachen.

Keiner der Wege ist besser als der andere. Sie haben alle ihre Vorteile und Risiken und bringen mich zu meinem Ziel.

Mario Aquino
quelle
5
Welches ist die Autobahn und welches ist die windige Nebenstraße mit Baumbestand? lol
Charlie Flowers
9
Charlie: das ist es, was es zen macht :)
xofz
32
Und welche Sprache hat die hübscheren Mädchen?
der Blechmann
25

Ich denke, Ihre Frage geht etwas daneben. Sie sollten nicht wählen, Sie sollten beide lernen !

Wenn Sie wirklich in der Lage sind, das nächste Framework (VM, Infrastruktur) auszuwählen, müssen Sie entscheiden, was verwendet werden soll, und können eine bestimmte Frage mit Vor- und Nachteilen aus der Perspektive stellen, was Ihre Anwendung tun soll.

Ich habe Smalltalk (liebe es) und Ruby (liebe es) verwendet.

Zu Hause oder für Open Source-Projekte kann ich jede Sprache verwenden, die ich mag, aber wenn ich arbeite, muss ich sie übernehmen.

Ich fing an, Ruby (bei der Arbeit) zu verwenden, weil wir eine Skriptsprache brauchten, die sich unter Solaris, Linux und Windows (98.2000, XP) mehr oder weniger gleich verhielt. Ruby war zu dieser Zeit dem Durchschnittsjoe unbekannt und es gab keine Schienen. Aber es war einfach, an alle Beteiligten zu verkaufen.

(Warum nicht Python? Die Wahrheit? Ich habe einmal eine Woche lang nach einem Fehler gesucht, der aufgetreten ist, als ein Terminal meinen Speicherplatz in einen Tab umgewandelt hat und die Absicht durcheinander gebracht wurde.)

Also fingen die Leute an, mehr und mehr in Rubin zu programmieren, weil es so entspannend war, Spaß machte und keine Wolke am Himmel war.

Paul Graham fasst es zusammen

Es ist sicher wahr, dass die meisten Leute Programmiersprachen nicht einfach aufgrund ihrer Verdienste wählen. Den meisten Programmierern wird gesagt, welche Sprache sie von jemand anderem verwenden sollen.

und

Um für Hacker attraktiv zu sein, muss eine Sprache gut sein, um die Arten von Programmen zu schreiben, die sie schreiben möchten. Und das bedeutet vielleicht überraschend, dass es gut sein muss, um Wegwerfprogramme zu schreiben.

Und wenn Sie im Lisp-Land waren, versuchen Sie, LISP durch Smalltalk zu ersetzen

Rubys Bibliotheken, Community und Dynamik sind gut

Wenn LISP immer noch leistungsfähiger als Ruby ist, warum nicht LISP verwenden? Die typischen Einwände gegen die Programmierung in LISP sind:

  1. Es gibt nicht genügend Bibliotheken.
  2. Wir können keine LISP-Programmierer einstellen.
  3. LISP ist in den letzten 20 Jahren nirgendwo hingegangen.

Dies sind keine überwältigenden Einwände, aber sie sind sicherlich eine Überlegung wert.

und

Angesichts der Wahl zwischen einer mächtigen Sprache und einer populären Sprache kann es sehr sinnvoll sein, die mächtige Sprache auszuwählen. Aber wenn der Unterschied in der Leistung gering ist, hat es viele nette Vorteile, beliebt zu sein. Im Jahr 2005 würde ich lange und gründlich nachdenken, bevor ich LISP anstelle von Ruby wähle. Ich würde es wahrscheinlich nur tun, wenn ich optimierten Code oder Makros benötige, die als vollwertige Compiler fungieren.

Jonke
quelle
4
Ähm, "die letzten 20 Jahre"?!?! Ich denke, Sie meinten "die letzten 51 Jahre". :-)
DigitalRoss
1
@ DigitalRoss - Ich würde mit 20 gehen; LISP war zu einem bestimmten Zeitpunkt in bestimmten Kreisen tatsächlich ziemlich groß, aber (trotz ViaWeb) wurden seit den 1980er Jahren keine neuen "Killer-Apps" mehr gesehen. LISP-basierte Technologien wurden jedoch in den 60er, 70er und 80er Jahren tatsächlich ziemlich viel finanziert. Die Leute dachten wirklich, dass LISP eine ganze Weile unterwegs war.
ConcernedOfTunbridgeWells
2
@DigitalRoss Ja, wenn Sie Dinge wie Fortsetzungen, Multimethoden, Makros, Tail-Call-Optimierungen ignorieren, aus dem Kopf.
Frank Shearar
Ich finde solche Argumente immer weniger akzeptabel. Es gibt keine beste Sprache und jeder Softwareentwickler kann Lisp, Schema, Ruby, PHP oder C oder was auch immer tun. Und wenn er nicht kann, kann er es in 2 Wochen lernen. Eine Sprache ist nur ein Werkzeug. Du musst nicht damit schlafen.
Edgar Klerks
22

Ich würde das Gegenteil sagen: Die Smalltalk-Syntax ist eine der einfachsten und leistungsfähigsten Programmiersprachen-Syntaxen.

Igor Stasenko
quelle
7
Ich möchte nur Amen sagen!
Schpaencoder
19

Es ist wahr, die Sprachen sind sehr ähnlich. Die flache Art, das zu interpretieren, besteht darin, Ruby als Smalltalk-Coverband zu bezeichnen. Die vernünftigere Interpretation ist, dass das geschlossene System von Smalltalk es isoliert hat, während Rubys Teilnahme an der Unix-Ökologie und die Gewohnheit, Funktionen aus jeder Sprache unter der Sonne zu übernehmen, ihm eine unendlich sanftere Akzeptanzkurve und eine mühelose Integration in Kickass-Tools wie Git verleiht.

Giles Bowkett

Vesan
quelle
17

Ratet mal, wer das gesagt hat? (Zitat ist nah, vielleicht nicht genau): "Ich dachte immer, Smalltalk würde Java schlagen. Ich wusste nur nicht, ob es dabei 'Ruby' heißen würde."

Trommelwirbel ....

...

Die Antwort ist ... Kent Beck

Charlie Flowers
quelle
15

Stephane Ducasse hat hier einige großartige Smalltalk-Bücher:

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

Obwohl die Smalltalk-Community nicht so produktiv ist wie die Ruby- und Rails-Community, gibt es immer noch eine große Hilfe.

Simon Knights
quelle
1
Dies verdient mehr positive Stimmen!
Froginvasion
15

Was hat Ruby, was Smalltalk nicht hat?

  • Massive, aktuelle Unterstützung durch wichtige Plattformen (IronRuby und jRuby), die die Bibliothek bereichern
  • Evangelisten wie Dave Thomas, die seit Jahren im ganzen Land unterwegs sind, um das Evangelium ihrer Sprache zu predigen. Ich habe Dave auf Java-Konferenzen gesehen, dass er Java nicht kennt und Ruby bevorzugt.
  • Starke, aktuelle Immobilien in den Bücherregalen
  • Der Schöpfer von Ruby hat gesagt, dass er an den Programmierer denkt: Rubys Syntax scheint diesen Zen-Reiz zu haben. Es ist schwer zu fassen, scheint aber die Fans zu galvanisieren.
  • Kreative, dynamische Präsentationen wie Giles und diese , die Mindshare gewinnen

Ich denke, Ihr Standpunkt ist gut aufgenommen. Wie ein Freund einmal sagte, könnte Ruby gegenüber Smalltalk "alter Wein in einer neuen Flasche" sein. Aber manchmal ist die neue Flasche wichtig. Ein Wein muss zur richtigen Zeit am richtigen Ort sein.

Michael Easter
quelle
Ihr erster Aufzählungspunkt ist aus. JVM- und .NET-VM-Unterstützung bedeuten für Smalltalk Mist, da jede Implementierung bereits auf einer VM ausgeführt wird (wie können sie sonst auf mehreren Betriebssystemen so gut ausgeführt werden, oder?). Rubys Syntax ist komplizierter als die von Smalltalk. Es ist schwer zu bestimmen, was Teil des Problems ist;)
1
Ja, ein Teil des Grundes, warum manche Leute jruny / ironruby verwenden, ist die relative Unreife des Ruby-VM, aber es gibt einige wirklich nette Bibliotheken für .net / jvm, die sie verwenden möchten und die an anderer Stelle keine Äquivalente haben Für einige Unternehmen ist es viel einfacher, sich mit ihren Java / C # -Codebasen zu vernetzen.
Roman A. Taycher
2
Natürlich habe ich festgestellt, dass das Schätzen von "starken, aktuellen Immobilien in den Bücherregalen" eine Strafe für eine komplexe Sprache ohne ein lebendiges, dynamisches Umfeld ist. Als ich in C ++ codierte, hatte ich Regale voller Gotcha-Bücher. Nachdem ich (über Ruby) zu Smalltalk gewechselt bin, vermisse ich sie kein bisschen. Ich verlasse mich auf die IDE selbst, um die meisten Anleitungen zu erhalten. Ich verlasse das Bild selten für mehr als eine schnelle Google-Suche und habe einige dieser
Regalimmobilien
14

Schlägt mich. Ich habe ein Jahr lang Ruby überprüft und einige kleinere Projekte durchgeführt, um zu sehen, wie es mir gefallen hat. Ich denke, ich bin ein Smalltalk-Fanatiker, denn jedes Mal, wenn ich mich hinsetzte, um mit Ruby zu arbeiten, seufzte ich und dachte: "Ich mache das wirklich lieber in Smalltalk." Schließlich gab ich nach und ging zurück zu Smalltalk. Jetzt bin ich glücklicher. Glücklicher ist gutmütig.

Was natürlich die Frage aufwirft: "Warum?". In keiner bestimmten Reihenfolge:

  1. Weil die IDE alles wegbläst, mit dem ich jemals gearbeitet habe. Dies umfasst eine Reihe von Plattformen von ISPF auf IBM-Mainframes bis hin zu Visual (. *) Von Microsoft, darunter Visual Basic 4-6, Visual C ++ (verschiedene Inkarnationen), Borlands Turbo Pascal und Nachkommen (z. B. Delphi) sowie DEC Maschinen sowohl im Zeichenmodus als auch unter X-Windows.
  2. Weil das Bild ein schöner Ort zum Leben ist. Ich kann dort finden, was ich will. Wenn ich nicht herausfinden kann, wie ich etwas tun soll, weiß ich, dass irgendwo auf dem Bild ein Beispiel dafür ist, was ich versuche - alles, was ich tun muss, ist zu jagen, bis ich es finde. Und es ist selbstdokumentierend - wenn Sie die Details der Funktionsweise von etwas sehen möchten, öffnen Sie einfach einen Browser für die Klasse, an der Sie interessiert sind, sehen Sie sich die Methode an und so funktioniert es. (OK, irgendwann wirst du etwas treffen, das ein Primitiv nennt, und dann ist es "hier gibt es Drachen", aber es ist normalerweise aus dem Kontext verständlich). Es ist möglich, ähnliche Dinge in Ruby / C ++ / C zu tun, aber es ist nicht so einfach. Einfach ist besser.
  3. Die Sprache ist minimal und konsistent. Drei Arten von Nachrichten - unär, binär und Schlüsselwort. Dies beschreibt auch die Priorität der Ausführung - zuerst unäre Nachrichten, dann binäre Nachrichten, dann Schlüsselwortnachrichten. Verwenden Sie Klammern, um zu helfen. Verdammt kleine Syntax, wirklich - alles wird mit dem Senden von Nachrichten erledigt. (OK, die Zuweisung ist kein Nachrichtenversand, sondern ein Operator. Also der 'return'-Operator (^). Blöcke werden von eckigen Klammern ([]) eingeschlossen. aber verdammt wenig ...).
  4. Blöcke. Ja, ich weiß, sie sind in Ruby (und anderen) da, aber verdammt, Sie können buchstäblich nicht in Smalltalk programmieren, ohne sie zu verwenden. Sie sind gezwungen , zu lernen , wie sie zu benutzen. Manchmal ist es gut, gezwungen zu werden.
  5. Objektorientierte Programmierung ohne Kompromisse - oder Alternativen. Sie können nicht so tun, als würden Sie "Objekte tun", während Sie immer noch dasselbe tun.
  6. Weil es dein Gehirn dehnen wird. Die komfortablen Konstrukte, an die wir uns alle gewöhnt haben (wenn-dann-sonst, do-while, für (;;) usw.), sind nicht mehr vorhanden, sodass Sie etwas Neues lernen müssen. Es gibt Äquivalente zu all dem (und mehr), aber Sie müssen lernen, anders zu denken. Anders ist gut.

Auf der anderen Seite ist dies möglicherweise nur das Geschwafel eines Mannes, der seit den Tagen programmiert hat, als Großrechner die Erde beherrschten. Wir mussten fünf Meilen laufen, um durch blendende Schneestürme zu arbeiten, bergauf in beide Richtungen, und Computer verwendeten Donuts als Speicher. Ich habe nichts gegen Ruby / Java / C / C ++ /, sie sind alle im Kontext nützlich, aber gib mir Smalltalk oder gib mir ... na ja, vielleicht sollte ich Lisp oder Scheme lernen oder ... :-)

Bob Jarvis - Monica wieder einsetzen
quelle
1
Ich dachte die Frage wäre "Was hat Ruby, was der Smalltalk nicht hat?"
Mauricio
1
@Mauricio und @Bob antworteten: "Schlägt mich."
Systemovich
1
Genial ausgedrückt, liebe es! Warum kann etwas nicht viel besser sein, obwohl es weniger beliebt ist? Wenn Sie nicht einverstanden sind, glaube ich, dass Sie Smalltalk nicht bekommen ;-)
Amos M. Carpenter
@aaamos - danke. Ich vermute, der Grund, warum Smalltalk nicht beliebt ist, liegt an # 6 und in geringerem Maße an # 5. Smalltalk ist nicht die "gleiche alte Syntax" Ihrer Mutter - es ist anders. Wenn Sie beispielsweise C kennen, fühlen sich C ++, Java und C # alle recht wohl. Und das "Wie" und "Warum" des Smalltalk-Verhaltens kann etwas umwerfend sein. (Ich gehe das Risiko ein, dass ein neuer Smalltalker, wenn er nicht das Gefühl hat, dass ihm der Kopf verdreht wird, entweder so brillant ist, dass er sofort geknackt hat, oder einfach nicht. Ja, ich frage mich, wie der "brillant" ist "ding würde sich anfühlen :-).
Bob Jarvis - Stellen Sie Monica
Haben Sie versucht, mit Pry (und Plugins) zu debuggen und mit gespeicherten Dateien live zu laden? Es war die beste Programmiererfahrung, die ich hatte.
Rivenfall
11

Smalltalk: Leute vorwärts ifTrue: [denken] ifFalse: [nicht denken]

Ruby: Die Leute denken vorwärts, wenn sie nicht rückwärts denken

1) Der RPN-ähnliche Kontrollfluss von Smalltalk durch Nachrichten ist wie bei Lisp - er ist regelmäßig und cool, macht aber die Leute verrückt.

2) Ruby lässt Leute Code auf die idiomatische Art und Weise schreiben, wie die Leute sprechen - mach bla, es sei denn, es gibt einen Grund, dies nicht zu tun .

Update hat das Smalltalk-Beispiel neu geschrieben, um tatsächlich mehr Rechtscode zu erhalten.

Andy Dent
quelle
4
Englisch ist wahrscheinlich die schlechteste Art, Programmieranweisungen auszudrücken. Ich meine, es verursacht genug Verwirrung unter den Menschen, geschweige denn unter Computern. Bla? Wer sollte bla tun? auf was? Auch Ihr Ruby-Code macht keinen Sinn und ist ungültig. Sollte sein: Ruby: people.think_forwards, außer people.think_backwards? und der SmallTalk sollte sein: Smalltalk: (Leute denken nach vorne?) ifTrue: [Leute denken nach vorne])
donalbain
2
Sie können der BlockClosure-Klasse auch eine Methode mit dem Namen aBlock aus der Kategorie Kernel-Methods hinzufügen, die aBlock und ifTrue: den aufrufenden Block auswerten würde.
Ricardo de Cillo
3
@donalbain, ich habe nicht vorgeschlagen, dass dies wörtliche Programmieranweisungen sind, sondern auf die Reihenfolge der Anweisungen hinweisen. Ich fand das ziemlich offensichtlich, als ich meine Antwort schrieb.
Andy Dent
1
@donalbain Sehr wahr, in der Tat existiert es. Weitere Ruby-ähnliche Kontrollflüsse finden Sie unter github.com/randycoulman/SuffixConditionals . Andy, es gibt einen Fehler in Ihrem Code - rückständige Leute denken nicht, also hätten Sie #ifFalse senden sollen :;-P
Sean DeNigris
Smalltalk hat schlechtes Marketing: seltsame Syntax und bildbasiert. Ruby ist normaler, hat aber auch eine gute Syntax. Java wird getippt und kompiliert, was die Clients beruhigt. Es würde mir nichts ausmachen, eine seltsame Syntax zu lernen und zu verwenden, wenn dies mein eigenes "Marketing" als Programmierer nicht beeinträchtigen würde.
Rivenfall
8

Ruby ist die aktuelle Buzz-Sprache. Es ist derzeit einfacher, damit erstellte Software zu vermarkten als eine in den 70er Jahren entwickelte Sprache.

coder1
quelle
Die Tatsache, dass es "in den 70er Jahren entwickelt" wurde, hat nichts damit zu tun, wie schwer es ist, sich damit zu entwickeln.
Gracchus
3
und mein Kommentar hat nichts mit Entwicklung zu tun.
Coder1
3
Tut mir leid, ich neige dazu, falsch zu lesen, wenn ich müde bin, also muss ich meine Urlaubszeit damit verbringen, mich bei Leuten zu entschuldigen, die ich gemobbt habe.
Gracchus
8

Gemeinschaft! Ruby und besonders Rails haben eine großartige Community. Beim Herumspielen mit Smalltalk schien es, dass nicht so viele Screencasts, Artikel, Blog-Beiträge usw. über Smalltalk geschrieben wurden.

Kevin Kaske
quelle
7

Sie haben die Frage in Ihrer ersten Zeile beantwortet: "Ruby wird immer beliebter"

  • Es gibt viel interessante Module, Projekte und dergleichen rund um Ruby.
  • Wenn Sie Probleme haben, etwas in Ruby zu tun, ist es trivial, irgendwo Hilfe zu finden.
  • Ruby ist auf einem installiert jetzt vielen Computern (es ist standardmäßig unter OS X, vielen Linux-Distributionen und guten Installationsprogrammen für Windows enthalten) - Ich habe nicht gesehen, dass Smalltalk standardmäßig auf einem von mir verwendeten Computer installiert ist.

Ich würde sagen, ob eine Sprache einer anderen überlegen ist oder nicht, ist irrelevant. Als Beispiel ist PHP möglicherweise nicht die "beste" Sprache aller Zeiten, aber ich würde trotzdem in Betracht ziehen, sie über Ruby on Rails zu verwenden (ein "besseres" Tool zum Erstellen Websites), weil es so weit verbreitet ist.

Grundsätzlich sind bestimmte Vor- und Nachteile einer Sprache weit weniger wichtig als alles, was sie umgibt - nämlich die Gemeinschaft.

dbr
quelle
7

Ruby (oder eine andere Sprache) ist beliebter als Smalltalk (oder eine andere Sprache), weil wir in einem chaotischen Universum leben. Nämlich:

  • Von Dave Thomas selbst: "[nach dem] Video über 'Wie man ein Blog in zehn Minuten erstellt' ... Ruby wurde von einer netten kleinen Nischensprache zu einer 'Sprache, in der Sie Rails-Apps geschrieben haben'" ( Ruby Conference) Keynote 2010 ).
  • Frühe Smalltalk-Anbieter berechnen unerschwinglich
  • Smalltalk, weil es vor 30 Jahren (vor seiner Zeit) erfunden wurde, kommt vielen als alte, "tote" Sprache vor (wie FORTRAN)
  • Unternehmen betrachten Smalltalk als einen solchen Wettbewerbsvorteil, dass sie seine Verwendung verbergen

Während die Sprachen in den OO-Funktionen ähnlich sind, ist Smalltalks Killer- Vorteil die offene Live-Umgebung (das vielfach missverstandene „Image“). Nachdem Sie sich dieses Beispiel für die Programmierung in Smalltalk angesehen haben , ist die Debatte beendet.

Sean DeNigris
quelle
5

Für mich ist es nicht so sehr ein Fall von dem, was Ruby hat, sondern was Ruby nicht hat. Und das, was es nicht hat, ist die Notwendigkeit einer VM und einer vollständigen Umgebung.

Smalltalk ist großartig - hier habe ich OO-Konzepte gelernt, aber aus Gründen der Benutzerfreundlichkeit habe ich mich für Ruby entschieden. Ich kann Ruby-Code in meinem Lieblingseditor schreiben und ihn über die Befehlszeile ausführen.

Für mich ist es das, was ich Ruby gegenüber Smalltalk wähle.

Simon Knights
quelle
Aber lernen Sie auch Smalltalk.
Simon Knights
Gemäß meiner Bearbeitung: Mit GNU Smalltalk können Sie Ihren bevorzugten Editor verwenden und über die Befehlszeile ausführen.
Zwei-Bit-Narr
Ja - Danke - habe gerade nachgesehen und eine Kopie heruntergeladen!
Simon Knights
2
Nun, es hat auch kein großartiges Webframework. Rails ist in Ordnung, aber es ist kein Meer
Stephan Eggermont
3
Auf jeder Smalltalk-Plattform können Sie Smalltalk-Code in Ihrem bevorzugten Editor schreiben. Aber wenn Sie von der Live-Welt getrennt werden möchten, haben Sie die Wahl. Sie müssen nur wissen, dass Sie dadurch etwa 90% der Produktivität verlieren.
Igor Stasenko
5

Ich denke, jeder, der schon eine Weile mit Ruby zusammenarbeitet, erkennt seine tiefe Schuld gegenüber Smalltalk an. Was mag ich als einer dieser Leute an Ruby over Smalltalk? Ich denke aus einer rein sprachlichen Perspektive, es ist der Zucker. Ruby ist absichtlich eine sehr syntaxzuckerhaltige Sprache, während Smalltalk eine sehr syntaxminimale Sprache ist. Ruby ist im Wesentlichen das Smalltalk-Objektmodell mit Perlish-Syntaxzucker. Ich mag den Zucker und finde, dass das Programmieren mehr Spaß macht.

Avdi
quelle
1
Ruby hat jedoch ein anderes Objektmodell als Smalltalk. Ich würde sagen "beeinflusst von", aber nicht dasselbe. Sie können Ruby-Programme prototypbasiert schreiben, ohne dass neue Klassen erstellt werden müssen. Obwohl dies ungewöhnlich ist, unterstützt Smalltalk dies einfach nicht.
Dafydd Rees
2
Ich mag Smalltalk, weil ich eigenen Syntaxzucker erfinden und verwenden kann, wann immer ich ihn brauche. Zucker wird nicht benötigt, wenn Sie bereits alles mit minimaler Syntax ausführen können.
Igor Stasenko
5

Sie können ziemlich leicht einen Job bei Ruby finden.Obwohl ich Smalltalk wirklich liebe, ist es praktisch unmöglich, in die Smalltalk-Nische zu gelangen. Es gibt Arbeit darin, aber wenn Sie nicht reingekommen sind, als es populär war, ist es jetzt praktisch unmöglich.

Alle anderen Gründe sind unbedeutend, weil Sie viel Zeit darauf verwenden müssen, sich auf echte Arbeit zu konzentrieren, um eine Sprache richtig zu lernen. Wenn Sie nicht unabhängig wohlhabend sind, ist der beste Weg, dies zu tun, die Exposition bei der Arbeit.

daf
quelle
4

Weil Smalltalk-Distributionen ein Vielfaches von 1000 USD kosten, während Ruby kostenlos ist.

grettke
quelle
4

Ruby ist zu Smalltalk wie arabische Ziffern zu römischen Ziffern. Gleiche Mathematik, einfachere Syntax.

sal
quelle
3
Das ist der falsche Weg. Smalltalk hat eine viel einfachere Syntax.
Stephan Eggermont
1
Nur wenn du in rpn denkst. Die meisten Leute tun das nicht. Ich bin wirklich stolz darauf, dass dieser Beitrag immer wieder auf und ab geht.
Sal
12
RPN? Java: foo.bar () Perl: foo-> bar () Python: foo.bar () Smalltalk: foo bar Wenn Sie also eine einfachere Syntax haben und behaupten, Smalltalk sei RPN, müssen Sie sagen, dass alle wichtigen OO-Sprachen sind "RPN".
Randal Schwartz
2
Vergleichen Sie einfach die Anzahl der Ruby-Keywords mit der Anzahl der Smalltalk-Keywords. Und das ist erst der Anfang! Die Syntax von Smalltalk passt auf eine Serviette. Versuchen Sie das mit Ruby, und Sie werden es schwer haben.
Froginvasion
3

Ich habe ein wenig Smalltalk gemacht - die IDE ist eine Sache, an die ich mich erinnere - hat Ruby eine gute IDE-Unterstützung?

Chris Kimpton
quelle
Ja. TextMate ist großartig, die Eclipse-Unterstützung ist gut und Emacs hat einen anständigen Modus.
Pete
6
Wenn Sie der Meinung sind, dass "TextMate / Eclipse / Emacs" mit der in Smalltalk integrierten IDE vergleichbar ist, haben Sie keinen echten Smalltalk gesehen!
Randal Schwartz
Ich vermisse immer noch select -> 'Show It' von IDEs auf den Systemen, mit denen ich heute baue - mit einer Ausnahme: Mit den SQL-Entwicklungstools von SQL Server können Sie eine Auswahl markieren und als Abfrage ausführen. Smalltalk ist einflussreich, wenn nichts anderes!
ConcernedOfTunbridgeWells
Die IDE, die Smalltalk am nächsten kommt, ist IMHO ArachnoRuby. Es ist besser integriert als jedes Emacs / TextMate usw. Es scheint jedoch, dass die Leute mit ein paar geöffneten Fenstern, in denen verschiedene Tools ausgeführt werden, sehr zufrieden sind. Grüße
Friedrich
@Friedrich Re "Die Leute sind sehr zufrieden mit ein paar geöffneten Fenstern, in denen verschiedene Tools ausgeführt werden" ... "Programmiersprachen lehren Sie, nicht zu wollen, was sie nicht bieten können. Sie müssen in einer Sprache denken ..." - Paul Graham
Sean DeNigris
3

Verwenden Sie Ruby, weil es möglicherweise geschäftliche Aspekte hat, Smalltalk jedoch nicht.

Ich kann es Ihnen aus persönlicher Erfahrung erzählen. Ich benutze immer noch Smalltalk, liebe es und habe ein paar Geschmacksrichtungen verwendet. Obwohl Smalltalk eine großartige Sprache ist und alles ist, was Sie erwähnt haben, werden Sie den durchschnittlichen CIO / CTO wahrscheinlich nicht davon überzeugen, Smalltalk für ein neues Projekt zu verwenden. Natürlich fällt es Ihnen möglicherweise sogar schwer, einen konservativen CIO / CTO von Ruby zu überzeugen. Am Ende müssen Sie sehr vorsichtig sein, wenn Sie eine nachhaltige langfristige kommerzielle Unterstützung und die Fähigkeit wünschen, Mitarbeiter von der Straße zu finden, die Ihre Systeme in Zukunft unterstützen können. Zum Beispiel war Smalltalk in den frühen 90ern eine wirklich große Sache, und IBM investierte in den späten 90ern stark in sie. Für IBM sollte Smalltalk die nächste Sprache für alle Geschäftsanwendungen sein. IBM hat Smalltalk auf alles angewendet, einschließlich der Mainframe-Systeme. Java wurde populär, übernahm den Markt, und Smalltalk wurde ein Nischenspieler. Vor über einem Jahr hat IBM die Sprache abgeladen (der Begriff ist Sonnenuntergang). Schauen Sie sich auch die Geschichte an. ParkPlace und Digitalk, wo die ersten großen kommerziellen Akteure in der Smalltalk-Arena fusionierten und dann ihr Geschäft aufgaben.

daduffer
quelle
Smalltalk "hat Geschäftsbeine" - wenn Sie bereits den richtigen Hintergrund haben und die richtigen Möglichkeiten finden können ...
Dafydd Rees
Ihr Titel ist weit überbewertet. Nicht jedes Geschäft wird durch kurzsichtige CTOs eingeschränkt. Wie Paul Graham sagte, als er den Mythos, dass eine Mainstream-Sprache sicherer ist, gründlich entlarvte: "Es wird Ihnen schwer fallen, den spitzen Chef davon zu überzeugen, dass Sie Dinge in Lisp bauen können ... Aber wenn Sie für ein Startup arbeiten, das dies nicht tut." Wenn Sie noch keine spitzen Chefs haben, können Sie ... Technologien einsetzen, die Ihre Konkurrenten, die unbeweglich mit der Mediansprache verbunden sind, niemals erreichen können. "
Sean DeNigris
2

Ich liebe sowohl Smalltalk als auch Ruby - aber ich habe festgestellt, dass Ruby besser auf das anwendbar ist, was ich täglich mache, und mir (praktisch) näher am Herzen liegt. Was bietet Ruby, was Smalltalk nicht bietet?

  • Textbasiertes Scripting
  • Geringe Implementierungsanforderungen (wird an mehreren Stellen ausgeführt)
  • Einfacher zu lernen und zu rechtfertigen (Perl- und Python-Programmierer haben keine Probleme
  • Einfacheres Verschieben von Programmen - Textdateien!
  • Interfaces gut mit nativer Umgebung
  • Überall dort, wo Java ausgeführt wird, wird jRuby ausgeführt ...
  • Größere und viel aktivere Community

Einige haben gst (GNU Smalltalk) erwähnt; Die Probleme halten immer noch an.

Mei
quelle
Welche "Orte" führt Ruby aus, die Smalltalk nicht betreibt? Pharo Smalltalk läuft beispielsweise unter Mac, Windows und Unix ohne Betriebssystem (kann Ruby das?) Und wird auf verschiedene mobile Plattformen (Android, iOS) portiert.
Sean DeNigris
Wie wäre es mit FreeBSD und OpenBSD? (Nein, ich weiß die Antwort nicht ...) Wie wäre es mit Solaris und HP-UX und OpenVMS? Ich möchte auch weder Ruby noch Smalltalk unter Android oder iOS verwenden. Das größte Problem ist nicht das Betriebssystem, sondern der Speicher: Ruby wird in erheblich weniger Speicher als Smalltalk ausgeführt.
Mei
Anscheinend gibt es eine FreeBSD-VM (siehe den letzten Punkt des OP unter forum.world.st/SOB-minutes-3-6-12-td4453817.html ). Bei den anderen bin ich mir nicht sicher. Was Android und iOS betrifft, stellt sich die Frage, ob Sie Smalltalk verwenden möchten, anders als ob es verfügbar ist ;-) Über erfolgreiche Experimente auf diesen Plattformen wurde berichtet, von denen ich einige vielversprechende Screencasts gesehen habe.
Sean DeNigris
Das erinnert mich auch - ich erinnere mich an ein Smalltalk für die Handfläche.
Mei
2

Verwenden Sie alles, was Sie leistungsfähiger und schneller macht, um Ihre Herausforderung zu meistern.

Für uns ist ein kleiner hausinterner Rahmen, den wir oben am Meer gebaut haben, wirklich unsere Supermacht.

Ich liebe die RoR-Community, sie hat die richtige Einstellung. Das ist sehr sehr wertvoll. Gleichzeitig macht Sie das Meer technologisch stärker gegen kompliziertere Probleme.

Mit Open-Source-Inhalten können Sie großartige Web-Apps am Meer erstellen.

dabbledb war ein Sartup, der auf dem Meer basiert und, hey! Avi hat es dieses Jahr im Juni an Twitter verkauft!

Ich sage, Sie müssen nicht darauf warten, dass andere Ihre Initiative genehmigen.

TU es einfach. Mach es fertig. Zeigen Sie uns, dass funktioniert.

Du bist nicht allein. Wir sind auf dem gleichen Boot.

Sebastian Sastre
quelle
2

Interessante Perspektive von Robert Martin (von RailsConf 2009): "Was Smalltalk tötete, könnte auch Ruby töten"

jmay
quelle
2
Dieses Gespräch setzt voraus, dass Smalltalk tot ist (es ist nicht) und dass Rubin Smalltalk in Raum und Zeit ähnlich genug ist, um das gleiche (Nicht-) Schicksal zu erleiden. Ist es nicht.
Randal Schwartz
0

Ich denke, ein Teil des Problems ist die Entwicklungsumgebung, die die Laufzeit ist. Dies gibt viel Kraft, aber auch eine größere Lernkurve.

Hier ist ein Hallo Welt Tutorial.

Dies unterscheidet sich stark von anderen Sprachen, in denen ich nur wissen muss, wie man einen Texteditor öffnet und Text kopiert und einfügt, auf Speichern klickt und einen Compiler ausführt. Ich muss wissen, wie man mit der Umwelt umgeht. Dieses Tutorial zeigt mir nicht einmal, wie man ein Basisprogramm erstellt (was wahrscheinlich eher ein Fehler dieses Tutorials ist), das ich ausführen kann.

Es gibt definitiv höhere Kosten, um die Dinge zum Laufen zu bringen als die meisten anderen Sprachen.

Die meisten Sprachen haben einen schönen auffälligen Code, den sie zur Schau stellen können. Das habe ich bei Smalltalk nicht gesehen. Ich denke auch, dass Smalltalk ein Stigma hat, weil es so lange existiert und es immer noch relativ dunkel ist.

Steve g
quelle
Am Ende der Seite: Selbstinformation: 'Hallo Welt!'. Ich stimme zu, dass die Lernkurve steiler ist, aber "Hallo Welt" als Beweis zu verwenden, denke ich, ist zu viel. :)
jop
Mein Punkt war zu sehen, wie man etwas Einfaches wie Hallo Workld schreibt. Das Tutorial muss Ihnen sagen, welche Fenster Sie öffnen müssen. Die Namen und Verwendungszwecke der Fenster kann ich nicht erraten. Ich musste ein wenig herumklicken, um die Fenster zu finden, von denen es sprach.
Steve g
1
Gemäß meiner Bearbeitung: Mit GNU Smalltalk können Sie Ihren bevorzugten Editor verwenden und über die Befehlszeile ausführen.
Zwei-Bit-Narr
ruby -e 'setzt "Hallo Welt"'
Marcel Valdez Orozco
1
pharo [Bilddateiname] -e "Selbstinformation: 'Hallo Welt'"
Sean DeNigris
0

Ich denke, der größte Unterschied ist, dass Ruby Perl in Bezug auf die NUTZUNG viel ähnlicher ist. Smalltalk hat nie in den "Skriptsprachen" Fuß gefasst.

Die VM ist wirklich cool und ich hoffe, dass Ruby etwas Ähnliches hat, damit wir alles auf unserem Betriebssystem, was in Ruby geschrieben ist, als Objekt im Speicher behandeln können. Bis dahin genieße ich einfach Rubys knappe, kurze Syntax, die Fähigkeit, einfach zu sein Schreiben Sie ein kleines Skript und verwenden Sie es später wieder. Ruby hat alle Vorteile von Perl und die OOP ist Smalltalk viel ähnlicher als der OOP-Hack von Perl.

sie
quelle
0

Ich würde weiter gehen als Jonkes Antwort und sagen, dass es mittlerweile eine große Anzahl von Sprachen gibt, die eine sehr starke Community haben, fast genug für jeden Geschmack, und eine Untergruppe davon hat Mainstream-Anerkennung (dh Ihr Manager lässt Sie sie verwenden auch arbeiten).

Es ist einfach, die Grundlagen einer Sprache zu erlernen, aber um sie tatsächlich effektiv zu nutzen, müssen Sie genügend Zeit investieren, um die Plattform und die Tools sowie die Syntax und die Redewendungen zu erlernen. Laut McConnell dauert es ungefähr drei Jahre, bis IIRC wirklich kompetent ist.

Angesichts dieser Dinge ist es schwer zu rechtfertigen, viel Zeit mit Sprachen wie LISP und Smalltalk zu verbringen, obwohl sie interessant und vielleicht lehrreich anzusehen sind.

Stuart Ellis
quelle
0

Als Neuling in der Diskussion besteht das Hauptproblem bei Smalltalk und Lisp darin, dass Sie sie nicht mit CGI oder FastCGI auf Shared Hosting ausführen können.

Die ungewaschenen Massen werden sie niemals verwenden, wenn sie VPS oder dedizierte Server benötigen, um sie zu verwenden. IMHO Seaside ist fast allem überlegen, aber läuft es auf Dreamhost oder Webfaction?

vfclists
quelle
Ich frage mich, ob dies jetzt noch ein großes Hindernis ist, da beispielsweise Digital Ocean VPS für 0,007 USD / Std.
Anbietet