Evolutionäre Programmierung - programmiert auch Ihr evolutionär?

[Delphi-Laie]

Hallo Delphifreunde!

Das Konzept der evolutionären Programmierung ist sicher etlichen von Euch geläufig.

Seit längerem implementiere ich Sortieralgorithmen für ein Animationsprogramm, das ihren Verlauf darstellen soll. Ich habe für die meisten der Algorithmen nicht die „intellektuelle Energie“ und die Ausdauer, mich in deren Funktionsweise hineinzudenken (oft fehlen mir auch Grundlagen dazu). Mithin bin ich auf schon vorhandene Quelltexte angwiesen: Pascal (sehr selten), (Visual-)Basic (selten, aber erträglich) oder allermeistens alle möglichen C-Derivate (ein elende Übersetzung). Oft genug funktionieren die Quellcodes auch nicht zur Zufriedenheit.

Also bin ich „Dünnbrettbohrer“ und „schraube“ an allem möglichen Parametern und Variablen umher (veränderte Startwerte, veränderte Typen, Laufbereiche bei Schleifen usw. usf.), bis der Algorithmus anscheinend / offensichtlich fehlerfrei funktioniert. Das dauert i.d.R. nur Stunden, und bis auf eine Ausnahme gelang es mir bisher auch immer. Jedem Informatikprofessor sträuben sich dabei natürlich die Haare, denn Professoren sind penibel und wünschen sichere Fehlerfreiheit, und die natürlich mit Beweis, denn ohne ist nichts sicher. Doch in der Programmierung bin ich Praktiker, und die Ersparnis an Zeit und Denkaufwand schätze ich als immens ein.

Nun meine Fragen: Geht Ihr auch gelegentlich oder sogar häufig so vor? Wie schätzt Ihr das Restrisiko ein, daß man doch Fehler dabei einbaut bzw. übersieht? Ist das in Euren Augen eine praktikable, akzeptable Programmiermethodik?

Ich wünsche schon mal einen schönen Jahreswechsel!

Gruß

Delphi-Laie

[Coffeecoder]

Hi,

Zitat von Delphi-Laie:

Nun meine Fragen: Geht Ihr auch gelegentlich oder sogar häufig so vor? Wie schätzt Ihr das Restrisiko ein, daß man doch Fehler dabei einbaut bzw. übersieht? Ist das in Euren Augen eine praktikable, akzeptable Programmiermethodik?

Ich muss zugeben, dass ich ähnlich vorgehe bei der Programmierung. Allerdings erstelle ich Pläne (Algorithmen, Struktogrammen, etc) zu meinen Ideen. Wenn ich doch mal hänge, dann schraube ich auch rum bis es passt. Natürlich ist der Restrisiko ziemlich hoch, das musste ich bei einem meiner Projekte einsehen. Dabei habe ich eine Überprüfung vergessen, die aber den normalen Verlauf nicht stört. Erst nach langer Zeit ohne neue Daten einzulesen, ist dieses Problem aufgetreten.

Sicherlich sollte man seine Programme/Projekte langfristig planen und versuchen alle Risiken zu minimieren. Doch Fehler schleichen sich immer ein.

Ich bin der Meinung, dass Programmierung eine praktische Angelegenheit ist. Doch um Algorithmen (Sortierung, Primzahl, usw) zu implementieren sollte man auch den theoretischen Zusammenhang verstehen.

Auf jedenfall, bin ich gespannt was andere Leute dazu sagen werden.

[Daniel]

Es ist in der Praxis leider unmöglich, jede Problemlösung bis ins letzte Detail vollständig zu erfassen. Spätestens dann, wenn ich externe Frameworks einbinde - zum Beispiel für die Kryptographie - muss ich mich auf deren Qualität verlassen können. So gesehen dürfte der von Dir skizzierte Weg eine fast alltägliche Praxis sein, solange wir von Allerwelts-Anwendungen reden: Wir haben hier im Forum Mitarbeiter von Flugzeugbauern, die für ihre Steuersoftware andere Maßstäbe ansetzen und jedes Framework bis auf die letzte Zeile auseinander nehmen. Dieser Aufwand ist aber nur in einer sehr begrenzten Menge an Einsatzgebieten wirtschaftlich.

Aber wenigstens den selbst programmierten Krams sollte man normalerweise im Griff haben und bei Bedarf für dessen Qualität geradestehen können. Werkzeuge zur systematischen Fehlersuche dafür gibt's ja genug wie z.B. Unit-Tests. Aber auch hier ist es wie immer eine Abwägung von Aufwand und Nutzen - man braucht schlichtweg nicht immer und überall das "perfekte" Programm. In dem Fall muss man sich nur der verbliebenen Risiken bewusst sein.

[Bummi]

wenn ich übermüdet und unter Zeitdruck in komplexer Materie unterwegs bin nutze ich diesen Ansatz gerne mal, um hinterher zu analysieren warum es so funktioniert.

[BUG]

Mit viel guter Laune könnten man es auch als naiven Ansatz für Test-driven-Development bezeichnen. Wenn du jetzt noch wiederholbare Tests verwendest ...

[Iwo Asnet]

