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

[Delphi-Laie]

Zitat von Furtbichler:

Zitat von Delphi-Laie:

Zitat von Luckie:

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

Luckie, was macht die Evolution wohl sonst?

Dummerweise ist der Begriff belegt. Ein komisches Buch, das rumfrickelndes rumprobierendes Rumprogrammieren mit einem evolutionären Prozess vergleicht. Weiterhin müsstest Du mir mal den Sortieralgorithmus zeigen, bei dem man durch rumschrauben (schon wieder 'Rum', das bringt mich auf eine Idee.. Grog!) von Parametern irgendetwas erreichen kann.

Es geht nicht darum, einen bereits funktionierende Idee zu verbessern, sondern die Implementation anzupassen, zu korrigieren.

Simples Beispiel, das z.B. bei Sortieralgorithmen immer wieder auftaucht: n ist die Elementeanzahl. Man hat z.B. anzupassenden Quellcode, bei dem die Indizes von 1 bis n laufen. Bei mir aber laufen sie von 0 bis n-1. Alles mögliche (nicht zwangsläufig alles) muß daraufhin angepaßt werden. So wird z.B. oft die Mitte benötigt, also div 2 (oder shr 1) ausgeführt. Die springt aber, abhängig, ob die Ausgangszahl gerade oder ungerade ist, aber eben nicht immer, sondern nur bei jedem zweiten Wechsel zwischen gerade und ungerade. Werden alle Indizes in der Implementation um 1 verringert, werden aus geraden ungerade und umgekehrt, und schon kann die Mitte ungeahnte Effekte verursachen.

Derlei Fallstricke lauern zu hunderten, und man kann diese systematisch suchen oder eben durch Ausprobieren aufzuspüren versuchen.

Wird es nun allmählich klarer, inwieweit man "rum"probieren und dieses auch zum Erfolg führen kann?

[Namenloser]

@Furtbichler: Naja, es ist schon eine Form von Evolution, wenn man einen Algorithmus durch kleine Veränderungen im Trial&Error-Verfahren immer weiter dem „Optimum“ annähert. Man simuliert eben nur von Hand den evolutionären Prozess, statt dass man ihn automatisiert ablaufen lässt. Das ganze ist nur insofern irreführend, dass, wie du schon sagst, unter „Evolutionärer Programmierung“ normalerweise etwas anderes verstanden wird.

[Luckie]

Na ja, ich habe eben nur gemerkt, dass wenn ich so anfange, ich den Algorithmus nicht verstanden habe.

[Furtbichler]

Ich verstehe. Ich nenne diese Art von Programmierung 'Heuristik', denn man hat ein Regelwerk, das man durch Versuch und Irrtum ver(schlimm)bessert.

Ich habe mal ein Silbentrennprogramm geschrieben (ja, ich bin alt). Da habe ich mit einer Art Phoneme, Wortteilen oder wie auch immer rumgebapselt. Zum Schluss war es richtig gut, aber ich habe Sonderfälle und Regeln und was weiss ich eingebaut und immer gegen mein Wörterbuch von 1000 Wörtern getestet.

DAS war -wenn man so will- evolutionär.

Sowas mach ich aber nicht. Oder -hups- doch, gerade gestern. Aber das ist Frickeln, sowas nenne ich rumspielen und experimentieren. Schaden tut es nicht, aber in produktive Systeme wird sowas nicht übernommen. Grauenvoll..

[Valle]

Hallo!

Dieses 'evolutionäre Programmieren' kommt mir durchaus sehr bekannt vor. Ich denke aber dass einige hier das etwas zu eng sehen. Es geht m.E. nicht darum das gesamte Programm nur durch trial & error zu schreiben - sondern einzelne Fehlerfällle dadurch zu beheben.

Gerade wenn es um Indizes oder eher ungenaue Beschreibungen von Schnittstellen geht, ist dieser Weg nicht selten auch der schnellere; besonders wenn der Tag sich dem Ende neigt. Wenn ich einen String auf bestimmte Weise zurecht schneiden muss und bei der Ausführung einen Fehler bekomme oder das Ergebnis schlichtweg falsch ist, dann ist es für mich oft schneller 'nach Erfahrung' an den Eckpunkten einer substr-Funktion zu raten. Insbesondere bei Scriptsprachen, in denen auch negative String-Längen und -Indizes eine Bedeutung haben kommt man schnell mal durcheinander bei den ganzen +1 und -1.

Das Restrisiko ist zumindest bei den Fällen ich denen ich dieses Prinzip anwende nicht existent. Wenn die Lösung funktioniert dann ist sie richtig. Wenn Verdacht darauf besteht dass eine Funktion nicht allgemeingültig genug funktioniert, dann wird diese Art von Problemlösung nicht angewendet, ganz einfach. Dann heißt es Gehirn einschalten, woanders weiter arbeiten oder den Lösungsweg im Gesamten vereinfachen.

Um das nochmal zu betonen: Ich meine damit banale Probleme im Detail bei der Implementation. Vom Rumspielen bei der Planung eines großen Programms hat keiner gesprochen. Deshalb sehe ich auch keinen Grund mir bei der gelegentlichen Anwendung der Verfahrens an der richtigen Stelle (!) Unprofessionalität vorzuwerfen. Wenn das Ergebnis der Spezifikiation entspricht und ich schnell und korrekt gearbeitet habe, dann ist doch alles okay, oder?

Liebe Grüße,
Valentin

[Sailor]

Das diskutierte Verfahren würde ich eher experimentell nennen. Unter evolutionärem Programmieren verstehe ich: Beginne mit einem Kern, der eine gewisse Minimalfunktionalität abdeckt und erweitere den im Laufe der Zeit konsistent, d.h. ohne das zu zerstören, was bereits funktioniert. Im übrigen ist mir unverständlich, wie man aus der Implementierung eines Algorithmus eher dessen Funktionsweise verstehen lernen will als aus seiner Beschreibung, die ja gerade von den (für das Verständnis unwesentlichen) Implementierungsdetails abstrahiert und demzufolge viel klarer die Grundidee erkennen läßt.

[BUG]

Das passt so gut zum Thema, dass ich es heraussuchen musste

[Furtbichler]

Ich kenn keinen Fall, bei dem Frickeln (aka 'Rumprobieren') zu einer nachhaltigen Lösung führte. Natürlich wird man in der Praxis, speziell, wenn es 5 vor 12 ist (oder noch später) und der Milestone drängelt, eher zu solchen Brachialmitteln greifen. Oder wenn man nur mal fix ein Helferlein programmieren muss (Filter, Transformer z.B.)

Eigentlich ist das aber alles Quark und als Projektleiter kann ich so etwas in keinem Fall gutheißen (nur vorübergehend dulden).

Wie gesagt: Es gibt durchaus Probleme, die derzeit nur durch Rumprobieren 'gelöst' werden können, wobei das dann keine Lösung ist, sondern ein mehr oder minder schlechter Versuch, einen halbwegs stabilen Output für ein (nichtdeterministisches) Problem zu finden.

Beispiel: Wir hatten eine Adressdatenbank mit vielen Duplikaten, und natürlich sollten die Duplikate raus. Nur, was ist ein 'Duplikat'? ("Dr. Meier vs. "Hans Meier (Dr.)". Hier kann man schlecht eine Formel definieren, sonder muss versuchen, mit heuristischen Mitteln das kleinste Übel zu finden. DAS wäre (und war) ein Fall für Frickler und etwas rumprobieren und etwas an Parametern drehen.

[QUOTE=Valle;1143711]Gerade wenn es um Indizes oder eher ungenaue Beschreibungen von Schnittstellen geht..[QUOTE] Na, da schaue ich aber lieber genau hin, als rumzuprobieren.

Zitat:

Wenn die Lösung funktioniert dann ist sie richtig.

Eingestellt würdest Du von mir mit dieser Einstellung nicht. Kurze Frage: Was passiert, wenn die Eingangsbedingungen etwas verändert werden? Dann knallt dir deine 'Lösung' u.U. und unvorhersagbar um die Ohren. Wenn das dann in einer Produktivumgebung passiert, dann ....

Zitat:

Um das nochmal zu betonen: Ich meine damit banale Probleme im Detail bei der Implementation.

Gerade dort muss man aufpassen, bei den ach so einfachen Problemchen. Einer unserer Programmierer hat eine Schnittstelle genauso umgesetzt, wie von dir beschrieben. "Komisch, am Ende der Antwort von der anderen SEite sind immer 2 so komische Zeichen. Ach die schnippel ich einfach weg, passt scho' und dann klappt es endlich.". Super, hat auch funktioniert... Nur war das ein CRLF, das man auf Senderseite auch weglassen konnte. Und dann wurde auf Senderseite eben mal in der Config das optionale CRLF entfernt, alles gemäß Spec. Bis wir den Fehler gefunden hatten, war ein Produktionsausfall von mehreren 100k Euro zu verbuchen. Und das bloß, weil jemand so lange rumprobiert hat, bis es funzte, anstatt die Spec zu lesen.

Zitat:

Deshalb sehe ich auch keinen Grund mir bei der gelegentlichen Anwendung der Verfahrens an der richtigen Stelle (!) Unprofessionalität vorzuwerfen.

Die Fragen aller Fragen lautet ja: "was ist die richtige Stelle"? Und darauf gibt es keine Antwort: Es ist nämlich Glückssache.

Zitat:

Wenn das Ergebnis der Spezifikiation entspricht und ich schnell und korrekt gearbeitet habe, dann ist doch alles okay, oder?

Eben nicht. Das "schnell" hat nix mit Qualität zu tun und das "korrekt" nicht mit dem, was Du hier beschrieben hast.

Isoliert betrachtet, ist die Aussage natürlich korrekt (und banal): "Wenn ich alles richtig gemacht habe, ist (doch) alles okay, oder?"

Ich kann deine Haltung verstehen, früher war ich auch so. Aber es ist unprofessionell. Schlicht und ergreifend. Und sehr teuer. Auf lange Sicht.

Meine Meinung.

@BUG: Genau so isses!