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
quelle
Antworten:
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.
quelle
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.
quelle
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
und
Und wenn Sie im Lisp-Land waren, versuchen Sie, LISP durch Smalltalk zu ersetzen
und
quelle
Ich würde das Gegenteil sagen: Die Smalltalk-Syntax ist eine der einfachsten und leistungsfähigsten Programmiersprachen-Syntaxen.
quelle
Giles Bowkett
quelle
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
quelle
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.
quelle
Was hat Ruby, was Smalltalk nicht hat?
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.
quelle
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:
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 ... :-)
quelle
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.
quelle
Ruby ist die aktuelle Buzz-Sprache. Es ist derzeit einfacher, damit erstellte Software zu vermarkten als eine in den 70er Jahren entwickelte Sprache.
quelle
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.
quelle
Sie haben die Frage in Ihrer ersten Zeile beantwortet: "Ruby wird immer beliebter"
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.
quelle
Ruby (oder eine andere Sprache) ist beliebter als Smalltalk (oder eine andere Sprache), weil wir in einem chaotischen Universum leben. Nämlich:
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.
quelle
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.
quelle
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.
quelle
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.
quelle
Weil Smalltalk-Distributionen ein Vielfaches von 1000 USD kosten, während Ruby kostenlos ist.
quelle
Ruby ist zu Smalltalk wie arabische Ziffern zu römischen Ziffern. Gleiche Mathematik, einfachere Syntax.
quelle
Ich habe ein wenig Smalltalk gemacht - die IDE ist eine Sache, an die ich mich erinnere - hat Ruby eine gute IDE-Unterstützung?
quelle
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.
quelle
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?
Einige haben gst (GNU Smalltalk) erwähnt; Die Probleme halten immer noch an.
quelle
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.
quelle
Interessante Perspektive von Robert Martin (von RailsConf 2009): "Was Smalltalk tötete, könnte auch Ruby töten"
quelle
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.
quelle
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.
quelle
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.
quelle
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?
quelle