Warum Ruby anstelle von Smalltalk verwenden? [geschlossen]

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:

• Reife (entwickelt in den 1970er Jahren)
• Stabilität
• Kommerzielle Unterstützung
• Verteilte Quellcodeverwaltung (versteht die Struktur des Codes, nicht nur den Textunterschied)
• Mehrere Implementierungen der VM
• Plattformübergreifende Unterstützung
• Das Seaside Web Framework als starke Alternative zu Rails

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

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.

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.

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.

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

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

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

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.

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.

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 ... :-)

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.

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

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.

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.

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.

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.

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.

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.

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

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

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

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.

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.

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.

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

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.

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.

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.

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?