Wieviel LOC pro Tag?

auch ganz nett sind bugs, die abhängig von äußeren Faktoren wie der Prozessorlast auftreten, also beispielsweise ein deadlock, der nur dann auftritt, wenn die Prozessorlast im Augenblick hoch genug ist, daß der zweite Thread ein paar Millisekunden länger zur Initialisierung braucht, sodaß er das Stop-Signal vom ersten nicht mehr mitbekommt. Wenn es in 95% der Fälle klappt, könnte es 20 Starts dauern, um überhaupt einmal den Fehlerzustand herzustellen.

hustbaer

@großbuchstaben
95%? Also 5% Chance den Fehler zu erwischen? Bei nem Deadlock? Optimist!
Spannend wirds mal wenn du unter 1% kommst. Und das ist nicht schwer/keine Seltenheit. Gerne auch mal < 10^-6.

Mechanics

Xin schrieb:

Code runterkloppen macht sicherlich am meisten Spaß

Ah, ich weiß nicht. Ich schreib zwar gern neuen Code, aber irgendwelche komischen Bugs untersuchen macht mir auch sehr viel Spass. Ist bei mir so ähnlich wie bei dir, mittlerweile landen viele schwierige Bugs erstmal bei mir zum Untersuchen.
Ich bin da auch sehr hartnäckig und finde sogar Bugs, die keinen interessieren. Hatte z.B. einmal einen Absturz bei mir, den noch nie jemand gemeldet hatte und der sonst niemandem aufgefallen war. War auch nicht reproduzierbar. Ist also vielleicht insgesamt nur ein einziges mal aufgetreten. Hab mir den Code aber so lange angeschaut, bis ich einen Bug gefunden habe, der zu dem Absturz führen konnte. Das Timing Verhalten war aber echt extrem unwahrscheinlich.

Mechanics schrieb:

Xin schrieb:

Code runterkloppen macht sicherlich am meisten Spaß

Ah, ich weiß nicht. Ich schreib zwar gern neuen Code, aber irgendwelche komischen Bugs untersuchen macht mir auch sehr viel Spass. Ist bei mir so ähnlich wie bei dir, mittlerweile landen viele schwierige Bugs erstmal bei mir zum Untersuchen.
Ich bin da auch sehr hartnäckig und finde sogar Bugs, die keinen interessieren. Hatte z.B. einmal einen Absturz bei mir, den noch nie jemand gemeldet hatte und der sonst niemandem aufgefallen war. War auch nicht reproduzierbar. Ist also vielleicht insgesamt nur ein einziges mal aufgetreten. Hab mir den Code aber so lange angeschaut, bis ich einen Bug gefunden habe, der zu dem Absturz führen konnte. Das Timing Verhalten war aber echt extrem unwahrscheinlich.

so sehe ich das auch, manchmal ist es auch mit einem enormen wissenszuwachs verbunden, solche fehler überhaupt erst einmal zu identifizieren...

aber wenn man einen solchen fehler gemacht hat und verbessert hat dann kann ich das auch ...
wie auch microsoft ceo nadella sagte: ... (bin eig kein ms fan)
http://www.heise.de/newsticker/meldung/Nadella-an-der-TU-Berlin-Macht-Fehler-und-lernt-daraus-2452852.html

"Macht Fehler und lernt daraus"

desweitern denke ich das man eine programmierer lieber daran festmachen sollte wie viele(oder wenig...) fehler er produziert...
weil mir bringen 50 zeilen code am tag nix... wenn der programmierer daran nochmal 4 tage bug fixing betreibt...
dann doch lieber gleich richtig und etwas weniger neu gecodet...

MfG schrieb:

desweitern denke ich das man eine programmierer lieber daran festmachen sollte wie viele(oder wenig...) fehler er produziert...

Sag ich doch.

Xin

Mechanics schrieb:

Xin schrieb:

Code runterkloppen macht sicherlich am meisten Spaß

