The Pragmatic Programmer (Ruby Teil 2)

Ich habe mir jetzt das erste Kapitel einer online Version des Pragmatic Programmers angetan. Dieses Buch scheint die Bibel der Ruby Programmierer zu sein.

Von den Grundlagen gefallen mir die vereinfachten Initialisierungen von Arrays und Maps (Hash) sehr gut. Damit kann man sich viel Mühe und stupide Arbeit sparen.

Beispiele:

[3.1415, "Pi", 2008] erzeugt einen Array

{ 'a' => 'Einleitung', 'b' => 'Grundlagen', 'c' => 'Objekte' } erzeugt eine Map

Vielversprechend sind auch die ominösen Closures, bei denen junge Programmierer, die gerade von Schweinecode-Skriptsprachen umsteigen, feucht werden.

Und die direkte Einbindung von regulären Ausdrücken (mittels =~ und // ) ist auch eine feine Sache.

Aber es ist mir unerträglich mit welcher Selbstverständlichkeit Fakten zurechtgebogen werden, um Ruby im Gegensatz zu anderen Programmiersprachen gut aussehen zu lassen. Da werden die blödesten Rückfälle in alte Zeiten garniert mit den Prädikaten "einfacher", "besser" und ganz wichtig "eleganter". Damit will man doch nur unerfahrene Leser über den Leisten ziehen.

Eine Freude war mir, wie die Möglichkeit Klammern in allen Varianten wegzulassen erst als Feature verkauft wird - und dann im Nachsatz darauf hingewiesen wird, dass man sie lieber setzen sollte, weil man sonst durcheinander kommt.

Der Compiler, den ich verwende, warnt generell davor Klammern bei Methodenaufrufen wegzulassen, um "mit zukünftigen Versionen kompatibel zu sein".

Und wer denkt sich heute noch eine Sprache aus bei der das Ende der Zeile das Ende des Befehls darstellt? Will man damit erreichen, dass man alle Aktionen freiwillig so klein und überschaubar hält, dass das nicht stört?

Aber das stimmt nicht so ganz, denn man kann nach bestimmten Zeichen ( . , ) anscheinend in die nächste Zeile umbrechen.

geht:

[1,

2]

geht nicht:

[1

, 2]

Zitat aus dem Pragmatic Programmer:

Allerdings gab es bis Ruby eine Unterstützung für reguläre Ausdrücke nur in den sogenannten Script-Sprachen wie Perl, Python und awk.

... und Ruby ist keine Skriptsprache? Und Ruby hat nicht seine ganze RegExp Syntax bei Perl abgekupfert? Und andere objektorientierte Sprachen haben keine RegExp Bibliotheken?

Eine "nicht-Skriptsprache" würde wohl kaum einen Unterschied machen, ob der Aufruf oder die Deklaration einer Methode zuerst in einer Datei steht.

Kleinste gemeinsame Obermengen

Heute hatte ich bei der Arbeit ein interessantes Problem.
Es fing ganz harmlos mit "Business Logik" an und reduzierte sich je mehr ich darüber nachdachte auf schlichte Mengenlehre.

Das Kernproblem ist folgendes und sei dem geneigten Leser zur Implementierung überlassen:

Man hat eine Gesamtmenge A von Mengen B.
Diese Mengen B enthalten eventuell gleiche Elemente.
Aufgabe ist es nun "kleinste gemeinsame Obermengen" zu finden. D.h. wenn zwei Mengen gleiche Elemente enthalten, müssen sie vereinigt werden.

Beispiel:
a: [1]
b: [2, 3]
c: [4, 5, 6]
d: [7, 8]
e: [9]
f: [1, 3, 4, 5]

=>
[1, 2, 3, 4, 5, 6], [7, 8], [9]
d.h. a, b, c und f werden vereint. d und e bleiben separat.

Ich habe das ganze mit Maps, Sets und einer Rekursion gelöst. Und irgendwie habe ich das Gefühl, dass es eine einfachere Lösung geben muss.
Vor allem ist mir auf dem Nachhauseweg aufgefallen, dass ich die ganze Aktion vermutlich auch noch für eine andere Gruppierungsebene machen muss...

Ruby

Ich habe jetzt angefangen mir die Programmiersprache Ruby anzusehen.
Koryphäen wie Martin Fowler schwärmen davon. Und das will etwas heißen, denn er hat ein paar wunderbare Bücher über Programmierung geschrieben. Vor allem den Klassiker "Refactoring: Improving the Design of Existing Code".
Außerdem ist es die Modesprache des Tages.

Und mein erster Eindruck ist: furchtbare Hackersprache. Javascript reloaded.

* Man kann abkürzen wo man will. D.h. Methodenaufrufe brauchen nicht einmal die sonst üblichen Klammern, wenn man keine Parameter hat.
* Membervariabelen werden nicht zwingend deklariert. Sie entstehen quasi bei Benutzung.
* Methodendeklarationen sind arschhäßlich und erinnern mich an 70er Jahre Sprachen. Anstelle von Klammern wird mit "end" gearbeitet. *schauder*
* Überhaupt scheinen die Entwickler eine Allergie gegen Klammern gehabt zu haben, was bei if und ähnlichen Kontrollstrukturen eher zur Verwirrung beiträgt.

Viele Blogs, in denen Ruby gelobt wird, pochen darauf, dass andere Sprachen viel zu unflexibel seien, zu viel Tipparbeit erfordern und den Blick auf das Wesentliche durch zu viel Ballast ("boiler plate code") verschleiern.

Man kann den Code in Ruby zwar durch diverse Umdefinitionen klein halten, aber m.E. leidet die Lesbarkeit sehr darunter. Vermutlich soll der Name von einer gewissen Verwandtschaft mit Perl zeugen. Sozusagen Perl x C++ mit syntaktischen Anlehnungen an Pascal.
Und ich kann mir wirklich nicht vorstellen, wie man da bei einem größeren Projekt noch durchblicken soll. Sobald die ersten Umstrukturierungen kommen, verliert man den Durchblick.

Ich finde Ruby noch unleserlich und verwirrend, aber so ging es mir mit Java 1.1 anfangs auch.
Mal sehen ob sich der Eindruck ändert, wenn ich erst mal etwas damit gemacht habe.

Wenn die Hütte brennt erstmal die Taschen füllen

Die Bankangestellten wollen mehr Geld haben.
Vorgestern hieß es noch, die Banken bieten 0,5% und die Gewerkschaft fordert 8%. Heute höre, ich die Angestellten fordern 8% und die Banken bieten 6% an.

Das sind schon spaßige Gesellen diese Bänker. Nahezu alle Banken müssen Abschreibungen in Millionen-, wenn nicht sogar in Millardenhöhe oder gleich den ganzen Laden zu machen - und sie wollen überdurchschnittliche Gehaltssteigerungen. Das erinnert mich irgendwie an Managerboni.

Ich hätte auch gerne 6% mehr Geld. Dann wären meine Anlagen wenigstens im Plus. Aber abgesehen davon, dass die Fondmanager aus schwankenden Märkten nicht das geringste erwirtschaften, kassieren sie ihre Prozente vom angelegten Geld und nähren sich von meinem erarbeiteten Besitz...

Ich werde mein Geld demnächst nur noch fest verzinst anlegen, dann können die machen, was sie wollen.