Wenn Ärzte Software debuggen würden ...

... dann ginge das so:


"Na, was hat das Programm denn?"
'Sehen sie, wenn ich hier den Knopf "Abbrechen" drücke - es tut nichts. Man muß es mit den Tasten bedienen, dann gehts.' "Hm, mit den Tasten gehts? Dann ist es wohl nichts Ernstes, aber wenn sie schon mal hier sind...ich verschreibe ihnen eine neue Maus, dann ist wahrscheinlich wieder alles in Ordnung."

(Die Kasse erstattet neue Mäuse.)
Gesagt, getan.
Doch der Knopf "Abbrechen" geht immer noch nicht.

"Sie wieder ... geht nicht, soso. Sind sie sicher? Na, weil ich heute so gefällig bin, machen wir mal eine große Analyse, mit Review. Das sollte man ohnehin alle 2 Jahre machen lassen. Haben sie nicht machen lassen...? Ahaaaa...nun das wird ja höchste Zeit. Also, bringen sie das Programm morgen früh mal vorbei. Ich brauche es ohne Eingabedaten. Eine Woche später haben wir die Ergebnisse."

(Die Kasse erstattet große Codeanalysen, alle 2 Jahre.)

1 Woche später...

"Also, was habe wir denn da...schauen sie mal, ihre For-Schleifen laufen in Schnitt bis 354! Nach dem Stand der Wissenschaft sollte der Wert zwischen 120 und 235 liegen!" (Das ist statistisch die Norm bei gesunden Programmen). "Ihr Programm ist nicht gut gewartet...brechen sie es ab und zu mit dem Taskmanager ab? Aaahaaa...sie sollten es in Zukunft immer regulär beenden. Außerdem müssen wir den Wert ihrer For-Schleifen senken. Keine Sorge, der For-Schleifen-Blocker ist gut verträglich, und kostet sie nur eine kleine Zuzahlung."

(Die Kasse erstattet For-Schleifen-Blocker, mit Zuzahlung.)

eine weitere Woche später...

"Nun, der Herr....? Bei ihnen haben wir doch die For-Schleifen-Senkung gemacht, nicht wahr? Na, wie gehts uns denn ?" 'Also, der Abbrechen-Knopf geht noch nicht.' "Aber ein bißchen besser ist es bestimmt schon geworden? Zumindest ein Stückchen bewegen sollte er sich jetzt schon! Haben sie auch nicht wieder mit dem Taskmanager abgebrochen?" 'Naja...also, vielleicht ist es schon ein bißchen besser. Aber ich bin jetzt wegen eines neuen Problems hier...es stürzt ab und zu ab! Der Abbrechen-Knopf ist mir jetzt gar nicht mehr so wichtig.' "Soso. Ihr Programm kommt halt in die Jahre...gut daß wir den For-Schleifenwert schon mal gesenkt haben! Mir sind auch noch relativ schlechte Case- und If-Werte aufgefallen. Da können wir noch etwas tun."

(Programm wird zum If-Spezialisten überwiesen. Der korrigiert alle If-Anweisungen nach dem neuesten Stand der Wissenschaft, der Case-Spezialist ebenso.)

(If- und Case-Spezialisten bezahlt die Kasse.)

Beim Termin am nächsten Quartalsanfang ...

'Herr Doktor, es wird immer schlechter. Die meisten Teile des Programms sind schon gar nicht mehr einsetzbar. Es erscheinen unsinnige Dinge auf dem Bildschirm.' "Hm, sie sind sich im klaren, wir habe schon ziemlich viel für sie getan. Allerdings sind sie ziemlich spät erst zu mir gekommen ! Ich sehe noch eine Chance ... da gibts eine neue Methode aus den USA, die wirkt manchmal Wunder. Schauen sie, dieses Tool erhöht alle Konstanten im Code um 1 (fragen sie mich nicht, wie es das schafft, aber es ist nachgewiesen daß es funktioniert!) Wir haben schon gute Erfahrungen damit gemacht. Es ist nur nicht ganz billig, und sie müßten es selbst bezahlen."