[QUOTE=Delphi-Laie;1143580Seit längerem implementiere ich Sortieralgorithmen ... [/QUOTE] Diese Algorithmen müssen beweisbar korrekt sein. Weiterhin ist das Laufzeitverhalten von großem Interesse und nicht, das es "bei mir schneller als Methode XY" ist. Daher ist eine Analyse des Verfahrens bzw. des Algorthmus an sich sehr wichtig.

Zitat:

Ich habe für die meisten der Algorithmen ... die Ausdauer, mich in deren Funktionsweise hineinzudenken (oft fehlen mir auch Grundlagen dazu).

Dann eigne es dir an. Gute Bücher gibts zuhauf, selbst ich verstehe sie.

Zitat:

Also bin ich „Dünnbrettbohrer“

Das sind die meisten, aber bitte nicht bei o.g. Thema!

Zitat:

...Professoren ...wünschen sichere Fehlerfreiheit, und die natürlich mit Beweis

Ein formal korrekter Beweis ist nur bei kleinen Algorithmen (sortieren z.B.) möglich. Sobald es etwas komplexer wird, ist der formale Beweis eine Sisyphus-Arbeit, nicht praktikabel und wird im Übrigen auch nicht gefordert. Nur bei fundamentalen Algorithmen ist dies nötig, wichtig und richtig.

Zitat:

..Doch in der Programmierung bin ich Praktiker, und die Ersparnis an Zeit und Denkaufwand schätze ich als immens ein.

Das ist ein Trugschluss, denn deine Faulheit musst Du später doppelt und hundertfach teuer bezahlen. Mach es gleich richtig, das spart am meisten Zeit.

Zitat:

Nun meine Fragen...

Ich programmiere seit fast 40 Jahren, davon 30 professionell. Basialgorithmen mache ich mir zueigen und lese viel darüber. Komplexe Projekte werden zunächst skizziert. Nachdem die Subsysteme und Schnittstellen definiert sind, gehts an die Klassenstrukturen. Sind die fertig, wird umgesetzt. Alles im Review mit Kollegen, Kunden und viel Gequatsche. Alle wissen alles und grobe Schnitzer werden vermieden. Und wenns schief geht, waren alle Schuld.

Ein Kollege schwärmt von "Feinspezifikationen", bei denen jeder Button und jedes Verhalten vorher mit dem Kunden vereinbart wird. Das ist zwar Korinthenkackerei, ist aber letztendlich die effektivste Vorgehensweise. Es macht nur leider überhaupt keinen Spass, denn der arme Programmierer, der die Feinspec umsetzen muss, hat überhaupt keine Freiheiten.

Ich selbst programmierer manchmal immernoch munter drauflos, nur um mir an der nächsten oder übernächsten Wand eine blutige Nase zu holen. Ich kanns einfach nicht lassen Allerdings ist es manchmal keine verlorene Zeit, denn u.U. muss man sich mit der Materie erst einmal auseinandersetzen.

[himitsu]

Viele kleine evolutionär gewachsene Programmteile, in einem großen Projekt vereint, können auch schnell man all ihre keinen Unzulänglichkeiten in einem rießigen Problem vereinen.

[Luckie]

"Evolutionär"? Ich würde die Methode als "Versuch und Irrtum" bezeichnen.

Ich mache das auch manchmal. Aber wenn ich es mache, dann merke ich, dass ich eigentlich keinen Plan habe wie der Code wirklich funktioniert und dann versuche ich ihn zu verstehen.

[Mavarik]

Hi!

Ich nenne das Debugger-Programmierung...

Zeilen tippen... F4 sehen was passiert... ggf. Fehler beheben
Zeilen tippen... F4 sehen was passiert... ggf. Fehler beheben
Zeilen tippen... F4 sehen was passiert... ggf. Fehler beheben

Besonders bei Randbedingungen ist der Debug-View schneller als "überlegen" besonders ohne Kaffee Nacht's um 3

Mavarik

[Phoenix]

Zitat von Delphi-Laie:

Also bin ich „Dünnbrettbohrer“ und „schraube“ an allem möglichen Parametern und Variablen umher (veränderte Startwerte, veränderte Typen, Laufbereiche bei Schleifen usw. usf.), bis der Algorithmus anscheinend / offensichtlich fehlerfrei funktioniert. Das dauert i.d.R. nur Stunden, und bis auf eine Ausnahme gelang es mir bisher auch immer....
Wie schätzt Ihr das Restrisiko ein, daß man doch Fehler dabei einbaut bzw. übersieht? Ist das in Euren Augen eine praktikable, akzeptable Programmiermethodik?

Gegenfrage zu dem letzten Satz:
Wie oft musst Du Dir sowas hinterher nochmal angucken / etwas ändern, wenn es in irgendwelchen Fällen dann doch nicht passt, und wie lange bist Du dann wieder damit beschäftigt (inkl. neu Eindenken, 'rumprobieren' bis es auch in dem Fall passt)?

Eigentlich sind grad solche Dinge sehr einfach automatisiert testbar, und somit weisst Du auch automatisch, dass Du beim Ändern nichts mehr kaputt machst, was schon von Tests abgedeckt ist. Erfahrungsgemäß kosten Unittests nochmal so viel Zeit wie die eigentliche Implementierung, da aber im Laufe der Zeit die Behebung von Fehlern (insbesondere durch Fehler die durch Seiteneffekte auftreten) mehr als drei- bis viermal so Zeit kostet (und bei komplexeren Systemen mit der Zeit noch zunehmen) spart das hintenraus richtig viel Zeit.