Contents

Erste (und zweite) Eindrücke von Python, Squeak, Ruby und D

Links

Dieses Mal habe ich mich entschieden, die erste Runde des 23. Bundeswettbewerb Informatik dazu zu nutzen, mir einige Sprachen näher anzusehen, mit denen ich mich schon länger mal auseinandersetzen wollte. Hier die Eindrücke, die diese Sprachen hinterlassen haben, nachdem ich jeweils eine Aufgabe damit gelöst habe:

Aufgabe 1 (Charminator) - Python

In Python hatte ich vorher schon ein paar kleine Skripte geschrieben, also war ich in der Sprache nicht völlig unerfahren. Am Anfang hat mich an Python die Idee begeistert, eine klar lesbare und sorgfältig designte Sprache zu haben. Allerdings musste ich beim Coden feststellen, dass mich die etwas starre Syntax teilweise ein wenig eingeschränkt hat. Das ist mehr eine Gefühlssache gewesen, aber das Coden in Python hat sich manchmal nicht wirklich gut angefühlt.

Insgesamt muss ich sagen, dass Python gegenüber C++ ("meiner" bisherigen Programmiersprache) eine Umstellung darstellt; nicht unbedingt von den Programmierpraktiken her, aber vom Sprachgefühl. Objektorientierte Programmierung ist in Python zum Beispiel auf eine Weise umgesetzt, die ich am Anfang sehr gewöhnungsbedürftig fand. (Als ein Beispiel möchte ich anführen, dass private Variablen nicht etwa durch ein Keyword "private", sondern durch einen führenden Unterstrich gekennzeichnet werden.)

Auch die Standardfunktionen verhalten sich manchmal etwas anders als erwartet. Warum gibt z. B. die print-Funktion zwischen jedem ihrer Argumente ein zusätzliches Leerzeichen aus? Das hat mich gleich zu Beginn etwas aus dem Tritt gebracht.

Wie vielleicht zu erkennen war, haben diese Sachen viel mit persönlichem Geschmack und dem Hintergrund, den man programmiermäßig hat, zu tun. Ich denke, um das Programmieren zu lernen, ist Python eine exzellente Sprache, und auch zum Skripten nicht zu verachten. Ich werde vorerst trotzdem bei Ruby bleiben, weil es mich doch etwas mehr begeistert hat.

Aufgabe 3 (Käsewürfel) - Squeak

Seitdem ich in der c't mal von Smalltalk gelesen habe, wollte ich schon immer mal mit dieser Sprache anfangen, da ich seit C++ begeisterter OOPler bin und mal wissen wollte, wie "echtes" OOP denn aussieht. Als ich Squeak aber vor ungefähr einem Jahr das erste Mal installierte, wurde ich von dem Programm regelrecht erschlagen - "wo bitte gebe ich denn hier meinen Code ein?" Tapfer probierte ich einige Tutorials, habe aber nie so wirklich Feuer gefangen.

Nachdem ich dann zwischenzeitlich ein bisschen mit dem für einen Coder wesentlich klarer aufgebauten Cincom Smalltalk gespielt hatte, fühlte ich mich zum BWInf bereit, es wieder einmal mit Squeak zu probieren. Dies ist das erste Mal, dass ich eine größere Menge an Code in Smalltalk geschrieben habe. Die Erkenntnis, die ich dabei langsam, aber sicher erreichte ist, dass die Syntax, die erst so klar und einfach aussieht, an einigen Stellen schlicht unpraktisch ist: Wenn man zum Beispiel an ein Objekt, das von einer Methode eines anderen Objektes geantwortet wird, eine Nachricht senden will, muss man Klammern benutzen (oder man führt eine neue Temp-Variable ein), und das ist umständlich und sieht hinterher komplizierter aus, als es ist.

Dann musste für die graphische Ausgabe natürlich Morphic her, das GUI-System von Squeak (genau genommen eins von drei verschiedenen). Und sich da einzufuchsen, war schon manchmal eine harte Nuss. Richtig fingen die Probleme aber erst an, als ich einen Button mit der Aufschrift "Neue Simulation erstellen" schön im Workspace platzieren wollte, denn dafür holte ich mir den Button ganz einfach aus der Toolbar. Aber wie sollte ich ihn dann vom Quellcode aus ansprechen? Bei einem Button habe ich es letztendlich hingekriegt, aber als dann noch ein Zweiter hinzukommen sollte, habe ich mit Hinblick auf den knapp werdenden Zeitplan auf diese Buttons verzichtet und stattdessen einen Hinweis in die Doku geschrieben, dass zum Starten von Simulationen ein Workspace zu benutzen ist. Komplizierter als Kommandozeilenoptionen einzugeben ist das auch nicht ;)

