Natürlich sollten wir uns mehr mit den Prozessen beschäftigen, die Software entstehen lassen, als mit angeblichen Kennziffern zur Beurteilung eines Projektes und abstrakten absoluten Werten, die nicht greifbar sind. Das ist ein generelles Problem mit der Software-Entwicklung, das in den Universitäten der Prozess der Erstellung der Software selber als unwichtig dargestellt wird und nur die Ergebnisse aus Analyse und Design als wichtig betrachtet werden. Als wäre die Analyse oder das Design unabhängig vom Prozess der Implementierung, als wäre dieser direkt von ersteren beiden ableitbar. Teilweise wird die Programmierung selber sogar aus dem normalen Bereich der Softwareentwicklung ausgegliedert und in Kurse gepackt, die als Pflichtscheine gefordert werden - aber in der eigentlichen Lehre wird darauf hingewiesen das ja die Analyse und das Design die Softwarelösung vorgeben, die Programmierung kann man dann ja in jeder Sprache machen. Albern.
Softwareerstellung ist von vielen Komponenten begleitet. Natürlich ist Analyse und Design einer davon - und ein nicht ganz unwichtiger. Vorzugsweise stehen diese beiden Komponenten am Beginn der Entwicklung. Aber begleitend auch wärend der Entwicklung. Aber genauso selbstverständlich ist die eigentliche Implementierung - oft verächtlich als blosses coding dargestellt, also würde man nur eine formale Sprache in eine andere überführen und das irgendwelchen trainierten Affen übergeben können - ein wesentlicher Aspekt, der ganz entscheidend für Erfolg und Misserfolg verantwortlich ist.Auch die Werkzeuge, ganz speziell die Freiheitsgrade die diese bieten, aber auch die Freiheitsgrade, die die Programmierer aktiv nutzen in der Realisierung, sind ein wesentlicher Aspekt. Dabei geht es jetzt nicht um meine Sprache ist besser als deine Sprache - das ist banal und langweilig. Nein, es geht darum, das Sprachen Ausdrucksmittel zur Verfügung stellen, so wie natürliche Sprachen das auch tun. Sprachen bieten Denkmodelle an - mit 40 Wörtern für Schnee und Eis kann man weitaus besser über Schnee und Eis diskutieren, aber in der Wüste geht einem der Gesprächsstoff aus. Genauso ist es in Programmiersprachen - sie bieten Denkmodelle an, die man nutzen kann. Oder man vergewaltigt die Sprache und redet mit 2 Wörtern für Sand über die Bedeutung von Wüste.
Es ist meiner Meinung nach unendlich traurig das gerade in der Bewegung des Software-Engineering und in den modernen Softwareentwicklungsstrategien (ausgenommen vielleicht der XP-Bewegung und der Pragmatic Programmer - aber die sind ja auch oft als Aussenseiter betrachtet) oft die Programmiersprache verächtlich als reines Werkzeug betrachtet wird. Mein Credo: die Programmiersprache ist mehr als ein Werkzeug. Sie ist ein Weg mit der Maschine zu kommunizieren. Und diese Kommunikation ist beileibe nicht spröde oder banal oder primitiv. Sie ist eine intellektuelle Herausforderung, und eine kreative Aktivität. Die Tätigkeit ist nicht kodieren - sie ist kommunizieren . Die verwendete Sprache zeigt den Fokus auf, den eine Gemeinschaft hat - das gilt auch für Programmiersprache. Deren Abstraktionsmechanismen, deren Freiheitsgrade und Ausdrucksvielfalt zeigt auf, welche Richtungen angedacht waren, wie die Entwickler, die diese Sprache entworfen haben, die Software-Welt sehen. Diese Richtungen und Ideenräume in denen sich eine Sprache bewegt sind wichtig - gehe ich in der Kommunikation dagegen an, fehlen mir die Wörter. Ich muss zu Umschreibungen greifen - hässlicher, unästhetischer Code ist oft die Folge.
Ich habe in meinen mitlerweile fast 20 Jahren Programmierung, davon 16 Jahre professionell, eine ganze Menge alten Code gelesen. Das ist unabdingbar wenn man 10 Jahre seiner Arbeitszeit damit verbringt an einem alten Warenwirtschaftssystem zu arbeiten. Und was mir immer wieder aufgefallen ist, ist das unästhetischer Code - im oben genannten Sinne, aber auch in seiner ganz profansten Form als falsch strukturierter und formatierter Code - fast immer auch der Code mit den meisten Bugs war.
Es ist oft ein ganz eindeutiges Kennzeichen das das Nichtverstehen der Kultur einer Programmiersprache und ihrer Kultur sich in der Programmierung dann durch ein Nichtverstehen der komplexen Abläufe widerspiegelt - und das führt zu Bugs.
Hässliche Sprachdesigns tragen dann das ihre dazu bei, das Programme eigentlich eher an Beschimpfungen der Maschine erinnern als daran, was sie sein sollten (und meiner Meinung nach sind): Programme sind Gedichte für den Computer!
Viele Programme erinnern in dem Kontext aber eher an verunglückte Limericks mit falschem Versmaß und nicht reimenden Zeilen, zu denen der Dichter 5 Seiten Erläuterungen geschrieben hat, wie der geneigte Leser bitteschön das Gedicht zu interpretieren hat ...
Bei PragDave gibts den Originalartikel.
Hah! Hätte ich das eher gehabt, hätte ich zusammen mit dem portable allegro store und vielleicht einer Portierung von Woods den ganzen Python Desktop Server in Common Lisp schreiben können
Bei CLiki Recent Changes fand ich den den Originalartikel.
