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:

Zitat von Delphi-Laie (Beitrag 1143580)

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 ... :stupid:

[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 :oops:

Mavarik

[Phoenix]

Zitat:

Zitat von Delphi-Laie (Beitrag 1143580)

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.

[Delphi-Laie]

Iwo Asnet, bitte keine Belehrungen. Ich bin mir der Defizite dieses Vorgehens selbst bewußt, das müßte doch aus dem Eröffnungsbeitrage offensichtlich geworden sein. Außerdem schrieb ich, daß ich nicht die Ausdauer (wegen nicht überschäumenden Interesses) habe, mich in alle Subtilitäten hineinzudenken. Andere schreiben über nur eine Sortiervariante eine Dissertation! Was erwartest Du von einem Hobbyprogrammierer?

Zitat:

Zitat von Luckie (Beitrag 1143632)

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

Luckie, was macht die Evolution wohl sonst?

Ich habe das aus dem Buch, das ich mir zulegte, weil Du darob schriebst. Im letzten Kapitel ging es darum, wie die (auto-)evolutionäre Programmierung zu funktionstüchtigen, schnellen und nebulösen Sortieralgorithmen führt.

Zitat:

Zitat von Phoenix (Beitrag 1143641)

Zitat:

Zitat von Delphi-Laie (Beitrag 1143580)

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)?

Nicht allzu oft - "gefühlt".

[Namenloser]

Also machen andere das auch :lol:

Ja, ich mache das gelegentlich, wenn ich z.B. seit Stunden irgendeinem mir unverständlichen Fehler auf der Spur bin. Allerdings dauert es so nach meiner Erfahrung meistens länger, zum Ziel zu kommen, als wenn man sich wirklich mal konzentriert mit dem Code auseinandersetzt, und überlegt an die Sache rangeht. Aber nicht immer hat man dazu noch die Energie, vor allem wenn man schon eine längere Coding-Session hinter sich hat und/oder müde ist.

Ich kann mich z.B. noch daran erinnern, wie ich vor etwa einem Jahr einen Algorithmus geschrieben habe, um eine antialiaste Linie mit variabler Dicke und abgerundeten Enden (und Alphatransparenz) zu zeichnen (und das mit Festkomma-Arithmetik). Ich hatte mir natürlich erst nen tollen Algorithmus auf Papier skizziert, nur in der Praxis haute das nicht so recht hin – z.B. erschienen vollständig horizontale Linien einen Pixel dünner als minimal schräge, oder es gab plötzlich 1 Pixel große Lücken oder Überlappungen bei den runden Enden, oder an einer Kante funktionierte das Antialiasing plötzlich nicht mehr richtig... letztenendes also Rundungs-Probleme.

Leider gab es zig Stellen, wo irgendwas gerundet wurde (oder hätte gerundet werden können/müssen), und die Kombinationsmöglichkeiten von Abrunden, Aufrunden, mathematischem Runden, gar nicht Runden (Festkomma), nur 0.5 addieren/subtrahieren etc. waren schier endlos. Ich habe mehrere Stunden versucht, den Fehler analytisch zu finden, aber schließlich aufgegeben, und dann einfach so lange rumprobiert, bis es klappte. Hat mich zwei Nachmittage gekostet... :oops:

edit: @Mavarik: Ja, der Debugger ist für diese Vorgehensweise ein sehr nützliches Tool.

[Luckie]

@Delphilaie: Ich habe ja nichts dagegen gesagt, ich fand die Bezeichnung nur sehr schön. Und was für ein Buch meinst du und was habe ich dazu geschrieben? :gruebel:

[Namenloser]

[OT]Btw auf dem 28C3 (nein, ich war nicht dort ;)) gab es einen Beitrag zur automatisierten, evolutionären Algorithmus-Entwicklung mithilfe von Grafikkarten. Hoffentlich gibt es wieder Videomitschnitte von den Vorträgen; ich finde, das klingt recht spannend.[/OT]

[Delphi-Laie]

Zitat:

Zitat von Luckie (Beitrag 1143658)

@Delphilaie: Ich habe ja nichts dagegen gesagt, ich fand die Bezeichnung nur sehr schön.

Die stammt doch nicht von mir! Dafür ist sie viel zu schön.

Zitat:

Zitat von Luckie (Beitrag 1143658)

