Zukunft des Programmierunterrichtes

[Christian Seiler]

Hallo,

Dieses heftige Veto kann ich nun überhaupt nicht nachvollziehen. Ich bin sicher, Tom hat nicht gemeint, dass der Einblick in die Elementarteilchen der EDV die Fähigkeiten zu abstraktem und algorithmischem Denken ersetzen soll, sondern ihr nur eine Basis und ein Gegengewicht geben soll.

Tom sagte, man sollte mit Assembler auf einem Real-Mode-System _anfangen_ (Du hast es selbst noch einmal zitiert). Und das halte ich für einen sehr, sehr großen Fehler. 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. Aber als Anfang ist es IMHO absolut ungeeignet.

In Assembler gibt es keinerlei (!) abstrakten Konstrukte, es gibt (vereinfacht gesagt) nur Sprünge und elementare Rechenoperationen. Da wird das Abstraktionsvermögen überhaupt nicht geschult, ...

Oh doch. Zum Beispiel das Abstraktionsvermögen in dem Sinn, dass man eine bestimmte Datenstruktur je nach Kontext ganz unterschiedlich interpretieren kann. Zum Beispiel das Abstraktionsvermögen, sich unter einer 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. Das geht auch mit so ziemlich jeder anderen Programmiersprache, sogar mit extrem abstrahierten Sprachen wie PHP (da gibt's halt pack()/unpack(), bei denen man mit Binärdarstellungen rumspielen kann).

Und auch der Real-Mode schlägt in die gleiche Kerbe: Kein Memory Management und damit kein virtueller Speicher und damit Speicheradressierung nur über feste Segmente, keine Trennung von Prozessen, etc. Wenn man Leuten erklärt, wie man für Real Mode programmiert, verhindert man auch hier wieder die Möglichkeit, Abstraktion zu lernen.

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, alle Betriebssysteme mit denen man heute auf Desktop/Server/Laptop/...-Rechnern arbeitet, nutzen den Protected Mode. Es gibt sogar Prozessorarchitekturen, die gar keinen Real Mode kennen, sondern gleich virtuellen Speicher etc. haben. Und die meisten Anwendungen werden aus Komplexitäts- und Portabilitätsgründen eben nicht mehr in Assembler geschrieben. Das heißt: Im realen Leben sind diese von Dir so bezeichneten "Stützräder" sowieso schon mit dabei, IMHO passt hier der Vergleich zwischen Fahrrad und Einrad besser. 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? Dafür schießt man sich mit anderen Dingen ins Knie, die man bei der Lernphase dann lange nicht mehr so gut beigebracht bekommen kann, weil man da viel zu beschäftigt mit den unwichtigen Segment-Adressierungs-Detail-Gedöns ist.

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. 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.

Und in meinen Augen ist Abstraktion VIEL VIEL wichtiger, als sich mit den Details irgend eines Prozessors rumschlagen zu müssen.

Ja, hier stimme ich unbedingt zu. Nur verstehe ich nicht, wie du der Programmierung in Assembler die Notwendigkeit der Abstraktion absprechen kannst.

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 sind alles erst einmal Hürden, die überwunden werden müssen, *BEVOR* man in Assembler anfangen kann, von Abstraktion zu reden. In Hochsprachen (objektorientiert oder nicht) hat man dagegen die "lästigen Dinge" schon wegabstrahiert, dass man sich beim Lernen gleich auf die erst einmal relevanten Dinge konzentrieren kann.

Zudem: In Assembler passiert intern viel "Mojo": Irgendwelche Flags werden von Instruktionen gesetzt oder ausgelesen, Register die nicht explizit angegeben werden werden teilweise implizit verwendet etc., was bei typischen Programmiersprachen in der Regel nicht der Fall ist. Wenn jemand programmieren lernt, ist es in meinen Augen sehr wichtig, dass er an einer Zeile ziemlich erkennt, was dort passiert und nicht erst überlegen muss, was der konkrete Befehl noch für "Nebenwirkungen" hat. In einer Sprache, in der man also while (i > 0) { ...; i--; } schreibt, ist ziemlich ersichtlich, was passiert. Wenn ich in Assembler einfach nur ein foo: ... ; LOOP foo habe, dann dürfte es einen Anfänger ziemlich verwirren, über was eigentlich geloopt wird und er müsste nachschlagen, dass das bei x86 eben ecx ist. Und das war nur ein Beispiel, es gibt noch mehr.

[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.]

Wenn ich prinzipiell weiß, wie ich einen Algorithmus in einer Programmiersprache umsetzen kann, dann kann ich auch eine beliebige andere Programmiersprache lernen und es dort genauso tun.

Genau. Notfalls sogar in Assembler. ;-)

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

Wenn man schon einigermaßen gut programmieren kann, dann spricht nichts dagegen, Assembler zu lernen, um die Interna mal kennen zu lernen, das halte ich auch für eine gute Idee (auch wenn ich nicht der Ansicht bin, dass man es machen *muss*). Aber damit anzufangen ist in meinen Augen ein riesengroßer Fehler.

Viele Grüße,
Christian