Warum sollte ich Ruby lernen (noch so eine Hirnrissige frage)
-
user-l schrieb:
wenn man nicht unbedingt Rails braucht, fällt mir kein besonders guter Grund ein, Ruby zu lernen oder zu benutzen.
Ruby ist wirklich vielfältig einsetzbar, nicht nur für das Web. Wenn man z.B. eine flexible Skriptsprache zur Stringverarbeitung braucht (was man früher vielleicht in Perl gemacht hat), ist Ruby gut einsetzbar. Interessant ist auch die Möglichkeit, eine DSL auf Ruby-Basis zu definieren und zusammen mit anderen Sprachen einzusetzen (z.B. Java-Skripting).
Diese Möglichkeiten bieten andere Skriptsprachen natürlich auch. Aber früher oder später wird man sich für eine Entscheiden. Warum also nicht für Ruby?Die einzelnen Sprachelemente von Ruby kann man schon seit Jahren, teils seit Jahrzehnten haben, indem man je nach Anwendungszweck Perl, Python oder Smalltalk usw. verwendet - bei Ruby in einer einzelnen Sprache zusammengefaßt.
Das ist doch ein Vorteil.
Aber ob es gut ist, Perl-Elemente und Smalltalk-Blocks in eine Python-ähnliche OO-Skriptsprache hineinzurühren, scheint mir ohnehin fraglich.
Was sollte daran fraglich sein? Welche Perl-Elemente glaubst du in Ruby zu entdecken? (sag nicht '@' und '$').
-
Meiner Meinung nach vereint Ruby jeweils einige Eigenschaften mehrerer altbewährter Sprachen (Tcl, Python, Perl, Smalltalk) in sich, ohne Vorteile zu bieten.
Die Syntax von Ruby finde ich überflüssig kompliziert, weil es für fast jeden Zweck etliche verschiedene Konstrukte gibt, die sich teils in Nuancen unterscheiden (allein für Blocks 6 oder 7 Konstrukte, glaube ich, wer braucht das denn ?). Man vergleiche das mal mit der schlüssigen Syntax von Python, die selbst für Leute lesbar ist, die Python gar nicht kennen.
Die Vielfalt an Sprachkonstrukten ist bei Ruby vergleichsweise groß, ohne, daß man damit die Flexibililtät der Klassiker (Lisp, Smalltalk, Forth) erreichen könnte. Prinzipienreinheit führt langfristig weiter als syntaktische Rafinesse.
Um bspw. zu Tcl oder Lisp ein Objektmodell hinzuzufügen, braucht man keine neue Syntax - ein paar Zeilen Tcl- oder Lisp-Code reichen dazu. Das ist *wahre* Flexibilität.Diejenigen Sprach-Elemente, die Ruby von Smalltalk übernommen hat (Objekte, Iteratoren, Blocks), können es auch nicht herausreißen - wenn man OO ernstnimmt, kommt man früher oder später ohnehin bei Smalltalk an.
Immerhin ist Ruby ein weiterer Schritt in Richtung echte Objektorientierung.
Es kann also nur noch ein paar Jahrzehnte dauern, bis man erkennt, daß alles, was es in dieser Hinsicht zu machen gibt, schon seit 1972 da ist: Smalltalk.
-
user-l schrieb:
Meiner Meinung nach vereint Ruby jeweils einige Eigenschaften mehrerer altbewährter Sprachen (Tcl, Python, Perl, Smalltalk) in sich, ohne Vorteile zu bieten.
Ich sehe schon Vorteile: Die gute Textbearbeitungsfunktionen von Perl (RegEx als Sprachelement) und dessen Ausdrucksstärke, ohne die kryptischen Syntaxmacken. Ein strenges Typsystem wie bei Python und Smalltalk, und kein schwaches wie bei Perl. Eine eingebaute vernünftige Objektorientierung (vs. Perl), die auch noch so aussieht und nicht aufgesetzt wirkt (vs. Python).
Flexible Blöcke (bzw. Closures) wie in Smalltalk (vs. Python).Die Syntax von Ruby finde ich überflüssig kompliziert, weil es für fast jeden Zweck etliche verschiedene Konstrukte gibt, die sich teils in Nuancen unterscheiden (allein für Blocks 6 oder 7 Konstrukte, glaube ich, wer braucht das denn ?). Man vergleiche das mal mit der schlüssigen Syntax von Python, die selbst für Leute lesbar ist, die Python gar nicht kennen.
Alles Geschmakssache. Ich finde die Python-Syntax gründlich misslungen. Dabei meine ich nichtmal die manchmal kontrovers diskutierten Whitespace-Syntaxelemente. Das OO wirkt an manchen Stellen einfach aufgesetzt. Wozu ständig self? Wer braucht das? Wozu die "globalen Funktionen", die dann doch nur auf geheime Unterstrich-Unterstrich-Funktoren zugreifen? Warum nicht gleich als Methode? Warum Unterstriche als Sichtbarkeitsmodifier. Entweder ganz /Ruby) oder gar nicht (Smalltalk). Sehr unästetisch das ganze. Aber es ist wie gesagt Geschmackssache und müßig darüber zu streiten.
Mit den verschiedenen Konstrukten in Ruby hatte ich noch nie Probleme. Ich kenne auch niemanden, der Schwierigkeiten beim Verständis damit hätte. Wenn man nicht eine ganz lange Leitung hat, versteht man sowohl Blöcke mit "{ }" alsauch mit "begin end" (so groß ist die Anzahl der Möglichkeiten nicht). Mir ist es lieber, die Sprache gibt mir Freiheiten beim Ausdruck, als dass sie den einzig wahren Weg vorschreibt.
Die Möglichkeiten eine DSL darauf aufzubauen (die eventuell auch von Nichtprogrammieren verstanden werden soll), profitiert auch von diesen Freiheiten. Keine überflüssigen Doppelpunkte, Klammern oder Whitespaces.Die Vielfalt an Sprachkonstrukten ist bei Ruby vergleichsweise groß, ohne, daß man damit die Flexibililtät der Klassiker (Lisp, Smalltalk, Forth) erreichen könnte. Prinzipienreinheit führt langfristig weiter als syntaktische Rafinesse.
Um bspw. zu Tcl oder Lisp ein Objektmodell hinzuzufügen, braucht man keine neue Syntax - ein paar Zeilen Tcl- oder Lisp-Code reichen dazu. Das ist *wahre* Flexibilität.Wobei diese Art Flexibilität bei Sprachen, die OO von vornherein unterstützen, auch überflüssig wäre.
Diejenigen Sprach-Elemente, die Ruby von Smalltalk übernommen hat (Objekte, Iteratoren, Blocks), können es auch nicht herausreißen - wenn man OO ernstnimmt, kommt man früher oder später ohnehin bei Smalltalk an.
Jedenfalls nicht bei Python
Immerhin ist Ruby ein weiterer Schritt in Richtung echte Objektorientierung.
Es kann also nur noch ein paar Jahrzehnte dauern, bis man erkennt, daß alles, was es in dieser Hinsicht zu machen gibt, schon seit 1972 da ist: Smalltalk.Leider gewinnen nicht immer die besten. Siehe C++. Siehe PHP.
-
Wenn du Ruby eine vernünftige Objektorientierung attestierst, was sagst du dann zu Smalltalk ?
Ob einem die Python Syntax gefällt oder nicht, ist sicher Geschmackssache.
Offenbar im Ggs. zur Ruby Syntax basiert sie immerhin auf Prinzipien, z.b. dem Prinzip "nur ein Konstrukt pro Aufgabe" oder "einfache Lesbarkeit".Wenn Du keine Probleme mit Ruby-Idiomen hast, dann erkläre doch mal eben auswendig die 6 oder 7 Methoden, Blocks zu benutzen.
Wieso soll Ruby für DSLs geeignet sein ? Dafür braucht man flexible Sprachen mit *wenig* Syntax, wie Lisp, Tcl oder Smalltalk, notfalls Forth.
btw. Die Syntax der von mir genannten "Evergreens" Lisp, Tcl, Smalltalk aufzuschreiben benötigt jeweils kaum mehr als eine halbe Seite. Ruby-Syntax ist m.M.n. monströs und zudem häßlich.
-
user-l schrieb:
Wenn du Ruby eine vernünftige Objektorientierung attestierst, was sagst du dann zu Smalltalk ?
Wo sage ich, dass Smalltalk keine vernünftige OO hat?
Ob einem die Python Syntax gefällt oder nicht, ist sicher Geschmackssache.
Mein Reden. Entweder man hat Geschmack oder man hat keinen. Deswegen ist es wohl auch sinnlos, hier weiter zu diskutieren.
-
ist eine harte Nuß, das mit dem Erklären der 7 closure/block-ähnlichen Sprachkonstrukten in Ruby, nicht ?
Hier die Auflösung: google nach closures-in-ruby.rb
Bist du jetzt immer noch sicher, daß Du keine Probleme mit den Sprachelementen von Ruby hast ?
Smalltalk hat nur *ein* Syntaxelement für Blocks. Reicht vollkommen aus.
Ich halte Ruby syntaktisch und semantisch für einen großen Rückschritt gegenüber anderen dynamischen Programmiersprachen wie Tcl, Lisp und Smalltalk, die Jahrzehnte älter und um Dimensionen einfacher und klarer konzipiert sind.
-
Die ganze Zeit redest du von Blocks und jetzt kommen Closures ins Spiel? Vielleicht lernst du erstmal den Unterschied!
Zu deiner Beruhigung: die Closure-Konstrukte unter Section 2 (falls du das mit "7 Arten von 'Blocks'" meintest) kenne ich. Auch die damit verbundenen Fallen (lambda vs. Proc, Arity).
Das wird ja auch in jeder (guten) Grundlagenliteratur hinreichend erläutert. Wem das zu hoch ist, muss eben bei Python bleiben.Die Ungereimtheiten in Ruby bzgl. Closures sind unschön aber nicht weiter gefährlich. Solche Pitfalls gibt's wohl in jeder Sprache. Außerdem sind speziell diese Probleme Gegenstand einer Überarbeitung für Version 1.9. Die Sprache entwickelt sich weiter.
-
ich würde dennoch von Ruby abraten.
Es gibt dynamische Programmiersprachen, die
1. sich jahrzehntelang bewährt haben,
2. auf einigen klar definierten Prinzipien beruhen und
3. mit einfacher Syntax und Semantik dieselben Probleme lösen können wie ruby.Als Beispiele nenne ich hier Tcl, Lisp, Smalltalk, ferner Python.
Ich kann schlicht keinen Bedarf für weitere Sprachen in dieser Richtung erkennen - mit Smalltalk ist doch seit den 70er Jahren schon alles gesagt, was es zum Thema "dynamische, objektorientierte Programmiersprachen" zu sagen gibt.
Wie man an Ruby sieht, führen weitere Sprachen dieses Typs dazu, Sprachelemente wiederzuentdecken, die Lisp & Co. seit vielen Jahrzehnten bieten, nur bei den Klassikern mit einfacher Syntax und wenigen, klar definierten Prinzipien.
-
Schön, dass wir das mit den Blocks geklärt hätten.
user-l schrieb:
ich würde dennoch von Ruby abraten.
Es gibt dynamische Programmiersprachen, die
1. sich jahrzehntelang bewährt haben,
Was nichts über Ruby aussagt.
2. auf einigen klar definierten Prinzipien beruhen und
Was auch immer du damit meinst.
3. mit einfacher Syntax und Semantik dieselben Probleme lösen können wie ruby.
Jetzt kommt auch noch Semantik ins Spiel...
Ich kann hier wirklich keine Argumente gegen Ruby entdecken.
Als Beispiele nenne ich hier Tcl, Lisp, Smalltalk, ferner Python.
Ich kann schlicht keinen Bedarf für weitere Sprachen in dieser Richtung erkennen - mit Smalltalk ist doch seit den 70er Jahren schon alles gesagt, was es zum Thema "dynamische, objektorientierte Programmiersprachen" zu sagen gibt.
Das sag doch mal all den tausenden Entwicklern und Benutzern von Python, Ruby, Lua, Groovy und wie sie alle heißen. Deren Relevanz scheint mir größer zu sein, als die von Smalltalk.
Wie man an Ruby sieht, führen weitere Sprachen dieses Typs dazu, Sprachelemente wiederzuentdecken, die Lisp & Co. seit vielen Jahrzehnten bieten, nur bei den Klassikern mit einfacher Syntax und wenigen, klar definierten Prinzipien.
Lisp und "klare Prinzipien" - da kann man geteilter Meinung sein. Jedenfalls haben einige Leute einen Bedarf nach einer klareren, einfacheren und schöneren Sprache gesehen und den Lisp-Dialek Scheme erfunden...
-
wir halten fest: von 7 verschiedenen Sprachelemente für closure-ähnliche Sachen sind ein paar (6 z.B.) zuviel.
Mit "klar definierten Prinzipien" meine ich Dinge wie:
Lisp: "alles ist eine Liste"; Smalltalk: "alles ist ein Objekt und jeder Befehl eine Nachricht"; usw.Übrigens liegen auch Python einige festgeschriebene Prinzipien zugrunde, darunter das Prinzip, für jeden Zweck ein (und nur ein) syntaktisches Element zu benutzen ("the Pythonic way of doing something").
Solche einfachen Prinzipien erkenne ich an Ruby nicht. Es sei denn, das "principle of my maximum surprise", weil kaum etwas so funktioniert, wie ich es erwarte.
Zur Relevanz von Smalltalk, die du offenbar anzweifelst:
Smalltalk ist das Resultat der Sprachenentwicklung, wenn man dynamische, objektorientierte Programmierung - eigentlich besser: Objektprogrammierung - zuende denkt.
Insofern ist es unausweichlich, daß sich zukünftige Programmiersprachen, die den Anspruch erheben, objektorientiert zu sein, an Smalltalk annähern.
Schleierhaft bleibt mir, wieso man nicht gleich Smalltalk nimmt, statt einen jahrzehntelangen Umweg über verschiedene dynamische Skriptsprachen zu gehen, der letztendlich ohnehin wieder dorthin führt, wo Smalltalk schon immer ist.
-
Ruby ist ja eigentlich eine Art Smalltalk++, also wozu noch Smalltalk?
(siehe Mixins, Metaprogramming usw.)
-
user-l schrieb:
Schleierhaft bleibt mir, wieso man nicht gleich Smalltalk nimmt, statt einen jahrzehntelangen Umweg über verschiedene dynamische Skriptsprachen zu gehen, der letztendlich ohnehin wieder dorthin führt, wo Smalltalk schon immer ist.
Meinst du syntaktisch an Smalltalk annähern oder vom Konzept? Beim Konzept ist Java ja teilweise schon recht nahe, mit Garbage Collector, Zwischencode und was-weiß-ich-nicht-was-alles. Ich denke syntaktisch hat sich über die letzten 20 Jahre klar die C-Syntax etabliert, kann sich aber natürlich auch noch ändern.
-
ich meine syntaktisch und konzeptuell, denn das hängt ja bei echter Objektprogrammierung stark voneinander ab.
Wenn man die OO-Prinzipien "alles ist ein Objekt" und "alle Befehle sind Nachrichten an Objekte" streng beachtet, dann kann das Ergebnis eigentlich nur ähnlich wie Smalltalk aussehen, syntaktisch wie konzeptuell - die Syntax von Smalltalk besteht doch aus kaum mehr als dem Senden von Nachrichten, aus Blocks und aus einigen wenigen Syntaxelementen für die Vereinbarung von Konstanten.
@smalltalk: finde ich nicht, eher --Smalltalk + 1/Perl + e^(-Python)
-
user-l schrieb:
Mit "klar definierten Prinzipien" meine ich Dinge wie:
Lisp: "alles ist eine Liste"; Smalltalk: "alles ist ein Objekt und jeder Befehl eine Nachricht"; usw.Wenn du hier einen Gegensatz zu Ruby siehst, behaupte ich, dass du dich mit dieser Sprache nicht hinreichend auseinander gesetzt hast.
Übrigens liegen auch Python einige festgeschriebene Prinzipien zugrunde, darunter das Prinzip, für jeden Zweck ein (und nur ein) syntaktisches Element zu benutzen ("the Pythonic way of doing something").
Und ich finde dieses Prinzip ist scheiße. Wenn du eine Zwangsjacke beim Programmieren brauchst, bitte. Ich zieh mir das nicht an.
Zur Relevanz von Smalltalk, die du offenbar anzweifelst:
Smalltalk ist das Resultat der Sprachenentwicklung, wenn man dynamische, objektorientierte Programmierung - eigentlich besser: Objektprogrammierung - zuende denkt.
Ich bezweifle nicht den Verdienst von Smalltalk im Hinblick auf die Entwicklung von OO. Mit Relevanz meine ich die allgemeine Popularität und Präsens am Markt (was nichts über die Sprachqualität aussagt). Und hier kann Smalltalk nicht mithalten.
Schleierhaft bleibt mir, wieso man nicht gleich Smalltalk nimmt, statt einen jahrzehntelangen Umweg über verschiedene dynamische Skriptsprachen zu gehen, der letztendlich ohnehin wieder dorthin führt, wo Smalltalk schon immer ist.
Ein ewiges Mysterium....
-
jetzt machst du mich aber neugierig darauf, welche einfachen Prinzipien das sein könnten, die Ruby zugrundeliegen.
"the Pythonic way" ist keine "Zwangsjacke", sondern die Einsicht, daß Lesbarkeit von Code wichtiger ist als syntaktische Finessen, vor allem, wenn der Code in einigen Jahren gewartet oder erweitert werden muß. Code wird nur einmal geschrieben, aber mehrmals gelesen.
Aber es geht hier doch eigentlich gar nicht um "Ruby vs Python". Die Frage lautete "warum sollte ich Ruby lernen", und meine Meinung ist: Entweder wegen Rails oder gar nicht.
-
Leider habe ich weder Zeit noch Lust, dir Ruby-Nachhilfe zu geben, zumal mir die Erfolgsaussichten auch ziemlich beschränkt zu sein scheinen.
-
die Erfolgsaussichten wären eher schmal, das gebe ich zu. Schließlich hast Du weder meine Frage nach den 7 Ruby-Konstrukten für Closure-Ähnliches noch meine Frage nach den Ruby-eigenen "einfachen Prinzipien" beantworten können.
Ruby ist nämlich alles Andere als einfach. Ruby ist ein syntaktisches Monster, wenn man es mal mit anderen dynamischen Skriptsprachen vergleicht.
-
Syntaktisches Monster? Ich glaube, du hast einfach nicht grade viel Ahnung wovon du redest. Wenn du Ruby die Daseinsberechtigung absprechen willst, dann kannst du das genauso auf Python umwälzen. Über Lesbarkeit kann man sich immer streiten, ich persönlich finde Ruby besser lesbar als Python. Aber wenn sich Ruby nur wegen Rails lohnt, für was lohnt sich denn dann Python? Django?
Wenn Ruby so kompliziert und obsolet ist, warum hat sich dann innerhalb der Java-Plattform eine Sprache wie Groovy entwickelt und etabliert, die Ruby zum Vorbild hat und versucht, ein Brücke von Java zu Ruby zu schlagen?
-
wie heißt es so schön: "Es gibt zwei Sorten Programmiersprachen: die einen werden gelobt, die anderen werden verwendet."
-
user-l schrieb:
wie heißt es so schön: "Es gibt zwei Sorten Programmiersprachen: die einen werden gelobt, die anderen werden verwendet."
Smalltalk fällt dann wohl eher in Kategorie 1. Ruby allerdings definitv in Kategorie 2.