Dieses Zahlenspiel: Rate eine Zahl zwischen eins und 127 mit maximal sieben Frage, kennt jeder. Stückchenweise eingrenzen, …

Insofern ist wohl verständlich, warum Programmierer in manchen Fällen total “chaotisch” (Intuitiv oder auch nicht) vorgehen. Und natürlich laufen Skriptsprachen sequentiell ab, nur ist das OO Programmiermodell dafür eigentlich nicht gemacht. Eher doch für die konkrete Aufgabenverteilung im Code in immer kleinere Einheiten (Vereinfacht wegen dem Disput um Daten- oder Funktionsortientierung).

Was ist ein Fehler? Diese fast philosophische Frage beschäftigt mich seit Beginn meiner Proggikarriere.
Ein erster provokativer Ansatz wäre: Ein Fehler ist ein nicht ausprogrammiertes Feature.

Andererseits gibt es Fehlerabfangmechanismen, die mich aber keinesfalls befriedigen, denn genau jeder abgefangene Fehler ist genau ein ausprogrammiertes Feature.

|so einfach ist das aus meiner sicht nicht. hier geht es
|nicht um: “was ist die ursache des fehlers?” sondern um
|“wie finde ich den fehler?”

Diesen Unterschied speichere ich mir in meine Sammlung “Was war zuerst da? Die Henne oder das Ei” Den Fehler finden ist recht einfach – die Ausgabe zeigt nicht das erwartete Ergebnis. Warum kommt es zu dieser und nicht der erwarteten Ausgabe? – Diese Frage scheint mir hier besser gestellt.

Dem Menschen passieren auch Fehler, viel wichtiger ist eben genau eine Kontrolleinheit, die dafür sorgt Fehler zu erkennen. Und wo die Kontrolleinheit bereits da ist, könnte sie ja auch bereits die Fehlerursache und den Fehlerort mitliefern.

Bei Gelegenheit nehme ich Ihr Angebot an. Mal sehen, wann es passt und ich in Dresden Zeit finde.

so einfach ist das aus meiner sicht nicht. hier geht es nicht um: “was ist die ursache des fehlers?” sondern um “wie finde ich den fehler?”

d.h. finde ich den fehler indem ich mir innerhalb einer zu betrachtenden methode fehlerquellen ausschliesse. und die übrigbleibenden mir anschaue. in jeder dieser potentiellen fehlerquellen gehe ich identisch vor. damit kann ich mich von methode zu methode hangeln und komme unweigerlich direkt zum fehler. gern können wir das mal gemeinsam machen.

hintergrund ist der, dass wir hier immer von skriptsprachen reden. da diese sequenziell hintereinander ablaufen, kann ich immer vom ende (sprich output) aus mich rückwärtsbewegen und die ursache logisch stringent ermitteln.

ist das jetzt verständlicher?

Habe jetzt verstanden: Nur was ist der Unterschied zwischen Logik und Intuition. Nach diesem Diskurs gibt es wohl nur einen klitzekleinen Unterschied. Kann ich es erklären ist es Logik, kann ich es nicht erklären ist es Intuition?

Wenn ich es erklären kann, kann ich es einer Software beibringen, kann ich es nicht erklären, dann funktioniert die Software nicht sehr lange. Spätestens beim nächstes co-Level wars das.

Also muss Software so geschrieben werden, dass die Software selbst den Fehler ermittelt und gleichzeitig am Computer des letzten Coders der Fehlerzeile eine “rote Lampe” angeht.

Schon mal daran gedacht die Software komplett datenbankgestützt zu programmieren? Das Pair Programming ist ja bereits Grundlage im Unternehmen.

Hier allerdings ging es mir eher darum, dass ich bei der Zusammenarbeit feststellte, dass viele Entwickler grundsätzlich beim Debugging zwischen “es könnte daran liegen” = Intuition und sauberem auf Logik basiertem Tracking und damit eindeutigen eingrenzen des Fehlers springen. Vor allem passiert das oft, wenn man ersten Versuchen nicht sehr weit kommt.

Also lass dich mit dem Problem vollquatschen, bis es bei dem Programmierer “klick” macht und schon biste wieder raus der Sache. Sinnvolle Fragen sind selbstredend angebracht. Ich haben dazu eine Fr.. im Haus. Hat keine Ahnung aber eben eine andere Sichtweise. Und nur daruaf kommt es an.

Gruß Veliks