Ah, ich weiß nicht. Ich schreib zwar gern neuen Code, aber irgendwelche komischen Bugs untersuchen macht mir auch sehr viel Spass. Ist bei mir so ähnlich wie bei dir, mittlerweile landen viele schwierige Bugs erstmal bei mir zum Untersuchen.

Ich mache meine Bugs aber lieber selbst. Darin bin ich aber schlecht, wenn ich im Jahr zwei Bugs bekomme, die ich selbst verschuldet habe, ist das viel. Die meisten Bugs, die ich "verschuldet" habe, bekomme ich deswegen, weil jemand ungefragt unfertige Software von mir abgreift und Features als fehlerhaft beschreibt, die ich noch gar nicht geschrieben habe. Da könnte ich auch 'nen Hals bekommen...

Debugging ist interessant und kann auch eine ganz neue Form von Kreativität bedeuten, aber ich muss auch klar sagen, dass ich den Job zur 3D-Visualisierung angenommen habe, weil ich mal wieder sehen wollte, was ich programmiere. Ich mache sonst Compilerbau und wenn Du zwei Wochen Zeit investiert hast, der Compiler fehlerfrei läuft und nichts meldet, dann ist das... ähh... ein tolles Erlebnis, aber

> gsys testprogramm.g
>

schaffen andere mit in wenigen Sekunden mit einem int main() {}. Du weißt, was da intern alles passiert ist, aber man kann es nicht mal jemandem zeigen, der keine Ahnung davon hat.

Ich war mal bei meinem neuem Chef und erklärte ihm, dass ich Low-Level-Programmierung mache. Danach musste ich ihn davon überzeugen, dass Low-Level nicht bedeutet, dass ich unfähig bin, weil auf geistig niedrigem Niveau arbeite, sondern eben die Grundlagen beschreibt auf dem alles andere aufbaut.
Das Problem hat unser GUI-Praktikant nicht. Der leistet ja was - sieht man doch, der macht viele tolle neue Dialoge, die man dem Kunden präsentieren kann.

Andere Programmierer lösen Probleme. Die Testbeispiele laufen, das sieht cool aus. Dann gibt's Applaus, dann kommen die Anwender, die ihre Probleme mit der Software lösen wollen. Dann haben wir einen Bug und der Entwickler gerade keine Zeit.
Wenn ich dann die halbverstandene, unkommentierte Lösung des anderen Entwickler nachvollziehe, dann das Problem des Kunden nachvollziehe und feststelle, dass das die Lösung leider nicht zum Problem passt, werfe ich diese weg und schreibe eine allgemein passende Lösung. Der erste Entwickler hat das Problem in 2 Tagen gelöst und ich habe einen kleinen Fehler in 2 Wochen behoben. In der Wirkung kann die Software jetzt nicht mehr als vorher, nur dass das Beispiel vom Kunden jetzt auch funktioniert und nicht nur die Testbeispiele.
Wenn man dann noch hört, dass die vorherige Lösung "aus dem Internet inspiriert" war, also auch nicht wirklich nachvollzogen wurde, sondern nur lauffähig gemacht wurde, dann nervt das schon etwas, weil der Kollege hat seine Show gehabt und ich habe ja nur einen kleinen Fehler für den Kunden behoben.

Debugging macht schon Spaß, aber gelegentlich will man auch sehen und zeigen, was man erschaffen hat. Und das funktioniert mit Debugging leider nicht.

Privat entwickle ich ja auch. Da habe keine Zeit zum Debuggen, entsprechend habe ich meine Herangehensweise optimiert, um Debuggen zu vermeiden. Und es ist einfach geiler, wenn man ein neues Feature sieht als wenn man für ein bereits verbuchtes Feature einen Bugfix macht.

MfG schrieb:

so sehe ich das auch, manchmal ist es auch mit einem enormen wissenszuwachs verbunden, solche fehler überhaupt erst einmal zu identifizieren...

Als ich C und C++-Tutor war, habe ich den Leuten immer wieder Aufgaben gegeben, bei denen sie mit Sicherheit in gemeine Fehler laufen und lies sie dann debuggen, Fragen stellen, nachvollziehen, was passiert und ihre Erwartungen zu formulieren und zu gucken, warum was passiert nicht ihren Erwartungen entspricht.

Ich habe den Leuten nicht beigebracht, wie man es richtig macht, sondern wie man es nicht falsch macht. Und dafür mussten sie es halt erstmal falsch machen, um dann zu lernen, warum das ihr Fehler nicht funktioniert.

Mit der Zeit fingen sie an, vor dem Tippen nachzudenken, wo sie in Fehler laufen können, denn irgendwann hatten sie raus, dass alle meine Aufgaben gemein sind. Da ich sie immer mit Ankündigung dumm dastehen lies, wollten sie mir ja zeigen, dass sie kleverer sind als meine Aufgabenstellungen. ^^

Xin schrieb:

Privat entwickle ich ja auch. Da habe keine Zeit zum Debuggen, entsprechend habe ich meine Herangehensweise optimiert, um Debuggen zu vermeiden.

Kannst du das etwas geneuer ausführen, wie kann man denn aufs Debuggen verzichten?

Xin

Loading schrieb:

Xin schrieb:

Privat entwickle ich ja auch. Da habe keine Zeit zum Debuggen, entsprechend habe ich meine Herangehensweise optimiert, um Debuggen zu vermeiden.

Kannst du das etwas geneuer ausführen, wie kann man denn aufs Debuggen verzichten?

Vermeiden, nicht verzichten - soweit bin ich dann doch noch nicht.

Debuggen vermeiden bedeutet Fehler vermeiden.
Und Fehler vermeiden bedeutet die Sprache voll auszunutzen: Const-Correctness, Templates, Mehrfachvererbung, viele bezeichnende Datentypen. Auch mal Zeit investieren, um einen neuen Datentyp (z.B. class Position) aus einem alten (unsigned int Position) herauszuholen, wenn man ihn häufiger braucht, statt hier und da ein paar ints reinzustreuen.
Und nachdenken, bevor man was tippt. Oder das tippen eben sein lassen, wenn man merkt, dass man nur Matsch in der Birne hat und in der Zeit halt eher Quelltext aufräumen und kommentieren, statt Fehler einbauen. Oder Tests schreiben. Jedenfalls nichts komplexes tun, was noch komplexer zu debuggen ist, falls es schief geht.

Es geht vorrangig darum, nicht den richtigen Zeitpunkt für eine Aufgabe zu verpassen, bzw. umgekehrt eine Aufgabe nicht zum falschen Zeitpunkt zu beginnen.

Gregor

Xin schrieb:

Und Fehler vermeiden bedeutet die Sprache voll auszunutzen

Unter Umständen kann es aber auch bedeuten, bewusst auf bestimmte Sprachmittel und Herangehensweisen, zu denen eine Sprache einlädt, zu verzichten.

volkard

Xin

volkard schrieb:

Loading schrieb:

Xin schrieb:

Privat entwickle ich ja auch. Da habe keine Zeit zum Debuggen, entsprechend habe ich meine Herangehensweise optimiert, um Debuggen zu vermeiden.

Kannst du das etwas geneuer ausführen, wie kann man denn aufs Debuggen verzichten?

Naja…

(Achtung, ich schweife persönlich ab. Bitte nicht lesen, wenn Dir die Zeit kostbar ist.)
...
Klar hatte ich damit Phasen, wo ich 8 Wochen Vollzeit nach einem Fehler suchte.

Am Anfang dachte ich, hier kommt etwas Interessantes, aber das wird ja wohl ein Frontalangriff.

volkard schrieb:

Wenn ein Vollprofi erreichbar war, frugte ich ihn und er sagte "schau mal nach malloc und ob die Zeilen drunter echt passen" und pardauz, er hatte recht! Die Halbprofis aber haben immer nur zurückgefragt "Was willste denn machen?" und so. Aber arschgeleckt, ich kann ihnen doch nicht meine genialen nobellpreiswürdigen Plan verraten. Wie lockt man Vollprofis in sein Fänge, die einem längst nicht mehr helfen wollen? Zur Not organisiert man eine Party und wenn er schonmal da ist…
Er schaut sich den Ausdruck an, er sagt das bekannte "schau mal nach malloc und ob die Zeilen drunter echt passen" und pardauz, er hatte recht!

