Auf mich hört ja keiner ...

[Alexander (HH)]

Moin Moin!

Du erzählst gerade meine Geschichte, nur durfte ich den Code selbst neu schreiben :).
Wobei man bei "gutem" Code natürlich streiten kann.

Natürlich. Man kann sich ja schon bei "Hello World" wunderbar über Code-Style und fehlende Fehlerprüfungen streiten. (Ja, puts() / printf() / write() KANN fehlschlagen, und ein typisches helloworld.c ignoriert das in aller Regel.)

Ich denke jedes System hat seinen Pferdefuss.

Richtig. Mal mehr, mal weniger, aber ganz ohne Macken ist ein System größer als "Hello World" eigentlich nie.

Wenn der Code aber aus mehreren 100.000 Zeilen verteilt über hunderte bis tausende Dateien und einige Pseudo-Datenbanken besteht, keinerlei Dokumentation vorhanden ist, und jedes einzelne Stück Code nur aus Pferdefüssen besteht, dann kann man dem System nur noch den Gnadenschuß geben oder eben mit sehr viel Geduld und Aufwand intensives Refactoring betreiben und so den kaputten Code nach und nach austreiben.

Angesichts diverser "Besonderheiten" der Laufzeitumgebung war mein Favorit ganz klar die zweite Variante; die hätte nämlich den Charme gehabt, dass man sich nicht mehr mit der Laufzeitumgebung herumärgern müßte.

Ein paar meiner persönlichen Highlights:

* Datei öffnen kann fehlschlagen. Man erfährt daber nur, dass das Öffnen nicht funktioniert hat, nicht aber, warum. Ob Platte voll, falscher Name, oder zu wenig Rechte, alles was das System meldet ist "funzt nicht™". Analoges gilt für sehr, sehr viele andere Funktionen. Man stelle sich C ohne errno vor.

* Editor, Compiler und Dokumentation sind sich nicht darüber einig, wo Kommentare anfangen und wo sie aufhören. Nur weil der Editor ein Stückchen Code als auskommentiert ansieht, muß der Compiler den augenscheinlich auskommentierten Code noch lange nicht ignorieren.

* Der SQL-(Pre-)Parser, der SQL-Statements für die Datenbank aufbereiten (vor allem Parameter / Variablen identifizieren) soll, paßt weder zur Datenbank noch zur Dokumentation und sorgt regelmäßig für völlig wirre Fehlermeldungen und Abstürze.

* Das DB-Interface ignoriert unter bestimmten Umständen SQL-Kommandos komplett, ohne Fehlermeldung, ohne Warnung. Das SQL-Kommando scheint für das Programm erfolgreich ausgeführt worden zu sein.

* Mindestens zwei inkompatible Typensysteme: Eines für Variablen, eines für Funktionsparameter. Und nein, das denke ich mir NICHT aus.

* Scripting mit "zu einfachem" C. Strings auf einen C-artigen Interpreter aufzusetzen ist eine gute Idee, dann aber fast alles andere wegzustreichen, was C kann (Funktionen als Funktionsparameter, beliebig dimensionierte Arrays, Funktionen mit einer variablen Anzahl Parameter, ...), ist extrem behindernd.

* Die Fehler dann mit Tonnen von halb fertig gedachten Runtime-Library-Funktionen ausbügeln zu wollen bringt's auch nicht.

* In einer Umgebung, in der fast alles als Objekt zu sehen ist, keinerlei OOP im Scripting vorzusehen, ist auch alles andere als genial.

* Im Datenbank-Umfeld keine assoziativen Arrays im Scripting zu haben macht auch keinen Spaß. Man schreibt alles in Arrays und rennt ständig mit for-Schleifen über die Arrays, um Werte nach Namen zu finden. Performance ist dann natürlich gruselig. Und um Hashes selbst zu programmieren, ist das C zu abgemagert.

Insgesamt erinnert die Laufzeitumgebung sehr an die wunderschöne Toolbox-Analogie aus PHP: a fractal of bad design:

Imagine you have a toolbox. A set of tools. Looks okay, standard stuff in there.

You pull out a screwdriver, and you see it’s one of those weird tri-headed things. Okay, well, that’s not very useful to you, but you guess it comes in handy sometimes.

You pull out the hammer, but to your dismay, it has the claw part on both sides. Still serviceable though, I mean, you can hit nails with the middle of the head holding it sideways.

You pull out the pliers, but they don’t have those serrated surfaces; it’s flat and smooth. That’s less useful, but it still turns bolts well enough, so whatever.

And on you go. Everything in the box is kind of weird and quirky, but maybe not enough to make it completely worthless. And there’s no clear problem with the set as a whole; it still has all the tools.

Now imagine you meet millions of carpenters using this toolbox who tell you “well hey what’s the problem with these tools? They’re all I’ve ever used and they work fine!” And the carpenters show you the houses they’ve built, where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards and they all yell at you for breaking their door.

Ich vergaß zu erwähnen, dass $VORGÄNGER vorher für den Hersteller der Laufzeitumgebung arbeitete. Nicht unbedingt als Core-Programmierer, aber als "Verkäufer", der die Laufzeitungebung, eines der verschiedenen Grundsysteme und kundenspezifische Anpassungen verkaufte und letztere auch "programmierte".

Ich hab bei einer günstigen Gelegenheit einen kleinen Einblick in die interne Arbeitsweise beim Hersteller der Laufzeitumgebung bekommen. Man werkelt mit hunderten verschiedener ZIPs auf diversen Rechnern, CVS ist ein Write-Only-Memory, dass nur ein einziger im Haus benutzen darf, und auch nur schreibend, nicht lesend. Man schult neue Mitarbeiter und Kunden (für viel Geld) hauptsächlich darin, Workarounds für die Macken der Laufzeitumgebung zu kennen bzw. zu erfinden.

Alexander