(Die Kasse erstattet keine Konstantenerhöhungen.)

"Wollen sie es probieren ?"

'Naja, wenn sie sagen es gibt sonst nichts...'

(Schulterzucken)

'...dann probiere ich es halt mal. Es ist meine beste Chance, nicht ?'

"Nun, es ist, wie gesagt, nicht ganz billig. Aber ich mache es mit ihnen wenn sie mir hier unterschreiben. Zusätzlich empfehle ich eine Oberflächenbehandlung, damit die schlimmen Fehlermeldungen verschwinden, von denen sie erzählt haben. Da wird einfach auf ihren Bildschirm so eine Folie geklebt...vom Spezialisten, der macht das genau auf die richtige Stelle. Das ist das Wirksamste was ich kenne. Na, keine Sorge...wir kriegen das schon alles in den Griff, gell?" (Oberflächenkorrekturen bezahlt die Kasse.)

Später, nach der Oberflächenkorrektur und der Konstantenerhöhung...

Auf dem Bildschirm klebt in der Mitte eine weiße Folie. Fehlermeldungen sind nicht mehr zu sehen, leider ist die Paßworteingabe jetzt etwas schwieriger. Das lästige Beep-Geräusch ist häufiger geworden. Fast nichts ist mehr benutzbar. Der Doktor sagt, das beep-Geräusch kann man in den Griff kriegen, an den restlichen Problemen forscht die Wissenschaft noch. Mißtrauen macht sich breit, ob die Konstantenerhöhung vielleicht etwas geschadet hat.

Und ohnmächtige Reue. Denn die Ursache des ganzen Schlamassels ist ganz sicher, daß wir früher das Programm zu oft mit dem Task-Manager beendet haben...

