lunar hat geschrieben:@pillmuncher: Bei formaler Logik als Waffe gegen die Ausbeitung der Arbeiterklasse durch das Kapitel?! [...] Auch wenn ich die politischen Ansichten, die durch Deine Beiträge schimmern, einigermaßen teile, so ist das erstens vollkommen themenfremd und zweitens übertrieben, polemisch und ziemlich einseitig.
Immerhin bin ich da derselben Ansicht wie
Otto Neurath. Und im Politischen darf man, finde ich, durchaus polemisch übertreiben, und man muss auch einseitig sein. Die Gegenseite ist es ja auch. Aber das ist tatsächlich OT, also lassen wir das Thema lieber.
lunar hat geschrieben:Auch wenn Dein Beispiel als Argument nicht taugt, weil es einfach nur einen schlechten Programmierer offenbart, nicht aber allgemeine Schwächen einer bestimmten Entwurfstechnik offenbart, so muss man natürlich zugestehen, dass Programmierer es oft genug an Abstraktion mangeln lassen.
Ich habe den Eindruck gewonnen, dass viele, die sich vom Top-Down-Entwurf angezogen fühlen, sich so verhalten, wie ich es beschrieben habe. Ich habe natürlich keine Studie parat, mit der ich das belegen könnte, aber ich hatte ähnliche Erlebnisse oft genug, um ein Muster zu erkennen. Genauso wie du ein Muster bei den LISPern erkennst:
lunar hat geschrieben:LISP (oder beispielsweise auch funktionale Sprachen wie Haskell) ist allerdings nicht die Lösung, sondern meist nur das andere extrem: Vom Problem wird so lange abstrahiert, bis das zu lösenden Problem und mithin auch die Lösung unter all den Abstraktionen nicht mehr zu erkennen ist.
Wie ich schon schrieb, LISPer neigen womöglich dazu, mathematische Eleganz über Lesbarkeit und Praktikabilität zu stellen. Jeder hat so seine Lieblings-Ideen, die er irrational verteidigt und durchzieht, ich möglicherweise ebenso, aber ich bemühe mich, meine immer wieder einer strengen Prüfung zu unterziehen.
Eine dieser Ideen ist, dass Bottom-Up-Entwicklung besser ist. Top-Down-Entwicklung führt IMO immer wieder dazu, dass Lösungen für inexistente Probleme entworfen werden, oder dass die Implementierung entlang der Planungen gar nicht möglich ist, weil manches gar nicht umsetzbar ist. Ein Bekannter von mir sollte mal ein Netzwerk programmieren, bei dem jederzeit neue Knoten dazukommen konnten, die dann ihren nächsten Nachbarn ihre Anwesenheit kundtun sollten, worauf diese die Nachricht weiter zu leiten hatten, bis alle Knoten Bescheid wussten. Das aber, laut Entwurf,
in konstanter Zeit. Dazu das von mir genannte Problem mit der Flachheit der Implementation. Mir gefällt das alles nicht.
Auf StackOverflow hat mich mal jemand auf
Abschlussdokumente der NATO Software Engineereing Conferences von 1968 und 1969 hingewiesen. Im ersten Jahr kann man mit etwas gutem Willen eine teilweise Favorisierung von proto-agilen Methoden und Bottom-Up-Entwicklung finden, zB. in diesem Beitrag von Kinslow:
The design process is an iterative one. [...] In my terms design consists of:
1. Flowchart until you think you understand the problem.
2. Write code until you realize that you don’t.
3. Go back and re-do the flowchart.
4. Write some more code and iterate to what you feel is the correct solution.
und in diesem von Ross:
The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from. The projects that are called successful, have met their specifications. But those specifications were based upon the designers’ ignorance before they started the job.
Im nächsten Jahr waren diese Stimmen mehr oder weniger verschwunden und Big Design Upfront mittels Top-Down-Entwurf wurde propagiert.
Zum Trost noch ein Beitrag von 1968, von Naur:
…software designers are in a similar position to architects and civil engineers, particularly those concerned with the design of large heterogeneous constructions, such as towns and industrial plants. It therefore seems natural that we should turn to these subjects for ideas about how to attack the design problem. As one single example of such a source of ideas I would like to mention: Christopher Alexander: Notes on the Synthesis of Form.
Die Geschichte der Programmierung ist interessanter als man denkt. Und wie
Buffy The Vampire Slayer einst sagte:
Those who fail history are doomed to repeat it in summer school.
Zurück nochmal zu meiner Ausgangsthese, dass der Kern der Programmierung nicht das Technische, sondern das Analytische ist. Da sind LISPer oft näher dran, als die Benutzer von nicht-funktionalen Sprachen. Und natürlich ist:
lunar hat geschrieben:Die Qualität von Programmen ist keine inhärente Eigenschaft einer Sprache, und folgt auch nur sehr bedingt aus der Sprache.
aber jede Sprache zieht gewisse Typen von Programmierern an, die etwas an ihrem Abstraktionsgrad, ihren Konstrukten und ihrem idiomatischen Code finden, was ihnen gefällt und mit dem sie gerne arbeiten. LISP zieht Leute an, die gerne abstrakt über Probleme nachdenken und die Generalisierungen mögen, aus denen sie dann ein Programm als Spezialfall allgemeinerer Konzepte entwickeln. Mir gefällt das. Aber ich sehe selbstverständlich auch, wie das in Übertreibungen enden kann. Die Kunst liegt darin, das richtige Maß zu finden.
Gruß,
Mick.
In specifications, Murphy's Law supersedes Ohm's.
