Neben den ständigen Tiefschlägen das Ruby ja ach so langsam sei, hören wir (zu recht!) die Hilferufe, dass die Dokumentation von Ruby nicht mal annähernd vollständig sei. Auf die Frage wie sich unser Liebling in speziellen Fällen verhält, mache ich bis heute doch noch hin und wieder meinen Editor auf und schaue mir eval.c und Gefolgschaft an. Um diesem Zustand ein baldiges Ende zu setzen, wurde vor ein paar Tagen ein Wiki aufgesetzt welches `irgendwann` einmal eine tragbare Spezifikation von Ruby bereitstellen soll. Im Moment muss ich gestehen, dass die Informationen bisher mehr als dürftig sind oder besser gesagt es ist fasst nix vorhanden. Aber der längste Weg beginnt mit dem ersten Schritt und dieser Weg könnte sehr lang werden.
Kommentar schreiben
Kommentare
Uff - da steht aber noch viel Arbeit bevor. Mal sehen ob ich irgendwann Zeit finde ein paar zusammenfassende Syntaxteile zu Regulären Ausdrücken dazu zu packen. Ansonsten hängt aber die Meckerei über Rubys sog. Langsamkeit auch mit der fehlenden Doku zusammen. Wenn man manchmal nicht ewig suchen müsste, könnte man sein Programm so schnell schreiben, dass die Ausführungsgeschwindigkeit irrelevant wird.
moin (auch, wenn's schon spät ist)! Was fehlt denn auf den Seiten www.ruby-doc.org und www.rubygarden.org? Da gibt's doch reichlich Doku.
Es fehlt eigentlich so etwas wie eine erweiterte (*) und jeweils auf dem aktuellen Stand gehaltene Hypertextversion der zweiten PickAxe, die auch herunterladbar und lokal installierbar ist. (*) Mehr Beispiele und Reference und Einführung strikter gestrennt, so dass eher Sachen doppelt vorkommen, als dass man zwischen diesen Teilen laufen hin und her schalten muss (wie aktuell in der PickAxe nötig).
Es fehlt insbesondere die Implementierungsspezifikation. Ruby-Doc und Rubygarden sind eher Anwendungsorientiert zu sehen. Wenn man jedoch Rubysinterna benötigt so gibt es schlichtweg keine vollständige englische Dokumentation (es gibt eine japanische die jedoch nur sehr träge übersetzt wird). Die Dokumentation für die Standardbibliothek ist zwar noch durchaus ausbaufähig jedoch sehe ich die wirklichen Löchen eher bei der Spezifikation der Sprache selber.
Auch die Anwenderdokumentation ist weit entfernt von einem Stand wie bei Perl oder Python. Das verhindert die Verbreitung bei Leuten, die schon länger in allem möglichen Sprachen programmieren und, wenn sie die Auswahl haben, dann (beispielsweise) Python vorziehen, weil sie bei Ruby einfach viel Zeit investieren müssen um sich eine komplette Anwenderdokumentation zusammenzustellen (sofern überhaupt möglich). Das Problem hätte ich auch, wäre ich nicht lange krank gewesen. Kein Arbeit-/Auftraggeber hätte eingesehen, dass ich Tage-/Wochenlang Dokumentation zusammenstelle, wenn ich sie bei Python komplett mit installiert bekomme (Windows). In Ruby gäbe es das Problem nur weit schwächer, wenn die PickAxe 2 in elektronischer Form frei verfügbar wäre - und nicht die alte Version. Wie schon gesagt, eine Dokumentation dieser Art gehört bei Python frei dazu. Das ist ein starker Wettbewerbsvorteil für diese Sprache, denn bei Scriptsprachen kommen die meisten Leute doch nicht über ein richtiges Projekt zu der Sprache, sondern, sofern überhaupt kommerziell, über selbstgeschriebene ad hoc Tools. Es wird also nebenbei in der Sprache gearbeitet. Dadurch ist man aber auf gute, vollständige und griffbereite Dokumentation angewiesen, weil man sie nicht andauernd benutzt.
Klar ist es am bequemsten, das Pickaxe2 frei zugänglich für alle anzubieten. Aber das steckt einfach viel Arbeit drin. Und die will verständlicherweise bezahlt werden. Wo ist denn das Problem, das Buch zu kaufen? Sind wir alle so arm, das 40 EUR für die Doku unserer Lieblingssprache zu viel sind? Sind die Entwicklungsleiter zu geitzig? Oder sind wir selbst zu geitzig? Ich konnte meinen Ex-Chef davon überzeugen und jetzt gehört es mir. Mal ehrlich: Gute Arbeit sollte auch gut bezahlt werden, oder? Ich habe jedenfalls kein Problem damit, der Klofrau 50 Cent zu geben, wenn's da sauber ist.
Also ich kann Ralf nur zu stimmen. Das Problem ist jedoch das die große masse kostenlose Doku zum Einstieg haben will. So wird es ja auch bei jeder anderen Sprache gemacht. Und wenn man sich zurück erinnert war der große Durchbruch von Ruby ja durch freie englische Doku begründet.
Das Problem sind die vorhandenen Dokumentationen, die bei Perl und Python mit ausgeliefert werden. Bei Ruby ist nichts in dieser Qualität dabei - das mit der E-PickAxe wäre auch nur eine Notlösung. Platz für Bücher gibt es allemal immer noch, wie sich bei Perl und Python deutlich zeigt. Wenn man jemandem, der Python oder auch Perl schon längere Zeit benutzt, auf Ruby aufmerksam machen will, gibt die fehlende Basis-Dokumentation in ähnlicher Qualität wie bei den beiden Sprachen ein Problem.