Und was für ein Buch meinst du und was habe ich dazu geschrieben? :gruebel:

Wer suchet, der manchmal sogar findet (nicht in den Foren, sondern in einem meiner Bücherregale): Daniel Hillis: Computerlogik.

Ich besorgte es für einen schlappen Ecucent (+ die obligatorischen 3 Ecu Versandkosten pauschal) von den Amazonen aufgrund einer lobenden Erwähnung in einem der beiden großen Delphiforen. Ich bin mir sehr sicher, daß ich über dieses Buch in einem Deiner Beiträge las. Dummerweise finde ich diesen Beitrag nicht wieder.

Edit: Oder las ich darob irgendwo auf Deiner Internetseite?

[Luckie]

Ach das: http://www.michael-puff.de/Programmi...volution.shtml

[Furtbichler]

Zitat:

Zitat von Delphi-Laie (Beitrag 1143647)

Zitat:

Zitat von Luckie (Beitrag 1143632)

"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.

Ansonsten ist Evolution nichts anderes als Versuch und Irrtum, wie Luckie schon sagte.

Also Hobbyprogrammierer kann man es so halten. Ich bin Hobbytischler und versuche dennoch, mit den richtigen Werkzeugen, dem richtigen Verständnis und den richtigen Techniken mein Hobby auszufüllen. Das ist aber eine Charakterfrage: Der eine wurschtelt gerne in seiner Freizeit rum, der andere fühlt sich erst wohl, wenn die Holzverbindung ohne Schrauben und Leim perfekt hält.

PS: Das, was Lucke darstellt, ist in der Tat 'Evolution'. Nur hat das nix mit dem Rumwurschteln zu tun, das manche dann als 'programmieren' bezeichnen. Es ist ein Gedankenexperiment. In der Tat kann man tolle Programme / Strategien entwickeln, in dem man ein Ziel vorgibt und dann einen genetischen(!) Algorithmus auf ein paar Programmzeilen loslässt. Irgendwo hab ich dazu mal ein lustiges Beispiel gesehen: Es ging um eine Simulation eines Schwarmes, der Futter finden sollte. dabei konnte er das Feld in einer bestimmten Strategie absuchen, sozusagen sein Programm. Das bestand aus Anweisungen wie "Laufe vorwärts", "laufe nach links" etc.

Die Evolution hat nun die Strategie/das Programm so verändert, das der Schwarm das Futter in optimal geringer Zeit gefunden hat. Echt lustig. Wenn ich nur wüsste, wo das war... Na, hier ist was ähnliches.

[Delphi-Laie]

Zitat:

Zitat von Furtbichler (Beitrag 1143670)

Zitat:

Zitat von Delphi-Laie (Beitrag 1143647)

Zitat:

Zitat von Luckie (Beitrag 1143632)

"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 :stupid:

[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: :thumb: Genau so isses!

[Delphi-Laie]

Zitat:

Zitat von BUG (Beitrag 1143721)

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

Das paßt wirklich gut und ist auch für mein Steckenpferd relevant:

Einen Größenoperator < oder > mit <= oder >= auszutauschen, kann schon entscheidend für die (In-)Stabilität eines Sortieralgoritmus' sein (relative Reihenfolge der Elemente mit gleichgroßem Schlüsselelement verändern oder beibehalten).

Und einen < mit einem > oder umgekehrt auszutauschen, kann die Sortierreihenfolge invertieren (also z.B. absteigend als aufsteigend).

Die von mir eingeworfene "evolutionäre" Programmierung meinte ich vor allem i.S. der Fehlerbeseitigungen (aber auch das tut die "echte" Evolution ja). Und anhand dieser simplen Vergleichsoperatoren läßt sich aber die Qualität von (Sortier-)Algorithmen entscheidend ändern und damit auch verbessern.

[Delphi-Laie]

Zitat:

Zitat von Furtbichler (Beitrag 1143722)

Eigentlich ist das aber alles Quark

Das ist die entscheidende Frage: Kreatives Ausprobieren und Verwerfen, Beibehalten teilverbesserter Lösungen usw. ist eine Vorgehensweise, der weder eine gewisse Systematik noch Erfolge abzusprechen sind. Die Welt der Lebewesen machte es vor und brachte auch uns Programmierer hervor, die darob diskutieren können.

Zitat:

Zitat von Furtbichler (Beitrag 1143722)

und als Projektleiter kann ich so etwas in keinem Fall gutheißen (nur vorübergehend dulden).

Warum "in keinem Fall gutheißen", dann aber wiederum "nur vorübergehend dulden"? Ist das nicht ein Widerspruch?

Ist die Zeitersparnis nicht doch der tatsächliche oder "gefühlte" Vorteil, der das dulden läßt?

Auch die tendenziell größere Fehlerarmut bei intensiverem Einarbeiten als bei von vornherein größerem Probieren ist diskutabel: Wie oft bekommt man von einem Programm nach der Implementation eines Algorithmus', einer Idee, von diesem Programm einen Denkfehler in seinem Konzept vorgeführt?

[Furtbichler]

Der Unterschied zur Natur ist der, das die Natur nie fertig wird: "Nach dem Verbessern ist vor dem Verbessern".

Wenn Du deine Heuristik (nennen wir sie mal so) nie auf die Menschheit loslässt, ist alles ok und die Vorgehensweise in der Tat nicht zu beanstanden. Nur im Berufsleben wird man das Resultat deiner Optimierungsbemühungen irgendwann einsetzen oder dem Kunden übergeben. Und dann kann man nur eines von dem Ergebnis sagen: "Es ist nicht fertig", denn das ist ja Mutter Natur auch nie.

Zitat:

Zitat von Delphi-Laie (Beitrag 1143724)

Warum "in keinem Fall gutheißen", dann aber wiederum "nur vorübergehend dulden"? Ist das nicht ein Widerspruch?

Ich dulde es, wenn sonst die Abnahme in die Hose geht. Das Problem wird jedoch in jedem Fall anschließend richtig gelöst. Meist ist der Kunde jedoch genauso der Ansicht, das die Lösung lieber gleich ordentlich umgesetzt wird. Dann verschiebt sich die Abnahme eben (sofern nicht kostenpflichtig).

Sollte dir mein Beispiel (aus dem echten Berufsleben) nicht Lehre genug sein, um eine Frage wie "Ist die Zeitersparnis nicht doch der tatsächliche oder "gefühlte" Vorteil, der das dulden läßt? nicht mehr zu stellen? Es ist schlicht und ergreifend Faulheit und Schlamperei, wenn ich etwas, was ich ordentlich erledigen könnte, nur so lange hinschludere, "bis es irgendwie hinhaut", oder "der Kunde zufrieden ist", oder "das Teil doch funktioniert" oder oder oder. Glaube mir: Diese Vorgehensweise beschehrt dir viele unnötige Besuche beim Kunden. Oder im schlimmsten Fall: Schadensersatzforderungen. Du bist nämlich verpflichtet, nicht fahrlässig zu arbeiten. Und was ist diese Einstellung denn anderes als "fahrlässig"?

Grenzsituationen, wie "Schnittstelle, ohne Beschreibung" oder "nichtdeterministische Probleme" werden mit dem Kunden abgestimmt. Hier ist nichts anderes als die o.g. experimentelle Vorgehensweise möglich. Wobei ich mich beim ersten Problem (Schnittstelle ohne Spec) meist weigere, dies umzusetzen sondern verlange, das diese verdammte Spec aufzutreiben ist. Na, und wenns eben gar nicht anders geht, dann hilft eben nur Try & Error.

Umgekehrt hebst Du dich von der Masse ab, wenn Du qualitativ hochwertige Arbeit ablieferst, die nachhaltig und robust funktioniert.

Lassen wir mal die Kirche im Dorf: Grau ist alle Theorie und in der Praxis wird natürlich (wie schon erwähnt) auch mal gefrickelt. Dann verlange ich aber, das dies im Code explizit durch dicke fette Kommentare kenntlich gemacht wird. Der Programmierer muss seinen Namen angeben und beschreiben, warum er diese Frickellösung nehmen musste.

Übrigens weigern sich die meisten meiner Jungs, Schrott zu programmieren, nur damit es irgendwie läuft. Weil, im Endeffekt sind sie es, die die Suppe auslöffeln müssen. Also machen sie es gleich richtig.

Zitat:

Auch die tendenziell größere Fehlerarmut bei intensiverem Einarbeiten als bei von vornherein größerem Probieren ist diskutabel: Wie oft bekommt man von einem Programm nach der Implementation eines Algorithmus', einer Idee, von diesem Programm einen Denkfehler in seinem Konzept vorgeführt?

Na ein Grund mehr, Sachen richtig umzusetzen. Oder bist Du mit (unentdeckten) Denkfehlern in deinem Programm zufrieden?

[Coffeecoder]

Man darf nicht alles in einen Topf werfen.
Es gibt Leute die beruflich mit der Programmierung zu tun haben und die in der Freizeit programmieren.

Es wurde ja schon erwähnt:

Zitat:

Zitat von Furtbichler (Beitrag 1143728)

Übrigens weigern sich die meisten meiner Jungs, Schrott zu programmieren, nur damit es irgendwie läuft. Weil, im Endeffekt sind sie es, die die Suppe auslöffeln müssen. Also machen sie es gleich richtig.

Man kann sagen,dass die Berufsprogrammierer diese "Hauruck"-Methoden besser sein lassen (sollten) und gleich überlegt an die Sache rangehen.

Die Hobby-Programmierer oder auch Anfänger tendieren eher zu dieser "Methode" zu programmieren.
Doch unabhängig davon ob Programmierung mit Beruf oder Freizeit zu tun hat, sollte man generell immer in irgendeiner Form seine Idee dokumentieren, darstellen und überlegt an sein Programm/ Problem rangehen.

[bernerbaer]

_Ich_ möchte hier doch noch klar differenzieren zwischen rumfrickeln und dem gesagtem im Ausgansgsposting:

Zitat:

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.

Und hier habe ich gerade bei mir festgestellt, dass professionelle Programmierer in der Regel öfters auf externe Quellen und Informationen angewiesen sind als Hobbyprogrammierer. Wer als Hobby programmiert, versucht sich nur an Dingen, die ihn auch interessieren und über die er bescheid weiss. Der professionelle Programmierer jedoch muss coden was von ihm verlangt wird. Das kann einmal aus dem Anlagensteuerungsbereich sein, ein anderes mal aus dem Wirtschaftsbereich, ein drittes mal aus der Forschung usw. Gerade deshalb ist es so, dass ein umfassendes Grundwissen nicht immer vorausgesetzt werden kann, ich kann von einem Programmierer nicht erwarten, dass er Informatik, Mathematik, Wirtschaftswissenschaft, Ingenieurstechnik, usw erfolgreich als Studium möglichst noch mit einem Doktortitel abgeschlossen hat. Deshalb ist ein professioneller Informatiker immer wieder auf externes Wissen, allenfalls sogar auf externen Code angewiesen, den er nur so versteht: "Das gebe ich rein - das kommt raus - also muss es korrekt sein". Das hat aber keineswegs etwas mit rumfrickeln zu tun und soll auch klar definiert und im Code angegeben werden: z.B. Code basiert auf dem Algo von XY - Quelle: xy

Dass Delphi dieses Vorgehen zudem deutlich fördert, ist der Komponentenansatz. Kaum jemand macht sich zum Beispiel noch Gedanken zu der RTF- oder der JPG-Spezifikation um nur zwei Beispiele aufzuführen, man verwendet die entsprechenden Units und damit hat es sich (bis der erste Fehler in der Komponente auftaucht).

[Valle]

Zitat:

Zitat von Furtbichler (Beitrag 1143722)

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 ....

Ich habe mir schon gedacht dass du genau diesen Satz aus dem Kontext reißen wirst. ;-) Ich schrieb ja dazu: Wenn der Verdacht besteht, dass da mehr dahinter steckt, dann ist so ein Lösungsweg natürlich nicht in Ordnung. Genau von diesen veränderbaren Eingangbedingungen habe ich gesprochen. Und ich rede von derartig banalen Kleinigkeiten, dass es einfach ist, zu erkennen, ob man solche Bedingungen möglich sind.

