Zukunft des Programmierunterrichtes

[Der Martin]

Hallo Christian,

Tom sagte, man sollte mit Assembler auf einem Real-Mode-System _anfangen_ (Du hast es selbst noch einmal zitiert).

ja, das würde ich auch immer noch unterstützen. Aber offensichtlich hast du etwas anderes darunter verstanden als ich - du hast vergessen zu abstrahieren. ;-)

Dass man - nachdem man die Grundlagen der Programmierung an sich erarbeitet hat - etwas über die x86-Architektur an sich lernt (elementare Datentypen, Endianess, Systemarchitektur, ...) halte ich auch nicht für verkehrt.

Ja, einverstanden. Ich meinte das "Anfangen mit Assembler" aber viel allgemeiner und nicht auf eine konkrete Prozessorarchitektur bezogen. Sondern eher als Grundlagenkapitel:
 * Wie funktioniert eine CPU (Prinzip)
 * Wie funktioniert das Zusammenspiel von CPU, Speicher, I/O
 * Welche Arten von Instruktionen gibt es (Beispiele verschiedener CPUs)
 * Wie kann man den Programmfluss strukturieren (Subroutines, Sprünge, Bedingungen)
Diese Grundlagen sollte man dann mit ein paar einfachen(!) Beispielprogrammen festigen und ein bisschen damit rumspielen dürfen. Je nach Neigung des Lehrers auf x86, 68xxx oder 8051-Derivate bezogen. Damit ist das Thema "Assembler als Grundlage", so wie ich es gemeint habe, abgehakt. Ich meinte nicht, dass jeder Programmierer erstmal x86-Assembler bis zur Perfektion lernen solle.
Apropos x86-Assembler: Auf den *wirklich* alten, überschaubaren Systemen (CP/M zum Beispiel) hat man das Theater mit der Speichersegmentierung gar nicht, und selbst bei DOS im Real Mode werden die Segmentregister vom Betriebssystem so günstig mit Defaultwerten belegt, dass man sie als Programmierer erstmal ignorieren kann. Erst wenn man größere Programme schreiben will (oder mit Assembler-Teilen ergänzen), trifft einen das Thema überhaupt.

Zum Beispiel das Abstraktionsvermögen [...] Datenstruktur je nach Kontext ganz unterschiedlich interpretieren kann [...] Sequenz von Bytes im Speicher eine bestimmte Zahl, einen String, einen Fließkommawert oder gar eine komplexe Struktur vorzustellen.
Dazu braucht's aber kein Assembler.

Nein, nicht zwangsläufig. Aber bei den meisten Programmiersprachen, seien sie schwach (Javascript, PHP) oder stark typisiert (Pascal, C) drängt sich bei Anfängern immer die Assoziation mit einem bestimmten Datentyp auf. Da wird ein ASCII-Zeichen aus einer Speicherstelle gelesen, die durch eine Variable mit einem bestimmten Typ (z.B. char) referenziert wird, und dann dieses Zeichen in einer printf-Anweisung mit dem Format %u ausgegeben. Und dann kommt die Frage: "Das ist ja jetzt eine Zahl! Wo ist denn das umgewandelt worden?"
Diese Äquivalenz bzw. kontextabhängige Interpretation von Daten kommt meiner Ansicht nach in keiner "höheren" Programmiersprache so anschaulich rüber wie in Assembler.

Nein. Radfahren lernt man auch am besten ohne Stützräder.
Wieso Stützräder? Bis auf den Embedded-Bereich hat man heutzutage einfach keinen Real Mode mehr, ...

Aber gerade dieser Bereich wächst immer noch so rasch, dass man ihn bitte nicht unterschätzen oder für irrelevant halten sollte.

Wieso also Konzepte lernen, mit denen man sich während der Lernphase EXTREM ins Knie schießen kann, im praktischen Leben aber in der Form nicht mehr vorkommen?

Weil sie Grundlagenwissen schaffen, das der angehende Programmierer eben in vielen Bereichen *doch* wieder braucht.

Fehlende Sicherheitsvorkehrungen sind IMHO eine der besten Methoden, Disziplin zu lernen: Wenn ich etwas falsch gemacht habe, dann knallt's irgendwo.
Nein, es reicht völlig aus, das ein Lehrer bei Fehlern einfach streng ist. Das ist dann das "Knallen", das dem Schüler richtig weh tut.

Kommt auf den Lehrer an ... ;-)

Wenn der Computer abstürzt, startet er ihn einfach neu, genauso, wie er eine Meldung einfach wegklickt. Das mag zwar etwas lästig sein, richtig weh tut es dem Schüler aber auch nicht - was vmtl. auch daran liegt, dass Benutzer auf Abstürze konditioniert wurden.

Wurden sie? Zu denen gehöre ich nicht. Für mich hat ein Systemabsturz immer noch etwas Alarmierendes (jedenfalls seit Windows aus den Kinderschuhen rausgewachsen ist).

Ich sage ja nicht, dass man in Assembler nicht abstrahieren kann. Aber um überhaupt erst einmal etwas zum Laufen zu bringen, muss man sich mit Dingen rumschlagen wie "Welche Register bietet der *spezifische* Prozessor an? Welche Calling Conventions verwendet mein *spezifisches* Betriebssystem unter dieser *spezifischen* Architektur? Welche Systemaufrufe unter meinem Betriebssystem gibt es, um Sachen auszugeben?" Und im Real Mode dann noch so Speicheradressierungsscherze.

Das kommt drauf an, wie tief man in das Assembler-Kapitel wirklich einsteigen möchte. Ich dachte, wie gesagt, nie an das Beherrschen aus dem FF (oder dezimal 255), sondern ums Kennenlernen des Prinzips und der allgemeinen Arbeitsweise und Randbedingungen.

Zudem: In Assembler passiert intern viel "Mojo"

Für mich passiert in Javascript, PHP oder C++ viel mehr Voodoo, als du es in Assembler siehst (z.B. Speicherverwaltung, Typecasting). Deswegen mag ich C++ auch nicht so gern und wähle, wenn ich kann, lieber klassisches C.

[Auf die Gefahr hin, dass ich damit wieder ein Flamewar auf mich ziehe: Dies ist auch der Grund, warum ich Perl auch für Anfängerungeeignet halte, weil dort auch sehr viel durch "funky syntax" passiert, wie zum Beispiel die ganzen $@, $/, ...-Variablen.]

Das kann ich nur als Außenseiter kommentieren, aber für mich ist Perl-Quellcode auch ein Buch mit sieben Siegeln, aus dem ich oft nicht einmal erahnen kann, was da passieren soll.

Natürlich. Aber Assembler ist eine extrem schlechte Programmiersprache, um das Programmieren überhaupt zu lernen.

Um die *Grundlagen* zu lernen, meiner Ansicht nach nicht.

Schönen Abend noch,
 Martin