[Dauerhaft unter: http://www.compiled.reifenberg.de/wennaerztedebuggenwuerden.html]

Wo sind Programmierer noch härter als ihre Hardware ? Hier sind die Programmiersprachen, die alles aus dem Codierer herausholen. Zugelassen wurden nur Sprachen, die sich bereits in der Praxis als herausfordernd bewährt haben. Intercal & Co. wurde darum die Teilnahme verwehrt.

Platz 7

PHP
Endlich! Eine Sprache räumt mit dem unseligen Trend auf, Programmlogik von Präsentation zu trennen. Wahre Kleinode sind bereits entstanden, die imperativem Code mit HTML auf engstem Raum untrennbar verschweißen. Firmeninterne Wettbewerbe um das Aufsuchen schließender Tags wurden als einzig objektives Leistungskriterium für Codierer anerkannt. Gedankenlos wurde aber die übersichtliche Syntax von C übernommen, was der Sprache jede vordere Platzierung für immer verwehrt.

Platz 6

RPG
Große Industrieprojekte wurden damit verwirklicht, in völliger Verkennung des Sprachentwurfs, der ausschließlich auf den hier vorliegenden Wettbewerb zielt. Eine dilettantische Weiterentwicklung der ersten, vielversprechenden Versionen nimmt dieser Programmiersprache aber jede Chance auf eine vordere Platzierung. Seit gar Leerzeilen zur Formatierung erlaubt wurden, ist diese Sprache kaum noch schwerer zu beherrschen als ihre Weiterentwickung, der 8086-Assembler.

Platz 5

Java
Typstrenge und vorauseilende Fehlervermeidung zeichnen jede Javasoftware aus, mit wenigen Ausnahmen: Lediglich Programme, die nicht auf eine Bildschirmseite passen, kann niemand ohne Kaskaden von Typecasts am Leben erhalten. Dann verschwindet produktiver Code zwischen den Typecasts wie ein Kulturprogramm zwischen Werbeblöcken im Privatsender. Fragt man Sie, welche VM-Version ihr Programm erfordert, so antworten Sie wenigstens 2 Nummern zu niedrig, da Sie während der Arbeit an den Typecasts die rasante Entwicklung der Versionsnummern aus den Augen verloren haben.

Platz 4

Python
Was quakt wie eine Ente, und watschelt auch so ? Entscheidend für Ihre Software wäre leider gewesen, zwischen zwei bestimmten Entengattungen zu unterscheiden, und das merken Sie erst zur Laufzeit. Bis dahin dauert es lange. Nicht nur weil die CPython-Entwickler noch über den C-Stack und das GIL diskutieren, während das Team von Sun die Java-Version 25 bereits wiederholt handoptimiert hat. Sondern weil Sie einen Großteil ihrer Arbeitszeit davon träumen, tatsächlich einmal Methoden zur Laufzeit einzufügen, aber seit dem Ende des Studiums keinen Anlaß mehr dazu gefunden haben, und weil Sie ständig den stets freien Quellcode anderer freier Programmierer erforschen müssen, der sich selbst die beste, leider aber auch einzig präzise Dokumentation ist.

Platz 3

Ruby
In ihrer Kindheit haben Sie Rubiks Cube ohne Anleitungsbuch in Minutenschnelle zerlegt und durcheinandergebracht. Heute programmieren Sie Ruby. Ihrem Genie kommt der Sprachentwurf entgegen, der den Spracherfinder nur wenig, jeden Reviewer hingegen maximal überrascht. Immer öfter präsentieren Sie routiniert Post-und Präfixnotation gemeinsam in einer Editorzeile. Sie erleben Freude wie seit der Kindheit nicht mehr, wenn eine Ganzzahl dank einer einzigen Zeile Code ohne entschlüsselbares Muster wiederholt in der Liste der Objekte auftaucht und wieder daraus verschwindet. Ihre Seele blüht auf in der Detailtiefe Ihrer Lieblingszeile, und noch vor dem ersten fehlerarmen Lauf Ihrer Software sind Sie zwar entlassen, aber glücklich.

Platz 2

Scheme
Eine wahrhaft edle Programmiersprache braucht keinen Zucker. Wohl aber Klammern. Eine durchschnittliche Bubblesort-Implementierung enthält 284 öffnende und fast genausoviel schließende Klammern. Seit Release 6 ist zudem mehr Individualismus erwünscht, nämlich die kreative, 100% willkürliche Nutzung eckiger Klammern zwischen runden. Spätere Releases werden erzwingen, eine öffnende runde Klammer nur mit einer eckigen oder geschweiften zu schließen. Solch zielgerichtete Fortentwicklung katapultiert diese Sprache schlagartig in den Spitzenbereich.

Platz 1

Perl
Hier kommt das Original. Nachahmer wie Ruby bleiben blass angesicht der einzigen wahren Perle der Selbstverwirklichung. Echte Männer lächeln nachsichtig über assemblerverwöhnte Dünnbrettbohrer, deren Mehrheit mehrmonatiges Debuggen, vielfach eingebogene Wirbelsäulenkrümmungen sowie RSI-Rehabilitations-Marathons niemals kennenlernen wird. Die durchschnittliche Bubblesort-Implementierung existiert hier nicht; Perl-Software verwendet vorrangig den Bogosort-Algorithmus, der auch die Basis des Syntaxparsers bildet. Seit Kugelfisch knapp ist, verwirklichen Gourmets gern Großprojekte wie SVK in dieser Sprache. Unser lokaler Sadomaso-Club bietet Perl-Sitzungen für verbrauchte IT-Projektleiter, die anders nicht mehr erregbar sind. Hunderte geiler Softwareexperten werden dabei erst wieder entfesselt, wenn sie die Funktion eines aus der Praxis entnommenen, in Extremfällen bis zu fünf Zeilen langen Perl-Scriptes erklären konnten.

[Dauerhaft unter: http://www.compiled.reifenberg.de/dieschwierigstenprogrammiersprachen.html]