Mit dem von dir angegebenen Beispiel bin ich mir allerdings mittlerweile recht sicher, dass du noch nicht wirklich verstanden hast, von welcher Art von Problemchen ich spreche.

Zitat:

Zitat von Furtbichler (Beitrag 1143722)

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

Denkst du dabei eigentlich nur an Programmiersprachen an sich, oder auch an Sachen wie HTML und CSS? In unserer Firma bin ich als Webentwickler eingestellt und habe deswegen (neben dem Backend natürlich) sehr viel mit HTML zutun. Das ist auch ein prima Beispiel für die beschriebene Art von Problemlösung. Hast du schon mal versucht eine inhaltlich voll gepackte Seite mit viel JavaScript und modernen Design auf allen halbwegs noch verwendeten Browsern zum Laufen zu kriegen? Ich möchte den sehen der hier nicht 'rumfummelt'.

Zitat:

Zitat von Furtbichler (Beitrag 1143722)

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.

Und ich verstehe deine, auch wenn ich (falls du mich doch richtig verstanden hast) anderer Meinung bin. Es ist schwer zu beschreiben welche Situationen das sind. Leider fällt mir auch kein praktisches Beispiel ein - und selbst wenn: Es ist schwer so etwas nachzuvollziehen. Möglicherweise fällt mir dieser Thread in der nächsten Situation mal wieder ein.