Sorry, der Fehler hatte nichts mit malloc zu tun.

volkard schrieb:

Das Debuggen ist mit MSVC eine Wonne! Als der MSVC6 rauskam, hing ich nur am Debugger.

Ich habe mich MSVC 6 immer verweigert bis 2012. Da musste ich ein Programm von MSVC6 nach 2010 portieren.

volkard schrieb:

Das mache ich kaum noch, hab Jahre ohne quasi Debugger gelebt. MinGW unter Win und der Debugger GDB lief nur als Admin oder so. Bei arger Verwirrung mal Codefragmente im MSVC debugt.

gdb läuft auch unter meinem Account, ich programmiere privat hauptsächlich unter Linux, nutze aber tatsächlich gelegentlich aber auch MSVC zum Debuggen.

volkard schrieb:

C++ ist total der Hammer, was es angeht, den Compiler dazu zu bringen, Leichtsinnsfehler zu Compilerfehlern zu machen!

Unter MSVC gibt's genug Compilerfehler, bevor man Leichtsinnig sein kann
Dann steht da aber auch "Interner Fehler" oder das Studio fliegt einem gleich um die Ohren. Das müssen Leichtsinnsfehler sein.

volkard schrieb:

Vielleicht auch die Tatsache, daß ich trotz viel~(mehr als viel, aber gibt keine Worte, die das ausdrücken)~ Computerbegeisterung keinen 64-er bekam, aber die meisten Freunde einen hatten.

Ich habe meinen C64 drei Wochen nach meinem 10. Geburtstag gekauft, lange bevor Freunde einen Computer und auch vor den meisten Eltern.

volkard schrieb:

Hab daheim auf Papier programmiert

Stimmt. Der Assemblerkurs war auf der Rückseite mehrerer MagicDisk-64-Disketten und mangels Multitasking oder Multi-C64er konnte ich entweder lesen oder programmieren, aber nicht beides.
Also Papier, dann abtippen, dann testen. Und debuggen war damals nachdenken, wenn der Computer sich aufgehängt hat.
Das war später, als ich Asm auf dem Amiga schrieb nicht anders. Und das hat mir auch beigebracht, dass denken schneller als debuggen geht, weil man mit Denken Debuggen vermeiden kann.

volkard schrieb:

Nuja, den Debugger verwende ich derzeit auch nicht. Gelegentlich, wenn was nicht stimmt, eine Debug-Ausgabe (hab alle Makros und Klassen und templates dahingehend weggeworfen, zu selten benutzt) und dann sehe ich den Fehler.

Debugger benutze ich, aber tatsächlich reichen mir meistens ein paar printf.

volkard schrieb:

Sonstnochwas? Joo, ich bin ja auch in der Lehre unterwegs. Da fragt mich ein Seminarteilnehmer nach einem Fehler und ich springe hin. Ja, ich eile hin trotz meiner rundlichen Figur, anstatt am Pult zu bleiben und seinen Moni einzublenden, weil ich durch das freudige Anhüpfen auf Fehlersuche den Leuten ganz tief reingebe, daß sie mir voll einen Gefallen tun, wenn sie bei einem Problem nachfragen.

Ich bin nicht mehr Tutor. Ich habe es tatsächlich in die freie Wirtschaft geschafft.
Trotz meiner rundlichen Figur bin ich tatsächlich zu den Monitoren gegangen. Nicht nur, weil es keine Infrastruktur gab, um den Monitor bei mir einzublenden, zum anderen, weil es kein "bei mir" gab. Ich habe keinen Computer benutzt, sondern die Tafel.

volkard schrieb:

Dadurch habe ich auch bei denen einen Zugang, die zu höflich sind, mal nachzufragen. Und ich sehe den ganz kleinen Fehler im ansonsten richtigen Code aus 5m Entfernung, sage ihn und kullere zurück. Dann denken die, ich wäre schlau.

Teilweise musste ich nichtmal hinkullern, sondern kannte den Fehler ohne auf den Monitor zu sehen. Dann dachten die wirklich, ich wäre schlau.
Und nein, es war nicht malloc.

volkard schrieb:

Das ist hilfreich, dann nehmen sie meine Ratschläge für die Zukunft (kleine Funktionen bauen, Variablen lokal machen und so) auch eher an. In Wirklichkeit sind die Schüler vergleichsweise viel schlauer, ich hab den Fehler selber hundertmal und mehr gemacht, nur deswegen sehe ich ihn schnell.

Stimmt. Ich habe programmieren aus Fehlern gelernt. Ich programmiere seitdem ich 9 bin und der Bücherpreis war leider viele Jahre nicht taschengeldkompatibel und mein Vater sah in dem Spielzeug "Computer" keine Zukunft. Jedenfalls hat er mir nie ein Buch dazu gekauft und wenn ich Geld hatte, ging das für Hardware drauf.
Also habe ich Spaghetti-Code in Basic geschrieben, lange Funktionen in C benutzt und globale Variablen in so ziemlich jeder Sprache.
Und daraus gelernt.

volkard schrieb:

Zurück zum Thema. Popelcode kann ich fehlerfrei liefern. GUI-Klassen anwenden. Datenbankabfragen. *langweil*. Und so Sachen, die mir Spaß machen, Bäume, verkettete Ringe, verschiedene Hashtables, einfache Numerik, Bitgefummle…
Daß ich fast gar nicht debugge, liegt nicht daran, daß ich so schlau wäre, denn das bin ich gar nicht.

Hier liegst du auch richtig. Ich habe lediglich vieles schon oft gemacht und damit kenne ich die meisten Standardprobleme. Darum habe ich vielleicht auch nicht so die Probleme mit malloc.

volkard schrieb:

Ich bin höchstens ein wenig anders. Es liegt daran, daß meine Anforderungen stehengeblieben sind.

Das wiederum stimmt nicht. Denn viele Probleme benötigen viel Popelcode. Wirklich interessante Sachen sind nunmal kein Massenmarkt und in der Wirtschaft muss man was verkaufen.
Und auch im Low-Level-Bereich ist das Programmieren halt auch oft if und while und Funktionen, wo man lieber lokale als globale Variablen nimmt.

volkard schrieb:

Sorry, mir war danach. Danke der Tradition dieses Forums, daß man recht frei abschweifen darf.

Jow... Du hast mal wieder festgestellt, dass Du Mr. Allwissend bist und ich nichtmal ein Halbprofi. Wobei ich vermutlich einfach nur anders arbeite als Du. Im Prinzip weiß ich nichtmals ob Du überhaupt was machst - also außer rumzustänkern. Von daher... was interessiert mich, was Du feststellst?

Wenn Du was Interessantes oder Hilfreiches aus deiner Erfahrung gepostet hättest, was Dein Ego ein wenig begründen würde... ist mir bei Dir aber nicht nur in diesem Posting nicht wirklich aufgefallen. Kommt ja vielleicht noch...

@volkard, xin:
Ihr solltet mal ein Buch schreiben "C++ im Alltag" oder so. Bücher die den Syntax und die Standardlib + Tricks und Rezepte runter beten gibt es genug, aber Bücher die so kleine Projekte von A-Z mit allem drumherum und ein wenig Geschichte dazu erzählen gibt es meines Wissen gar nicht.

Noch eine Frage, wenn ihr kaum debuggt, dann macht ihr auch kaum logische Fehler?

Ich, als Anfänger, tappe von einem Fettnäpfchen ins nächste. Ich verbringe mehr Zeit auf Seiten wie StackOverflow, in Büchern, Tuts, Videos über C++, mit Notizen machen, als in der IDE selbst. Naja, mit 42 lernt man auch nicht mehr so leicht, wie damals ASM auf dem Amiga.

SeppJ

Citizen42 schrieb:

Noch eine Frage, wenn ihr kaum debuggt, dann macht ihr auch kaum logische Fehler?

Ja, die kleinen Fallen, in die man als Anfaenger oefters rein rennt, kennt man nach einer Weile alle. Ebenso kennt man gute, bewaehrte Loesungen fuer die ganzen kleinen Teilprobleme, denen man immer wieder mal begegnet. Selbst wenn man hier mal einen Fluechtigkeitsfehler macht, dann findet man ihn schnell auch ohne Debugger, weil man es schon so oft gemacht hat und die typischen Fehler und Symptome kennt. (Und auch sehr wichtig ist das, was volkard gesagt hat, dass man in C++ den Compiler sehr gut abrichten kann, Logikfehler zu entdecken. Das geht aber so ziemlich nur in C++ und kaum einer anderen Sprache. Ist einer der Gruende, warum ich die Sprache so mag. Kaum eine Chance fuer Fluechtigkeitsfehler^*)

Bei den grossen Problemen macht man hingegen keine Logikfehler, weil man da normalerweise nicht mit einer "mal ausprobieren ob das funktioniert"-Einstellung rangeht, sondern sich vorher genau ueberlegt, ob und wie das Problem zu loesen ist. Oder wenn man doch einfach drauf los programmiert (ich mache das gerne, weil ich eine Gefuehl dafuer habe, wie die Loesung aussieht und die Details beim Programmieren kommen) und in dabei in eine Sackgasse laeuft, dann braucht man auch keinen Debugger, da man ja gar nicht bei einem fehlerhaften Programm angekommen ist.

^*: Das geht aber auch nur, wenn man es richtig macht. C++ kan man auch sehr falsch benutzen und dann wird Fehlersuche schwer. Das sind dann die Leute, die sich hier im Forum beschweren, was das fuer eine dumme, primitive Sprache waere.

tntnet

Citizen42 schrieb:

Ich, als Anfänger, tappe von einem Fettnäpfchen ins nächste. Ich verbringe mehr Zeit auf Seiten wie StackOverflow, in Büchern, Tuts, Videos über C++, mit Notizen machen, als in der IDE selbst. Naja, mit 42 lernt man auch nicht mehr so leicht, wie damals ASM auf dem Amiga.

Das ist schon eine sehr gute Art, C++ zu lernen. Die Fettnäpfchen werden mit der Zeit immer weniger und man lernt, neue Fettnäpfchen zu analysieren und frühzeitig zu erkennen.

Ich kann SeppJ nur zustimmen, dass C++ einen sehr gut unterstützt, wenn man damit umgehen kann. Es gibt aber keine Abkürzung an den Fettnäpfchen vorbei. Also nur Mut. Es lohnt sich .

Das macht mir Mut, danke. Ich lerne mit dem Buch "Einführung in die Programmiersprache mit C++" von Bjarne Stroustrup und natürlich ganz viel vom selbst ausprobieren. Aber bis jetzt konnte ich jedes Problem mit Hilfe von Google lösen. Es ist ein enormer Vorteil solch eine Riesen-Community hinter einer Sprache zu haben und seien wir mal ehrlich, die meisten Programme, die wir so nutzen, sind doch in C++ geschrieben, oder? Und sobald es auf den Smartphones und Tablets mal etwas performant werden soll, dann wird ja wohl auch nur ausschließlich mit C++ und ObjC gearbeitet, aber das ist nur eine Vermutung von mir.

Und Java, es tut mir Leid das sagen zu müssen, ist in meinen Augen auch nicht die richtige Sprache um das Programmieren zu lernen, da eben viele Aspekte des Programmierens eines Computers vor dem Anwender versteckt werden. Zumal ich Java nach wie vor lahm finde. Ich habe mal ein paar Stunden mit dem neue SceneBuilder eine GUI zusammen geklickt und das Programm wurde nach neun Textfelder, ein paar Labels und Layoutmanager richtig langsam und das auf einem neuen i7-Desktop + dicker GPU!

Na gut, reden wir hier nicht über Java, für irgendwas wird das schon gut sein.

Gregor

Citizen42 schrieb:

Und Java, es tut mir Leid das sagen zu müssen, ist in meinen Augen auch nicht die richtige Sprache um das Programmieren zu lernen, da eben viele Aspekte des Programmierens eines Computers vor dem Anwender versteckt werden.

Ich weiss nicht, warum Du hier ploetzlich Java thematisierst, aber mit der Argumentation, die Du da zum Besten gibst, solltest Du das Programmieren mit Assembler lernen.

Das habe ich sogar früher mal auf dem Amiga und auch jetzt werde ich dahin gehend mal einige Versuche auf dem PC unternehmen. Aber eine Hochsprache ist da dann doch schon komfortabler und ich traue den Compilern auch schönen Maschinencode zu, aber zum reinen Verständnis ist Assembler wirklich toll, jedenfalls der auf dem 680000. Ich weiß nicht wie der x86 Assembler so ist, aber da werde ich mich auch noch mit beschäftigen.

Gregor

Citizen42 schrieb:

Das habe ich sogar früher mal auf dem Amiga und auch jetzt werde ich dahin gehend mal einige Versuche auf dem PC unternehmen. Aber eine Hochsprache ist da dann doch schon komfortabler und ich traue den Compilern auch schönen Maschinencode zu, aber zum reinen Verständnis ist Assembler wirklich toll, jedenfalls der auf dem 680000. Ich weiß nicht wie der x86 Assembler so ist, aber da werde ich mich auch noch mit beschäftigen.

Das war von mir nicht wirklich ernst gemeint. Natuerlich bist Du mit Assembler naeher an der eigentlichen Maschine dran, aber Programmieren hat nicht nur etwas mit einem Low-Level Verstaendnis eines Computers zu tun. Jenseits davon lernst Du das selbst mit Assembler nicht wirklich. Natuerlich lernst Du mit Assembler, was zum Beispiel Register sind, Aber mit Dingen wie Pipelining, der Speicherhierarchie und so weiter kriegst Du es auch nicht direkt zu tun. Wenn Du fuer Deine Programmiertaetigkeit ein solches Verstaendnis von Computern benoetigst, dann solltest Du neben dem Erlernen der Programmiersprache ein Buch wie zum Beispiel das da durcharbeiten:
Computer Architecture | ISBN: 012383872X

Danke für den Buchtipp. Benötigen tue ich solches Wissen nicht. Das ist wie früher beim Democoding(nix bekanntes) auf dem Amiga einfach nur Hobbykram. Assembler war halt die einzige Sprache, mit der ich wirklich was mit dem Computer machen konnte. C + Libs waren damals grottenlahm und Basic naja nochmal hundert Stufen lahmer. Mir ist schon klar, dass das heute alles anders ist mit Multicore, der Pipeline und den Caches. Damals war Assembler halt nichts besonderes. Das haben eigentlich alle programmiert und es wurden auch viele Bücher und Artikel in Zeitschriften darüber geschrieben. Internet gab es ja nicht, also musste man selbst die Fehler finden. Schwer war das damals überhaupt nicht, wenn man einmal den Dreh raus hatte. Waren ja auch nur sehr wenige Befehle mit sehr wenigen Fragezeichen. Man musste halt geschickt auf die Register aufteilen und den Rest auf den Stack packen. Die Customchips kennen und wissen wie man die ansteuert, musste man auch, aber so viele waren das ja auch nicht. Und das schöne daran, so gut wie jeder hatte dieselbe Hardware, es gab einfach nie irgendwelche Sonderfälle zu beachten.

Aber ich gerate schon wieder ins Schwärmen, wie einfach das alles damals war. Aber nun probieren ich es mal mit C++ und OOP, an das ich mich erst noch gewöhnen muss, es sind aber tolle Pattern dafür vorhanden, wirklich beeindruckend.

Also alles nur ein Versuch eines alten Mannes mal wieder etwas zu programmieren, mehr nicht, reines Hobby.

Citizen42 schrieb:

aber zum reinen Verständnis ist Assembler wirklich toll, jedenfalls der auf dem 680000.

und der auf dem 800386 erstmal