Ich kann nicht programmieren....
-
Manache glauben sogar, dass sie ne Programmieren klausur schafen, wenn man ihnen den Quellcode der letzten Klausr erkärt!?
Neulich kam einer an mit ner Übungsaufgabe Objekorientierung Polymorphy etc. Da meinte er ich solle ihm nur den Code erklären also was die Klassen machen und wie sie zusammen aggieren, und er können es dann programmieren:)
Die meinsten denken wenn sie einmal den Code erklärt bekommen und ihn auch verstehen, können sie sowas selber Programmieren (naja vll. gibts ja ausnahmen)
-
Tippgeber schrieb:
Übrigens: die ein Programmierer ist nur so talentiert wie weit seine Debug-Talente reichen...Wer gut im Debuggen ist hat es einfach leichter und das ist das Problem von vielen Anfängern: sie haben einen Fehler, aber können ihn unmöglich finden, da sie keine Ahnung haben was ein Debugger ist und wie man diesen einsetzt.
andererseits macht ein guter programmierer selten fehler, die man mit einem debugger suchen muss.
-
-fricky- schrieb:
Tippgeber schrieb:
Übrigens: die ein Programmierer ist nur so talentiert wie weit seine Debug-Talente reichen...Wer gut im Debuggen ist hat es einfach leichter und das ist das Problem von vielen Anfängern: sie haben einen Fehler, aber können ihn unmöglich finden, da sie keine Ahnung haben was ein Debugger ist und wie man diesen einsetzt.
andererseits macht ein guter programmierer selten fehler, die man mit einem debugger suchen muss.
Naja darüber kann man wohl streiten
-
-fricky- schrieb:
Tippgeber schrieb:
Übrigens: die ein Programmierer ist nur so talentiert wie weit seine Debug-Talente reichen...Wer gut im Debuggen ist hat es einfach leichter und das ist das Problem von vielen Anfängern: sie haben einen Fehler, aber können ihn unmöglich finden, da sie keine Ahnung haben was ein Debugger ist und wie man diesen einsetzt.
andererseits macht ein guter programmierer selten fehler, die man mit einem debugger suchen muss.
Wie sucht man dann die fehler von guten programmieren?
-
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
-
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. klar, wenn man nen 500 zeilen spaghetti-code hat, kann ich mir schon vorstellen dass ein debugger hilft, aber sowas kommt mir beim programmieren egtl nie vor.
ich bemühe mich drum programmabschnitte möglichst gut zu kapseln und klein zu halten, da ist mein gehirn dem debugger ebenbürtig.
wobei... vor 2 jahren als ich angefangen hab mich etwas intensiver mit c++ zu beschäftigen, benutze ich den um rauszufinden in welcher codezeile der code abstürzt. für mehr aber dann auch nicht.
-
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.