Dass du mich nicht falsch verstehst. Eine genaue Planung und detailliertes Verständnis von dem was man macht ist sehr wichtig beim Programmieren. Ich bin durchaus in der Lage zu entscheiden, wann ich wie zu arbeiten habe. Klar, Fehler macht jeder, aber wenn ich 'rumprobiere', dann bin ich sicher dass es zu diesem Zeitpunkt akzeptabel ist.

@bernerbaer: Deine Erklärung gefällt mir auch sehr gut! :)

Liebe Grüße,
Valentin

[Sailor]

Keine Ahnung, wie man ein Zitat einstellt, ich beziehe mich auf das hier:

Und ich rede von derartig banalen Kleinigkeiten, dass es einfach ist, zu erkennen, ob man solche Bedingungen möglich sind.

In unserem Beruf gibt es sowas nicht. Wenn Du eine M3-Schraube, mit der das Typenschild an einem Motor befestigt ist, rausdrehst, läuft der Motor klaglos weiter. Wenn Du aber ein '<' gegen ein '>' tauschst, kann das gesamte System seinen Geist aufgeben. In den CACM gab es vor einiger Zeit mal Lobpreisungen von "good enough" Programmen. Ich hätte gern gewußt, was der Autor sagen würde, hätte man ihm für sein gutes Geld ein "good enough" Auto angedreht. Wenn da jemand am Abend am Computer zu seinem Vergnügen rumprogrammiert, bitte schön. Aber von jemandem, der seine Erzeugnisse verkauft, kann man gute Arbeit verlangen.

Und das Schönste ist wohl das hier:

Hast du schon mal versucht eine inhaltlich voll gepackte Seite mit viel JavaScript und modernen Design auf allen halbwegs noch verwendeten Browsern zum Laufen zu kriegen?

Schon mal dran gedacht, daß diese Browser vielleicht "evolutionär" enstanden sind?

[Delphi-Laie]

Zitat:

Zitat von Sailor (Beitrag 1143753)

Keine Ahnung, wie man ein Zitat einstellt

Rechts unten auf die Schaltfläche ("Button") des Beitrages klicken, den (oder aus dem) man zitieren möchte.

[Valle]

Zitat:

Zitat von Sailor (Beitrag 1143753)

Schon mal dran gedacht, daß diese Browser vielleicht "evolutionär" enstanden sind?

Ähm. Eigentlich ist mir das herzlich egal wie die entstanden sind. Tatsache ist, dass Altlasten und Abwärtskompatibilität einen Großteil der heutigen Probleme in dieser Technik ausmachen. Mangelhafte Spezifikationen und Standards sowie Microsofts Gier immer einen eigenen Brei kochen zu müssen führten dann letztendlich dazu, dass HTML und CSS heute keinen Spaß mehr machen. [/meinung]

Wenn du aber schon so provokant danach fragst, ob genau solch schlechte Software wie die Browser durch evolutionäre Programmierung entstanden ist, dann denke ich hast auch du nicht verstanden was ich darunter verstehe. Hier wurden auf ganz anderen Ebenen Fehler gemacht.

Offensichtlich ist meine persönliche Interpretation des Begriffs der evolutionären Programmierung nicht wirklich für die Meisten hier gültig. Wahrscheinlich verstehe ich das im Gesamten nicht ganz so wie der TE es meinte. Möglicherweise solltet ihr meine Meinung dazu deswegen nicht allzu ernst nehmen. :gruebel:

Liebe Grüße,
Valentin

[Furtbichler]