Übrigens wurde ich noch mal richtig geschockt, als ich die erste Simulation mit 100 Testwürfeln ausführte. Die braucht nämlich auf meinem Athlon XP Mobile 2500+ ungefähr 15 Sekunden. Man kann sich vorstellen, wie lange wirklich *genaue* Simulationen brauchen...

Fazit: Komische Syntax, langsam, komplizierte Umgebung. Sicher, Squeak ist auch jetzt schon eine Umgebung, die Spaß macht, aber um produktiv zu sein, reicht es mir noch nicht ganz.

Aufgabe 4 (Bücher) - Ruby

Von Ruby hatte ich vor einigen Jahren zum ersten Mal gelesen, es damals aber nicht ausprobiert. Ein Fehler!

Das Objektmodell - das was mir in Smalltalk sehr gut gefallen hat - ist in Ruby quasi genauso enthalten. Dafür benutzt Ruby eine meiner Meinung nach lesbarere Syntax und ein konventionelleres Sourcecode-Format - nämlich Textdateien. Ruby wurde nach dem "Principle of Least Surprise" (Prinzip der geringsten Überraschung) designt, was meiner Meinung nach ein sehr mächtiges Prinzip ist. Man merkt das auch, denn die meisten Sachen funktionieren auf Anhieb so, wie man es von ihnen erwarten würde. Der Rest an Fragen ließ sich durch die gute Dokumentation - vor allem das "Programming in Ruby"-Buch, das auf der Website verfügbar ist - klären. Alles in allem gab es in Ruby kaum Punkte, wo ich die Art, wie etwas funktionierte, unlogisch oder unverständlich fand.

Darüber hinaus hat Ruby einige kleine Extras, die offensichtlich aus der praktischen Programmiererfahrung heraus entstanden sind. Zum Beispiel wird sich mit den Features attr_reader und attr_writer (automatisches Erzeugen von get/set-Methoden) jeder anfreunden können, der schon einmal stundenlang Zugriffsmethoden geschrieben hat. Auch die Tatsache, dass sich Methoden in Ruby wie eine Zuweisung aufrufen lassen, finde ich sehr natürlich und habe sie schon oft in anderen Sprachen vermisst.

Ich denke, mit Ruby werde ich mich in der Zukunft noch öfter beschäftigen.

Aufgabe 5 (Rechtecke) - D

Die D-Programmiersprache war ursprünglich als "Nachfolger" zu Sprachen wie C++, Java usw. gedacht und sollte einige Sachen ausräumen, die bei diesen etablierten Sprachen einfach falsch gelaufen waren. In diesem Punkt hat D in meinen Augen schon jetzt gewonnen - bis auf die mangelnde Verfügbarkeit von Libraries und noch keine vollständige Container-Library finde ich D schon jetzt eigentlich in allen Punkten besser als C++. Besonders beeindruckend sind die Kompilierzeiten, die ja gerade bei C++ ins Unermessliche wuchsen.

D ermutigt aber dadurch, dass Variablen standardmäßig Referenzsemantik haben, und durch den eingebauten Garbage Collector, auch zu einem anderen Programmierstil als zum Beispiel C++. In C++ musste man bei Polymorphismus immer Pointer benutzen und höllisch genau darauf achten, wer ein Objekt nun besitzt und es zerstören darf. Bei D sind diese Probleme passé.

Ein weiteres Feature, dass eine häufige Fehlerquelle aus C++ ausräumt, ist die Tatsache, dass Arrays ihre Länge kennen.

Diese Features hören sich geradezu höllisch nach "Skriptsprache" an, und auch ich war, als ich zum ersten Mal davon gehört habe, über die Geschwindigkeit besorgt. Zu bemerken ist allerdings, dass D-Programme im Allgemeinen nicht wesentlich langsamer laufen als C++-Programme, und dass D in manchen Benchmarks sogar die Nase vorn hat.

Ich finde, die Verbesserungen sind diesen Performanceunterschied allemal wert, genauso wie es der Umstieg von C auf C++ wert war.