Ich kann nicht programmieren....
-
TravisG schrieb:
meh, das klingt vll. doof, aber ich habe bis jetzt noch nie einen debugger gebraucht und kann mir auch nicht vorstellen den jemals zu brauchen. probleme die mit dem debugger gelöst werden können schienen mir in der vergangenheit und jetzt einfach viel zu trivial als dass ich tatsächlich den debugger angeworfen hätte.
Man macht Fehler beim programmieren - das ist einfach so. irgendwo springt der code in den falschen branche, irgendwo hat man einen spezialfall uebersehen, etc.
natuerlich kann man die sachen auch ohne debugger finden, aber wir wollen doch nicht zu debug-printfs zurueck fallen, oder?
alleine das problem wenn das programm abstuertzt - wo ist es abgeschmiert? oder man faengt eine exception die sagt, da war ein null zeiger der da nie haette sein duerfen - wie findet man sowas? meistens ist der fehler in der tat trivial, aber wie findet man am schnellsten die stelle im code? mit dem debugger rein, kontext ansehen und man hat schonmal einen guten ansatz.
oder wie findest du so einen fehler?
zB logikfehler. entweder man macht debug ausgaben oder man verwendet einen debugger. den code zu analysieren kostet enorm viel zeit und wenn man pech hat, analysiert man die falsche stelle. debugger sparen da soviel zeit...
-
Shade Of Mine schrieb:
oder wie findest du so einen fehler?
Fehler, die das Programm abstürzen lassen (zugriffe out of range oder auf unreferenzierte zeiger und sowas) kommen einfach nicht mehr vor. Und wenn, dann weiss ich sofort von welcher Stelle es kommt, da ich einzelne Teile des Programms programmiere und danach einzeln Teste bis sie wirklich perfekt (für den Zweck den sie erfüllen) sind.
Shade Of Mine schrieb:
zB logikfehler.
Wie schon erwähnt bearbeite ich einzelne Ausschnitte genau und gehe Logikfehler wesentlich schneller im Kopf durch als mit dem Debugger. In der Regel ist es so, dass mir der Debugger nur den Fehler zeigen würde, den ich ohnehin kenne. Zur Lösung führt mich da keiner.
-
TravisG schrieb:
Fehler, die das Programm abstürzen lassen (zugriffe out of range oder auf unreferenzierte zeiger und sowas) kommen einfach nicht mehr vor. Und wenn, dann weiss ich sofort von welcher Stelle es kommt, da ich einzelne Teile des Programms programmiere und danach einzeln Teste bis sie wirklich perfekt (für den Zweck den sie erfüllen) sind.
[...]
Wie schon erwähnt bearbeite ich einzelne Ausschnitte genau und gehe Logikfehler wesentlich schneller im Kopf durch als mit dem Debugger. In der Regel ist es so, dass mir der Debugger nur den Fehler zeigen würde, den ich ohnehin kenne. Zur Lösung führt mich da keiner.In welcher Branche arbeitest du? Klingt wie eine Utopie.
Unittests fangen zwar viele Fehler, aber bei weitem nicht alle. Vorallem was Unittests idR nicht testen ist das zusammenspiel der einzelnen units.Aber sagen wir das alles waere perfekt. Dann bleibt immernoch das Problem der Implementierung eines neuen Algorithmus bestehen. Hatte ich zB gestern: Ein Unittest hat einen Absturz gefangen. Testdaten angesehen, nichts komisches aufgefallen, sah aus wie die Daten bei den bestandenen tests. Also debugger an, durchgestept und siehe da - das Problem war dass es einen Fehler bei der Behandlung von leeren Feldern gab. Es wurde einfach ein spezialfall uebersehen. Das war aber anhand der testdaten nicht offensichtlich, man musste in den algo selber reingehen und sich ansehen was passiert und warum da etwas falsches passiert.
natuerlich haette man theoretisch auch von alleine darauf kommen koennen dass da ein spezialfall nicht abgedeckt wurde - aber so ganz trivial waere es nicht gewesen. dagegen mit dem debugger -> total simpel. ich habe ja exakt an der absturzstelle gesehen dass ein end-iterator dereferenziert wurde.
-
Leute, der Threadsteller will doch gar nicht programmieren koennen. Er will nur seine Pruefung bestehen.
-
TravisG schrieb:
Shade Of Mine schrieb:
oder wie findest du so einen fehler?
Fehler, die das Programm abstürzen lassen (zugriffe out of range oder auf unreferenzierte zeiger und sowas) kommen einfach nicht mehr vor. Und wenn, dann weiss ich sofort von welcher Stelle es kommt, da ich einzelne Teile des Programms programmiere und danach einzeln Teste bis sie wirklich perfekt (für den Zweck den sie erfüllen) sind.
Shade Of Mine schrieb:
zB logikfehler.
Wie schon erwähnt bearbeite ich einzelne Ausschnitte genau und gehe Logikfehler wesentlich schneller im Kopf durch als mit dem Debugger. In der Regel ist es so, dass mir der Debugger nur den Fehler zeigen würde, den ich ohnehin kenne. Zur Lösung führt mich da keiner.
Dann hast du also noch nie mit anderen Leuten zusammen was großes programmiert, oder waren die auch alles so perfekt wie du und die Schnittstellen haben perfekt gepasst und es gab keine Missverständnisse...
Zähl doch einfach mal auf, was du größeres programmiert hast und mit wieviel Leuten.
-
Verurteilt TravisG mal nicht für seine Arbeitsweise. Im Linux Kernel gibt es keinen (Kernel) Debugger genau aus diesem Grund, denn Linus will nicht, dass die Leute mit dem Debugger anfangen wild rumzusuchen und evt. nur Symptome zu beheben statt sich den Code anzuschaue und zu überlegen und zu verstehen warum er schief geht.
Seine Arbeitsweise hat also durchaus ihre Daseinsberechtigung, allerdings scheint es mir als würde er sie aus einer anderen Einstellung heraus praktizieren wie ich oben skizziert habe.
-
Linuxxer schrieb:
Im Linux Kernel gibt es keinen (Kernel) Debugger [...]
-
rüdiger schrieb:
Linuxxer schrieb:
Im Linux Kernel gibt es keinen (Kernel) Debugger [...]
2.6.26 ist noch so neu, den gibt es seit 2 Monaten erst! Und in der Patch-Zusammenfassung von Linus steht der überhaupt nicht drin.
-
Linuxxer schrieb:
Verurteilt TravisG mal nicht für seine Arbeitsweise. Im Linux Kernel gibt es keinen (Kernel) Debugger genau aus diesem Grund, denn Linus will nicht, dass die Leute mit dem Debugger anfangen wild rumzusuchen und evt. nur Symptome zu beheben statt sich den Code anzuschaue und zu überlegen und zu verstehen warum er schief geht.
Aeh, nein. Linus weiss genau dass ein Debugger vieles einfacher machen wuerde - aber genau das will er nicht. Und sein 2. Punkt ist, dass im Kernel ein Debugger sowieso nur halb so effektiv ist (was bei kernels eben zu trifft).
Siehe zB http://linuxmafia.com/faq/Kernel/linus-im-a-bastard-speech.html
-
Shade Of Mine schrieb:
Aeh, nein. Linus weiss genau dass ein Debugger vieles einfacher machen wuerde - aber genau das will er nicht.
linus übertreibt mal wieder maßlos, aber in einem punkt gebe ich ihm recht: es ist oft besser, dinge zu verstehen, als blind im nebel herumzustochern.
Shade Of Mine schrieb:
Und sein 2. Punkt ist, dass im Kernel ein Debugger sowieso nur halb so effektiv ist (was bei kernels eben zu trifft).
warum eigentlich? bei den fehlern, bei denen ein debugger wirklich weiterhelfen würde, also wenn nach aller logik, scharfblick und dreimaligem lesen der dokumentation der code immer noch spinnt, kann man froh sein, wenn man einen hat. in solchen fällen bleibt den armseligen linux-kernelhackern nichts anderes übrig, als ihre kreationen mit 'kprintf's zu verschönern.
-
Für die "Kritiker" der Arbeitsweise von TravisG:
Schaut euch mal Cleanroom Programming an. Da hat der Programmierer nichtmal nen Compiler zur Verfügung stehen und kann nur Code schreiben.
-
loks schrieb:
Für die "Kritiker" der Arbeitsweise von TravisG:
Schaut euch mal Cleanroom Programming an. Da hat der Programmierer nichtmal nen Compiler zur Verfügung stehen und kann nur Code schreiben.
Und macht das mehr als 0,1 Prozent der Softwareentwickler? Wohl kaum.
Ich bin ja gespannt, ob TravisG mal verrät, was er so programmiert oder ob er mal wieder nur was in den Raum wirft ohne konkret zu werden.
-
loks schrieb:
Für die "Kritiker" der Arbeitsweise von TravisG:
Schaut euch mal Cleanroom Programming an. Da hat der Programmierer nichtmal nen Compiler zur Verfügung stehen und kann nur Code schreiben.
Naja das ist ein kleiner Teil des Cleanroommodells. Hauptsächlich baut es auf den mehr formalen Methoden der Softwaretechnik auf, und so arg wie das durchspezifiziert wird kann man dann auch den Code ohne Compiler schreiben, viel Unterschied macht das dann nicht mehr.
-
milka schrieb:
Gregor schrieb:
Aber mich würde mal interessieren, was das für eine Prüfung ist, bei der man mehr als Kleinkram programmieren muss. Was muss man da so programmieren? Und wieviel Zeit hast Du noch bis zum letzten Versuch?
Das problem beim prüfung ist- man muss auf einem stückchen papier programmieren-und da kannst du nicht testen ob es läuft und wenn nicht - was falsch sein kann.Jedes mal sind die aufgaben unterschiedlich-mal prekursive funktion schreiben, mal eine programm mit 1000 zeigern vorgegeben ist, und da muss man rausfinden was am ende rauskommt.Ich habe noch ca halbes jahr zeit
Ein halbes Jahr Zeit ist ja schonmal etwas gutes. Hätte ja auch sein können, dass Du eine Woche vor der Prüfung diesen Thread erstellst. Dieses halbe Jahr kannst Du gut nutzen, um jede Menge zu programmieren. Wenn Zeiger ein Problem für Dich darstellen, dann solltest Du in der Zeit halt einiges programmieren, was mit Zeigern arbeitet. Ähnliches gilt für rekursive Funktionen. Beides möglichst in der Sprache, die für die Prüfung relevant ist. Mach Dir wegen des Papier-Programmierens mal keine Panik. Eine IDE hat für solche kleinen Programme in erster Linie deshalb Vorteile, weil sie einen bei der Suche nach Syntaxfehlern unterstützt. Die werden aber vermutlich keine so große Relevanz bei den Programmieraufgaben in der Prüfung haben.
-
Was zum Teufel lernt Ihr da eigentlich im Fachgebiet Informatik? Programmierkenntnisse gehören doch einfach dazu oder etwa nicht? Mache das selbst, z.B mit ANSI-C, C++ und der Windows-Programmierung mit WinApi. Damit kannst Du immer etwas anfangen. Programmieren ist "Handwerkzeug" für jeden Informatiker genauso wie die "Maurerkelle" für eine Maurer. Musst Du schon können in einem späteren Job. Dort heisst es: "Sie sind der Fachmann - machen Sie mir mal schnell ein Programm". Du hast noch Zeit bis zum Ende Deines Studiums. Hier im Forum bist Du richtig aufgehoben!
-
Ich hab schon fälle gesehen, da haben sich "Informatik" Studenten quasi durchgemogelt wenns um praktische Progrmmierung ging. Threorie war keinm Probleme, aber zum coden hatten die kein Bock. Kann das auch nich verstehen.
Neulich habe ich mit mit dem Geschäftsfühere einer kleinen Softwareschmiede unterhalten, der meinte er habe frische Informatiker eingestellt und die konnten nicht progrmmieren, die wurden 2 monate in java eingelernt
P.S. Ich wars nicht, falls ihr euch wieder das Maul über mich zerreisen wollt:)
-
BorisDieKlinge schrieb:
P.S. Ich wars nicht, falls ihr euch wieder das Maul über mich zerreisen wollt
hättest du anstatt Java C gesagt, hätte ich das aber glauben können.
-
Du warst bestimmt auch mal anfänger/amateur in sachen C, wurdest du da auch von Profi's schikaniert?
-
BorisDieKlinge schrieb:
Du warst bestimmt auch mal anfänger/amateur in sachen C
natürlich...
BorisDieKlinge schrieb:
wurdest du da auch von Profi's schikaniert?
die 'foren-profis' schikanieren mich immer noch.
btw, trotz aller lästereien meinerseits: du bist mir trotzdem sehr sympathisch.
im unterschied zu vielen anderen hier, die einen ziemlichen stock im arsch haben, kommst du immer ziemlich offenherzig und authentisch rüber.
-
Gut das wollte ich hören;)
Obwohl du glaub mal "_fricky" warst...