Oh Gott, bitte nicht HTML + JavaScript + Browser ins Spiel bringen. Dann gebe ich mich geschlagen ;-)

Aber das sind ja nun mal "nichtdeterministische" Probleme. So wie der Umgang mit einer Frau. Da hilft auch nur "Versuch und Irrtum". ;-)

Ich kann mir übrigens keinen Profi- (oder Hobby-)programmierer vorstellen, der allen Ernstes behaupten würde, mit Rumfrickeln und Probieren schneller und besser ans Ziel zu kommen. Umgekehrt gilt aber auch, das man nicht jeden Pups analytisch herleiten und beweisen muss.

[Valle]

Zitat:

Zitat von Furtbichler (Beitrag 1143760)

Oh Gott, bitte nicht HTML + JavaScript + Browser ins Spiel bringen. Dann gebe ich mich geschlagen ;-)

Aber das sind ja nun mal "nichtdeterministische" Probleme. So wie der Umgang mit einer Frau. Da hilft auch nur "Versuch und Irrtum". ;-)

Nichtdeterministisch find ich klasse beschrieben! :lol:

Zitat:

Zitat von Furtbichler (Beitrag 1143760)

Ich kann mir übrigens keinen Profi- (oder Hobby-)programmierer vorstellen, der allen Ernstes behaupten würde, mit Rumfrickeln und Probieren schneller und besser ans Ziel zu kommen. Umgekehrt gilt aber auch, das man nicht jeden Pups analytisch herleiten und beweisen muss.

Man kann eben nicht immer einer Meinung sein.

Ich könnte mir auch vorstellen, dass diese Einstellung bei mir auch dadurch kommt, dass ich bisher nie in den Genuss einer schnellen Internetverbindung gekommen bin. Beispielsweise nachschauen in welcher Reihenfolge Parameter einer Funktion stehen, oder ob der zweite Parameter substr()-Funktion jetzt die Anzahl der folgenden Zeichen oder den Index des letzten Zeichen angibt. Sowas dauert hier viel länger als es einfach zu probieren. Ich denke das wäre ein Beispiel, welches gut zeigen müsste was ich meine.

Liebe Grüße,
Valentin

[Namenloser]

Zitat:

Zitat von Valle (Beitrag 1143762)

Ich könnte mir auch vorstellen, dass diese Einstellung bei mir auch dadurch kommt, dass ich bisher nie in den Genuss einer schnellen Internetverbindung gekommen bin. Beispielsweise nachschauen in welcher Reihenfolge Parameter einer Funktion stehen, oder ob der zweite Parameter substr()-Funktion jetzt die Anzahl der folgenden Zeichen oder den Index des letzten Zeichen angibt. Sowas dauert hier viel länger als es einfach zu probieren. Ich denke das wäre ein Beispiel, welches gut zeigen müsste was ich meine.

Naja, zum Glück hat ja jede gescheite IDE/jeder gescheite Editor heutzutage Code Completion...

[Valle]

Code Completion wird schwer bei Script- und Auszeichnungsprachen.
Und das ist nunmal mein Job.

Liebe Grüße,
Valentin

[Namenloser]

Also mit Netbeans klappte das bei mir bisher immer ganz gut – zumindest mit Ruby, PHP und Python. Aber selbst billige Editoren wie Notepad++ haben meist eine einfache Liste von Standardfunktionen (wie eben substr und Co.), die zwar nicht kontextsensitiv, aber dennoch einigermaßen brauchbar ist, wenn man schon weiß, welche Funktion man aufrufen will und nur die Parameterreihenfolge nachschauen will.

[Furtbichler]

Hi Valle,

Das Erarbeiten von Parameterreihenfolgen, oder allgemein 'wie etwas funktioniert' ist aber kein Programmieren, sondern eine Methodik, um sich Wissen anzueignen.

Bei zwei Parametern, bei denen nur ihre Reihenfolge relevant ist, gibt es ja nur 2 Möglichkeiten.

Allgemein gesehen kann ich bei Problemen mit abzählbar vielen Möglichkeiten diese durchprobieren und die Ergebnisse bewerten. Ich vergleiche jeweils erwartete mit tatsächlichen Ergebnissen. Das ist kein 'Rumprobieren', sondern wissenschaftlich fundierte Arbeit und vollständig.

Der Threadersteller meint aber etwas anderes.