[linux-l] Geeks Traum [hier: Referenzsysteme]

[Volker Grabsch]

On Fri, Dec 28, 2007 at 01:42:33AM +0100, Thorsten Stöcker wrote:
> Am Donnerstag, 27. Dezember 2007 15:39 schrieb Volker Grabsch:
> >
> > Die Uni ist vielfälig. Natürlich wird in den Vorlesungen Wert auf
> > Zusammenhänge, Erklärungen, etc. gelegt. Wer das nicht drauf hat,
> > besteht niemals die mündlichen Prüfungen.
> 
> Das kann ich nicht beurteilen, ich weiß nur, daß das Denken in Zusammenhängen 
> nicht weit verbreitet ist, völlig unabhängig von Profession und Bildung.

Woher hast du dieses "Wissen"? Wahrscheinlich nicht aus einem
Informatik-Studium? Und ganz sicher nicht aus einem Mathe-Studium.

> > Aber es gibt eben auch Übungsaufgaben, in denen man mehr "handwerkliche"
> > Dinge lernen soll. Dazu gehört das Ausarbeiten von Diagrammen & Schemas,
> > dazu gehören kurze, präzise Erläuterungen (keine Labertexte). Und dazu
> > gehört auch Programmierung.
> 
> Programmierung ist lediglich die Umsetzung einer abstrakten menschlichen 
> Vorstellung in eine Sprache, die die Maschine versteht.

Die Sprache der Maschine ist einerseits detaillierter, was die
"Übersetzung" schwerer macht, und andererseits austestbar, was die
"Übersetzung" leichter macht, wenn man mit dem Computer zusammenarbeitet.

Zudem sind Programme i.d.R. komplex genug, um nicht komplett im
Gedächtnis bleiben zu können (abgesehen von den groben Konzepten).
Das heißt, auch bei der Organisation seines Programmes kann und muss
man sich vom Computer helfen lassen.

> > Obwohl ... wir hatten mal so eine Klausur im Grundstudium, wo eine der
> > Aufgaben darin bestand, auf dem Papier möglichst viele Syntaxfehler
> > in einem C-Programm zu finden. *Das* ist erstmal realitätsfern. 
> 
> Nein, das ist die von Dir definierte Praxis. Syntaxfehler sind mit Abstand die 
> häufigsten Fehler. Und ein Compilerlauf nur wegen Syntax-Fehlern zu 
> wiederholen ist schlicht unnötig und Zeitverschwendung.

Ein größeres Programm manuell nach Fehlern zu durchsuchen, solange, bis
auch der letzte Fehler gefunden ist - das ist eine viel größere Zeit-
verschwendung.

Davon abgesehen braucht ein Compilerlauf heutzutage höchstens 3 Sekunden,
solange nur das compiliert wird, was sich wirklich geändert hat.
(sprich: Makefile, JIT-Compiler und/oder Intepreter, also alles Stand
der Technik)

> > Dann doch lieber den Umgang 
> > mit Compiler-Fehlermeldungen und Debuggingtechniken lernen. 
> 
> Compilerfehlermeldungen??? Man, wieviele Generationen Compiler kennst Du und 
> wieviele davon produzieren bei Syntax-Fehlern aussagekräftige 
> Fehlermeldungen.

So war das nicht gemeint. Wenn er einem eine konkrete Zeile nennt,
sollte man Syntaxfehler schon auf den ersten Blick erkennen. Oder
schnell genug merken, an welcher anderen Stelle man suchen muss,
falls es in Wahrheit nur ein Folgefehler ist.

Aber ein bereits fehlerstrotzendes Programm geht man entweder
systematisch mit /Hilfe/ des Compilers durch, oder schreibt es
nochmal und /erlaubt/ erst gar kein Einschleichen solcher Fehler.
Aber ganz sicher sucht man nicht auf dem Papier systematisch nach
allen Syntaxfehlern. /Das/ ist nämlich Zeitverschwendung!

Wichtiger ist z.B., dass man inkrementelle Programmierung lernt.
Ein großes Stück Code aus dem Boden zu stanzen ist eine Garantie
für Fehler - syntaktische wie semantische.

Man sollte ein Programm in kleinen Stücken zu entwickeln, die
man ausprobiert, vllt. systematisch testet, und Stück für Stück
ausbaut. Bei heutigen Compiler- und Interpreter-Geschwindigkeiten
kein Problem mehr. So merkt man quasi beim Schreiben schon die
Fehler, rechtzeitig, und nicht erst später im Nachhinein.

Natürlich vorher ein grober Plan, klar. Und für komplizierte
Bestandteile erstmal Algorithmen entwerfen. Ändert aber nichts
daran, dass Programmierung mehr ist als bloße Übersetzung von
Algorithmen in eine andere Sprache. Man "übersetzt" nämlich
in eine detailliertere Sprache, deren Details man nicht auf
einem Blatt Papier überblicken kann. Wozu auch, wenn man was
viel besseres hat: Werkzeuge, die einem mit auf die Finger
schauen (und hauen), sowie die Möglichkeit, jederzeit testen
zu können.

Und genau solche Techniken müssen vermittelt werden: Wieviel
auf dem Papier, wieviel an (und mit Hilfe) der Maschine?

> > Programmieren 
> > tut man *mit* dem Computer, nicht gegen ihn.
> 
> Das hängt vom OS ab. Denn zwischen Dir und Deinem Computer oder Dir und Deiner 
> Programmiersprache und dem Computer sitzen ziemlich viele Stufen der 
> Übersetzung und alle diese Übersetzungen haben Menschen programmiert, die 
> Fehler machen. :-) 

Umso wichtiger, Fehler möglichst schnell zu finden, ergo: inkrementell
programmieren, *mit* dem Computer.

> Du programmierst weder mit noch gegen den Computer, Du programmierst den 
> Computer.

Der Computer kann dir helfen. Rechtzeitige Testläufe helfen, strenge
Compiler helfen.

> Einfaches Beispiel, ich habe mal jemanden aufgetragen (zu Erklärungszwecken), 
> ein Programm zu schreiben damit irgend eine beliebige Person ein Stück Butter 
> aus dem Kühlschrank in der Küche holt. In der endgültigen Version waren das 
> einige hundert Zeilen Code.
> 
> Ohne Compiler. Ohne Debugger.
> 
> Für die einfache Anweisung "Geh in die Küche und hole ein Stück Butter aus dem 
> Kühlschrank."

Ja, eine schöne Übung. Ich sage auch nichts gegen das Skizzieren von
Algorithmen! Das würde ich aber nicht wagen, "Programmierung" zu nennen.

Sicher, auch in der Uni skizzieren wir Algorithmen. Ob das wichtiger
ist als die Fähigkeit, sie auf einer echten Maschine zum Laufen zu
bringen, weiß ich nicht. An der Uni lernst du halt beides. Das eine
ohne das andere wäre Unsinn.

Wie ein Prof. mal so schön gesagt hat: "Je bessere Theoretiker ihr
werdet, umso bessere Praktiker werdet ihr sein." Ich würde noch
ergänzen, dass die Umkehrung genauso gilt.

> Und das ist meiner Meinung nach wichtiger, als zu wissen Code 220 bei MS-C# 
> heißt ich habe "}" zu vergessen oder ich muß in Procedure X einen Tracepoint 
> auf Variable Y setzen.

Meine Rede! Dafür ist der Compiler da. Sowas prüft man nicht per Hand!


Gruß,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR