Gesucht: Python-Aufgaben für Schul-Programmierkurs

[stem]

Hallo,

ich bin Lehrer und habe vor, einen Python-Programmierkurs anzubieten. Derzeit bin ich auf der Suche nach geeigneten Aufgaben oder Projekten. Hat jemand Tipps für mich zur "Didaktik" von Python?


Danke und viele Grüße

stem

[numerix]

Das sind zu wenig Informationen - du müsstest die Zielgruppe und das Ziel genauer spezifizieren.
Evtl. wäre das dann ein möglicher Zugang: http://ada.rg16.asn-wien.ac.at/~python/index.html

[Nebelhom]

Falls dich Englisch nicht stoert, ich habe mit dem Buch "How to Think like Computer Scientist" angefangen. Das wurde extra fuer den Schulunterricht geschrieben (jedoch fuer USA) und hat deshalb auch regelmaessig Uebungsaufgaben am Ende eines Absatzes oder Kapitels. Kannst dir ja im Preface anschauen, was die Philosophie des Buches ist und entscheiden, ob es etwas fuer dich ist. Vielleicht geistert auch irgendwo im Netz eine deutsche Version herum.

Mir hat es auf jeden Fall Spass gemacht, mich da durch zu arbeiten.

Edit: Das Buch behandelt Python 2.x. Falls du 3.x benutzen willst, dann ist es wohl nur geeignet, wenn du es anpasst.

[cofi]

Falls dich Englisch nicht stoert, ich habe mit dem Buch "How to Think like Computer Scientist" angefangen.

Das gibt es auch in deutsch: http://ada.rg16.asn-wien.ac.at/~python/how2think/

Ansonsten halt ichs mit numerix: Das ist abhaengig von dem Alter/Vorwissen der Schueler und um richtig helfen zu koennen muessen wir das kennen.

[problembär]

Zu "Python in der Schule" wurde hier neulich mal 'ne besonders schöne Seite genannt:

http://www.inf-schule.de
http://www.inf-schule.de/informatik/lis ... ?version=0

Ich persönlich bin eigentlich ganz froh, daß ich mir erstmal ein bißchen C und Perl beigebracht hatte, bevor ich zu Python gekommen bin. Ich finde es eigentlich ganz gut, wenn man erstmal diese Syntax mit ";" und "{}" kennt, z.B.

Code: Alles auswählen

#include <stdio.h>
int main(void)
{
    printf("%s\n", "Hallo Welt");
    return 0;
}

bevor man die in Python wieder ablegt. Und daß man sieht, wie anstrengend Programmieren in C ist. Aber gut, ich war ja auch kein Teenager mehr, als ich mich da herangewagt habe, und in ein paar Unterrichtsstunden kann man sicher nicht alles haben.

HTH

[Nebelhom]

@problembär: Das "Problem" kenne ich. Ich habe mit Python angefangen und jedes mal, wenn ich mich an etwas anderem versuche, merke ich wie "laestig" doch diese ganzen ";" sind. Ich kann schon gar nicht mehr zaehlen wie oft ich aus gewohnheit einfach enter gedrueckt habe anstatt da noch einen ; hinzusetzen

[snafu]

@problembär: Dein C-Beispiel finde ich jetzt aber etwas unglücklich. Den Newline-Character würde ich doch eher in den Formatierungsstring setzen. Außerdem sei erwähnt, dass für solche Fälle auch `puts()` funktioniert, welches nur einen String erwartet und diesen mit angefügtem `\n` ausgibt.

[problembär]

@problembär: Dein C-Beispiel finde ich jetzt aber etwas unglücklich. Den Newline-Character würde ich doch eher in den Formatierungsstring setzen.

Ok, korrigiert. Hab's halt schon 'ne Weile nicht mehr gemacht.

Außerdem sei erwähnt, dass für solche Fälle auch `puts()` funktioniert, welches nur einen String erwartet und diesen mit angefügtem `\n` ausgibt.

Ja, das weiß ich. Ich hatte absichtlich "printf()" genommen, weil ich damit das mit dem "\n" zeigen wollte, das die Schüler, die nur Python gezeigt bekommen, dann ja gar nicht kennenlernen, obwohl man das wissen sollte.
Und die Sache mit dem Formatierungsstring auch. Den kann man ja auch in Python gebrauchen, versteht mit C's "printf()" aber besser, wo der eigentlich herkommt.
Mein C-Code ist sicher (fast) nie perfekt, wie gesagt ist C für mich recht schmerzhaft. Das heißt, es erfordert sehr viel Zeit und Aufwand, bis der Code einigermaßen brauchbar wird. Nicht, daß das für mich ganz unmöglich wäre. Aber es dauert eben (viel zu) lange. Gerade deshalb weiß ich dann Python umso mehr zu schätzen. Es fühlt sich dann fast an, als könnte man fliegen, so schnell schreibt sich der Code.

Gruß

[snafu]

Naja, Pythons `print`-Statement ähnelt in seinen Grundzügen IMHO eher `puts()` als `printf()`. Letzteres kommt ja von seiner Art her nur dann zur Anwendung, wenn man String-Formatting benutzen möchte. Und dies muss man bekanntlich gesondert angeben. Später mit `print()` als Funktion verschwimmt das Ganze ein bißchen. Aber Python versucht da ja eh nicht, C zu imitieren - und das ist auch gut so.

Achso, und ich finde nicht, dass C einen sozusagen zwingt, `printf()` zu benutzen, wenn man eigentlich `puts()` möchte. `puts()` ist vielleicht unter Anfängern nicht ganz so bekannt wie `printf()`, aber das ist IMHO ein komisches Argument, falls man sowas hinsichtlich eines Vergleichs zeigen möchte, um zu belegen, dass Python einfacher als C ist. Da gibt es genügend andere Punkte, die Python besser machen.

Es fühlt sich dann fast an, als könnte man fliegen, so schnell schreibt sich der Code.

http://xkcd.com/353/

[tjuXx]

Ich finde Turtle immer sehr schön, da man mit geringen Kenntnissen einen grafischen Output bekommt und am Ergebnis direkt sehen kann ob die Berechnung richtig ist.
Man kann ein paar geometrische Berechnungen und Benutzerabfragen vorschalten und das Ergebnis dann zeichnen lassen. (z.B. Haus vom Nikolaus)

[stem]

Danke für die Antworten.

Die Schüler werden vermutlich 13 Jahre und älter sein (relativ bunt gemischt).

[HerrHagen]

Ich finde Turtle immer sehr schön, da man mit geringen Kenntnissen einen grafischen Output bekommt und am Ergebnis direkt sehen kann ob die Berechnung richtig ist.

Ich kann mich noch erinnern, dass wir im Informatik-Unterricht mit turtle Grafiken gearbeitet haben. Ich fand es furchtbar. Furchtbar langweilig... Da fehlte doch einfach jede Motivation. Was interessiert sich ein Schüler in dem Alter dafür, das Haus vom Nikolaus zu zeichnen? Motivation ist das Hauptproblem in dem Alter. Wenn die gegeben ist sind Schüler IMHO auch zu viel größeren geistigen Sprüngen fähig.
Ich denke man sollte eine (möglichst) spannende "echte" Aufgabe lösen - auch wenn sich diese nicht so fein didaktisch herleiten lässt wie das bei Turtle Grafiken oder Fibonacci-Folgen der Fall ist.
Wie wärs bspw. mit einem Spiel programmieren? Z.B. etwas hieraus: http://www.atariarchives.org/basicgames/. Vielleicht auch ein Kartenspiel wie Poker (in einer abgespeckten Form)? Auch interessant ist Daten zu analysieren. Vor kurzen sind ja die Passwort-Daten vom Sony-Hack im Netz aufgetaucht. Da könnte man z.B. analysieren wie viele Leute das Passwort 123456 verwenden; oder das gleich Passwort haben, etc. Bei so einer anrüchigen Aufgabe sind auch sicherlich alle sehr schnell aufmerksam...

MFG HerrHagen

[lunar]

@HerrHagen: Poker zu implementieren ist für Schüler dieser Altersstufe ohne jegliche Vorkenntnisse schlicht unmöglich. Nicht nur deswegen, weil Schüler dieser Altersstufe überhaupt kein Begriff vom Programmieren haben, sondern vor allem, weil selbst algorithmisches Denken, also die Fähigkeit, Problembeschreibungen mit einem Algorithmus zu lösen und diesen Algorithmus streng formal zu notieren, vollkommen fehlt.

Die Motivation hält sich folglich nur anfänglich, die Schüler sind schnell überfordert und mithin auch ziemlich schnell wieder demotiviert.

@stem: Schülern in diesem Alter muss Du wahrscheinlich erst einmal eben dieses algorithmische Denken vermitteln, bevor Du sie auf komplexere Programmieraufgaben wie Poker loslassen kannst. Ich glaube nicht, dass ein Python-Programmierkurs dazu geeignet ist. Eine „vollwertige“ Sprache hat zu viel „Drumherum“, was vom Algorithmus ablenkt, aber trotzdem zwingend erklärt werden muss (e.g. Bedienung des Editors, Start des Interpreters, Ein- und Ausgabe in einem Programm).

Eine „Spielzeugsprache“ wie Robot Karol, die eine geschlossene Umgebung mit einer eingeschränkten Sprache und unmittelbarer Visualisierung des Algorithmus bietet, ist wahrscheinlich geeigneter. Damit kann man mit einfachen Programmen beginnen, deren Ablauf die Schüler unmittelbar visuell verfolgen können. Das erleichtert sowohl den Einstieg als auch das Verständis. Nichtsdestotrotz kann man mit dieser Sprache auch verhältnismäßig komplexe Probleme lösen, wie beispielsweise das schriftliche Addieren von Zahlen, was für Schüler dieser Altersstufe ohne Vorkenntnisse schon eine ziemliche Herausforderung darstellt.

Vollwertige Programmiersprachen würde ich persönlich nur älteren Schülern zumuten, die bereits „höhere“ Mathematik in der Oberstufe hatten, und damit auch ein gewisses, rudimentäres Abstraktionsvermögen haben.

[HerrHagen]

@lunar: Das halte ich für schlicht falsch. Ich hab mit 6 Jahren mit Programmieren angefangen. Da hab ich auch noch keine höhere Mathematik beherrscht. Für ein einfaches Textadventures braucht man die auch nicht. So kompliziert ist das Programmieren ja nicht. Der Computer tut ja schließlich nur genau das was man ihm sagt.
Lehrsprachen halte ich für ziemlichen Blödsinn. Das ist wie wenn du Gitarre lernen willst und in der Musikschule nur Hänschen Klein spielst. Klar, das ist auch ein Lied. Es lässt sich sicherlich leichter spielen als *hier coole Band einsetzen*. Aber es ist einfach nur demotivierend. Und nach 3 Unterrichtseinheiten bleibt die Gitarre dann einfach liegen. Schüler in dem Alter haben selten Probleme zu verstehen weil sie nicht können. Meist haben sie einfach keine Lust zu verstehen.
Klar wird man kein vollwertiges Poker am ersten Tag hinbekommen. Aber eine vereinfachte Variante als Ziel für das Jahresende ist sicher drin. Da hat man was worauf man hinarbeiten kann. Dann ergeben auch die didaktischen Zwischenschritte einen Sinn und man fragt sich nicht ständig: Wozu mach ich das überhaupt???
Noch eine Frage: hast du das Programmieren mit Robot Karol gelernt? Kennst du irgendjemand der es damit gelernt hat (und sich dann auch gesteigert hat)? Ich nicht...

[nezzcarth]

Na ja, bei uns hieß Karol Niki (und für Python wohl Guido van Robot) und das war soweit ich weiß recht verbreitet an Schulen, wurde u.a. auch vom Klett Verlag propagiert. Keiner, der nicht vorher schon programmieren konnte, hat damit was gelernt. Könnte aber auch am Lehrer gelegen haben.

[lunar]

@HerrHagen: Ich habe nicht von höherer Mathematik gesprochen, sondern von Abstraktionsvermögen (was normalerweise vor allem durch Mathematik geprägt wird). Und ich glaube, dass diese Abstraktionsvermögen essentiell ist, und gelehrt werden muss, bevor man eine konkrete Sprache sinnvoll lehren kann, insbesondere, wenn man nicht allzu viel Zeit hat (der OP spricht wohl von einem Wahlkurs, also einer oder zwei Wochenstunden).

Warum ich das glaube? Erfahrung. Ich habe Informatik-Unterricht an meiner Schule erlebt, in dem jeder, der nicht schon Programmieren könnte, daran gescheitert ist, das Lösen quadratischer Gleichungen in Delphi zu implementieren, sprich eine Formel abzutippen. Ich habe selbst Kurse vor Informatik-Studenten gehalten, die daran verzweifelt sind, zwei Daten in Java zu addieren, ebenfalls keine sonderlich komplexe Aufgabe. Programmieren ist offenbar doch ziemlich komplex für jemanden, der keine Ahnung hat.

Insofern halte ich es für wahrscheinlich, dass 13-Jährige, die keinerlei Vorkenntnisse haben, und vielleicht nicht einmal sonderlich fundierte Computer-Kenntnisse besitzen, schon mit den ersten Schritten in Python (e.g. Interpreter starten und 2+2 eintippen) überfordert sind. Ich lasse mich gerne vom Gegenteil überzeugen, glaube aber nicht, dass dem Versuch dazu Erfolg beschieden sein wird, denn diejenigen, die mit sechs oder auch mit zehn Jahren einigermaßen vernünftig programmieren können, sind ebenso Ausnahmen wie diejenigen, die in diesem Alter bereits Wurzelrechnung beherrschen. Es gibt diese Ausnahmen, zweifelsohne, nur taugen sie nicht als Maßstab für „normale“ Menschen.

Es halt in der Tat so, dass Musikunterricht in Musikschulen meist eben doch mit Hänschen-Klein, und so hässlichen Grundlagen wie Notenlesen anfängt, weil auch die genialen Gitarrenspieler eine Rarität sind

[Hyperion]

Neben der Schwierigkeit der Abstraktion halte ich auch den (technischen) "Overhead" für wichtig, wie lunar es auch schon erwähnte. Man muss Python installieren und dann irgend wie zum Laufen bringen. Will man dann eigene Scripte zum Laufen bringen, muss man sich auch noch mit einer Commad-Shell auseinandersetzen (ja, idle existiert - aber es bringt imho viele Probleme mit sich, wie wir hier Woche für Woche sehen) und ggf. noch System-Variablen setzen usw. Auch wenn ein Compilier-Vorgang wie bei Java und Co wegfällt, so ist das imho immer noch verdammt viel Krams.

Einziger Ausweg wäre eine Live-CD mit vorkonfigurierter Oberfläche o.ä. Diese würde (theoretisch) zu Hause wie in der Schule identisch laufen. Ich habe einer Nachhilfeschülerin mal ein Knoppix in die Hand gegeben, damit sie einen einfachen Editor + Shell für das C-programmieren zur Hand hatte.

Als großen Vorteil würde ich bei einer universellen Sprache wie Python die Möglichkeiten sehen, Probleme aus dem Leben oder ggf. individuelle Interessen der Probanden aufzugreifen. Allerdings kann man dabei den Bogen schnell überspannen... insgesamt also keine einfache Entscheidung!

Ggf. spielt natürlich noch die zukünftige Perspektive eine Rolle: Wird Python evtl. später noch in der Schule verwendet? Dann wäre es u.U. doch sinnvoll einen steinigen Einstieg zu wählen.

[numerix]

In der Einschätzung der Fähigkeiten der genannten Altersgruppe im Hinblick auf Abstraktionsvermögen und insbesondere das Algorithmisieren einfachster Abläufe stimme ich lunar in vollem Umfang zu. Leider wird diese Position hier im Forum eher selten geäußert, was vermutlich daran liegt, dass die meisten, die sich dazu äußern zu denjenigen gehören, denen das algorithmische Denken leicht fällt und für die es eine reizvolle, angenehme Tätigkeit ist, eine Problemstellung zu Algorithmisieren und in einer Programmiersprache (vorzugsweise Python) zu implementieren. Das geht mir so und lunar vermutlich auch. Für einen typischen 13-14jährigen Schüler trifft das jedoch nicht zu.

Beispiel: Das Implementieren eines einfachen Zählers, der ermittelt, wie oft eine Schleife durchlaufen wurde, stellt für viele Schüler dieses Alters eine große Hürde dar, auch wenn die dafür benötigten Sprachelemente längst vertraut sind. Der Grund ist der, dass der "unvorbelastete" Mensch eben anders zählt als man es in einer imperativen Programmiersprache implementiert.
"Nimm einen leeren Eimer. Bei jedem Durchlauf kippe den Eimer aus, füge einen weiteren Klotz mit dazu und stecke alles wieder in den Eimer hinein. Wenn die Schleife fertig ist, kippe den Eimer aus." Das ist überhaupt nicht offensichtlich und es gibt Schüler, die das niemals wirklich verstehen - sie können es zwar als typisches Programmierelement auswendig lernen und einsetzen, aber es bleibt immer irgendwie suspekt.

Was die speziellen Lernumgebungen (Niki, Karol etc.) angeht, bin ich allerdings eher skeptisch, was deren Tauglichkeit angeht. Abhängig vom Alter, der zur Verfügung stehenden Zeit und der Zielvorstellung bzw. -vorgabe mag das ein Weg sein. Andererseits ist gerade Python DIE Programmiersprache, mit der sich eine klassische Einführung in die Grundlagen des Programmierens gut bewältigen lässt.

Was HerrHagen zum (alten) turtle-Modul sagt, kann ich nachvollziehen. Bis Python 2.5 war das turtle-Modul wirklich nur zum Abgewöhnen. Seit Python 2.6 ist das vormalige xturtle Modul von Gregor Lingl (dem Verfasser von "Python für Kids") als turtle Modul in die Standard-Lib eingeflossen und damit lässt sich schon einiges anfangen. Das gleiche gilt auch für das frog-Modul, das in etwa vergleichbar ist. Beide Module sind m.E. durchaus geeignet, um damit eine Einführung in die Grundlagen der Programmierung mit Python zu gestalten.

@Hyperion: In der Tat ist allein schon die Installation(!) von Python für manchen Schüler eine Herausforderung und beim Editor/Shell/IDE tun sich schnell unlösbare Probleme auf. Hier ist IDLE unschlagbar gut (läuft out-of the Box, auf dem heimischen Windows-Rechner ebenso wie auf dem schulischen Linux-Rechner) und die immer wieder gerne wiederholte Behauptung, IDLE stecke voller Probleme und sei kaum brauchbar, ist in diesem Bereich in jedem Fall haltlos. Wer soweit gekommen ist, dass er die (sehr wenigen!, z.T. auch Plattform spezifischen) Probleme von IDLE zu spüren bekommt, der ist auch längst in der Lage, einen anderen Editor/Shell/IDE zu verwenden.

[pillmuncher]

Beispiel: Das Implementieren eines einfachen Zählers, der ermittelt, wie oft eine Schleife durchlaufen wurde, stellt für viele Schüler dieses Alters eine große Hürde dar, auch wenn die dafür benötigten Sprachelemente längst vertraut sind. Der Grund ist der, dass der "unvorbelastete" Mensch eben anders zählt als man es in einer imperativen Programmiersprache implementiert.
"Nimm einen leeren Eimer. Bei jedem Durchlauf kippe den Eimer aus, füge einen weiteren Klotz mit dazu und stecke alles wieder in den Eimer hinein. Wenn die Schleife fertig ist, kippe den Eimer aus." Das ist überhaupt nicht offensichtlich und es gibt Schüler, die das niemals wirklich verstehen - sie können es zwar als typisches Programmierelement auswendig lernen und einsetzen, aber es bleibt immer irgendwie suspekt.

Das wäre ein Argument für Lisp oder Prolog als erste Sprache. Da macht man das mittels Rekursion, "der einzig wahren Schleife" (sma).

Als ich das erste Mal vor dem QBasic Interpreter von DOS 5 selig gesessen bin und rauskriegen wollte, wie Programmieren geht, hab ich mit Ausdrücken wie X = X + 1 nicht wirklich was anfangen können, weil mir nicht klar werden wollte, wie es eine Zahl X geben soll, die gleich sie selbst plus eins ist. Auch, dass X + 1 = X in BASIC nicht dasselbe ist wie X = X + 1 fand ich verwirrend. Prozedurale Programmiersprachen sind eben mehr oder weniger hohe Abstraktionen von Computern mit veränderlichen Speicherzellen, während deklarative Sprachen ausführbare Mathematik oder Logik sind. Letzteres liegt zumindest mir viel mehr, und das, obwohl ich in der Schule ziemlich schlecht in Mathe war. Jetzt, wo ich erwachsen bin, und Programmierer, kann ich das ungestraft auf meine Lehrer schieben.

Apropos Lehrer. Ich kann mich gut erinnern, wie mein Mathe-Lehrer Variablen erklärt hat, "das sind veränderliche Zahlen". Was soll das sein, eine veränderliche Zahl? Ist das eine 17, die manchmal auch eine 23 oder ein 749 ist? Der Witz ist: in der Mathematik sind Variablen überhaupt keine Zahlen, sondern Platzhalter für bestimmte Terme in anderen Termen. Es gibt Regeln für den Umgang mit solchen Platzhaltern und Termen, und das Funktionieren dieser Regeln hängt geradezu davon ab, dass Zahlen selbst unveränderlich sind. Currying und der ganze Lambda-Kalkül hängen daran, dass Variablen Platzhalter für Terme sind, und dass eine zwei nicht manchmal auch eine drei ist. Auch, was mathematische Funktionen sind, ist mir erst völlig klar geworden, nachdem ich Freges "Funktion, Begriff, Bedeutung" und "Die Grundlagen der Arithmetik" gelesen hatte. Ich finde das bemerkenswert, dass ich in der Schule das Rechnen mit Formeln gelernt habe (eher schlecht als recht), ohne dass mir beigebracht wurde, was die Grundlagen dieses Rechnens überhaupt sind. Ich habe diejenigen meiner Freunde befragt, die in der Schule Mathe-Cracks waren, ob sie mir erklären können, was Zahlen, Variablen und Funktionen sind, und alle konnten mir bestenfalls eine operationale Erklärung liefern, also: "mit Funktionen kann man ... machen", statt: "Funktionen sind ...". Mit einem von ihnen, einem ziemlich schlauen Programmierer, hatte ich eine Diskussion über Intelligenztest. Mein Argument war, dass bei den typischen "was ist die nächste Zahl dieser Folge"-Fragen jede beliebige Zahl richtig ist, weil es zu jeder Zahlenfolge beliebig viele Funktionen gibt, die, angewendet auf die Folge der natürlichen Zahlen, ebendiese Zahlenfolge erzeugen. Ihn hat das nicht überzeugt, weil "du weißt ja gar nicht, ob das eine Funktion ist". Da war ich doch ratlos. Zahlenfolgen sind eindeutige Abbildungen von den Indices einer Folge auf deren Elemente, und eindeutige Abbildungen nennt man Funktionen. Offensichtlich hat die Frage, was mathematische Funktionen sind, weder in seinem Schulunterricht, noch in seinem Flugzeugbauerstudium, noch in seiner Karriere als (exzellenter) Software-Entwickler je eine Rolle gespielt. Genauso formale Logik. Die gab es in der Schule überhaupt nicht, ist aber IMO notwendig für die Software-Entwicklung. Dass "Wenn es regnet, dann ist die Straße nass" dasselbe bedeutet wie "wenn die Straße nicht nass ist, dann regnet es nicht" liegt daran, dass beide Sätze in Kontraposition zueinander stehen: (p -> q) = (~q -> ~p). Jeder Programmierer wendet solcherlei Gesetze tagtäglich an, aber die wenigsten haben sich je bewusst damit beschäftigt. Geschweige denn mit Lambda-Kalkül, Herbrand-Universum, konjunktiver Normalform (Prolog-Klauseln sind in konjunktiver Normalform), Skolemisierung, überhaupt Prädikaten-Logik. Im Informatik-Studium muss man sie wohl lernen, höre ich, aber keiner meiner Bekannten, die Informatik studiert haben, hat je etwas zB. von Existenz-Einsetzung mitbekommen. Oder der Begriff des Typs: Das ist ein Begriff der AFAIK zum ersten mal bei Russell und Whitehead in den principa mathematica aufgetaucht ist, wo er mehr Probleme gebracht hat, als er gelöst hat. Genauso wie in den Programmiersprachen. Es gibt, ebenfalls AFAIK, keine Programmiersprache außer Haskell und Lisp, die nicht ein kaputtes Typ-System hat. Pythons Typ-System ist nur sehr wenig kaputt (weil Variablen nicht typisiert sind), und unglaublich flexibel, was einer der Gründe dafür ist, dass ich Python so mag. Das Typ-System von Java fühlt sich für mich an wie ein Betonklotz am meinem Bein und ich mit curly braces gefesselt am Grunde der Isar. Das von C++ ist ein Irrgarten aus dem es kein Entrinnen gibt. Das von Haskell basiert auf dem typisierten Lambda-Kalkül, weswegen es eben auch nicht kaputt ist.

Während ich so schreibe, kommt mir die Vermutung, dass dieser längliche rant eigentlich auf etwas anderes, grundlegenderes, abzielt, was mich schon seit längerer Zeit wurmt. Die fehlenden analytischen Grundlagen in der Programmieren-als-Beruf-Ausbildung resultieren, so meine These, aus dem Verständnis heraus, dass Programmieren eine technische Beschäftigung ist. Wir sind Programmierer, wir sind Techniker, wir gehen mit Technik und Technologie um. Die Mathematik, die wir brauchen, ist Ingenieurs-Mathematik, Analysis++ und Statistik++. Alle fachlichen Probleme sind technische Probleme. Wir ziehen uns unseren Blaumann an und krempeln die Ärmel hoch. Wenn die Maschine irgendwo hakt, nehmen wir einen Hammer oder Schraubenzieher und werkeln dran rum bis sie wieder läuft. Da gibt es dann diejenigen, die keiner Schraube trauen, deren Gewinde sie nicht selbst geschnitten haben (Not-Invented-Here-Syndrom), oder am anderen Ende des Spektrums diejenigen, die nur mit standardisierten industriell gefertigten Werkzeugen arbeiten wollen (ASP.net, J2EE, ...). Alle 1,5 Jahre kommt eine neue Art von Werkzeugen, deren Verwendung wir lernen sollen, und der Programmierer wird immer mehr zum Bedien-Spezialisten neuester oder auch nicht ganz so neuer technologischer Werkzeuge. Die verwendete Sprache ist dabei bloß das Medium, in das man seine Gedanken kodiert, und zwar transformiert in den Kategorien der jeweiligen Technologie, von wo aus der Computer sie dann wieder dekodiert und schließlich ausführt. Sprache ist aber gar kein Medium. Wenn es ein Resultat der Analytischen Philosophie in hundert Jahren gegeben hat, dann das, dass Sprache kein Medium zur Gedanken-Übertragung ist, sei es an andere Menschen oder Computer. Ein gesprochener Satz ist nicht bloß eine Kodierung eines Gedankens in Schallwellen, den mein Gegenüber nach dem Hören wieder dekodiert, um an den Informationsgehalt zu gelangen. Die Sprache ist nicht in diesem Sinne transparent, sondern opaque. Ihre Ausdruck-Möglichkeiten bestimmen, wie wir denken, und was wir überhaupt sagen können. Beim Programmieren doch genauso: wir versuchen beständig unerhörte neue Dinge in die Welt zu setzen, aber die verwendete Programmiersprache bestimmt die Kategorien in denen wir denken und die Abstraktions-Ebenen, zu denen wir hinaufgelangen können. Je mächtiger und ausdruckstärker die Sprache, um so besser. Oft hilft einem die mächtigere Programmiersprache nicht mal. Mein letzter Gig war ein Python-Job, aber es war furchtbar. Man konnte jedem Code ansehen, wer ihn geschrieben hatte. Er schrie einen förmlich an "Java!", "Dephi!". Auch hier die - für mich absurde - Vorstellung, Programmieren sei immer die gleiche Tätigkeit, auf demselben Abstraktions-Niveau (lies: Arrays und for-Schleifen, jede Funktion ist eine Methode "weil das ist objektorientiert"), nur die Technologie variiert. Python ist aber kein Java mit weniger Klammern, sondern IMO eher ein Lisp mit weniger Klammern. Wenn man solch reiche Ausdrucks-Möglichkeiten hat wie in Python, dann ist man bescheuert, wenn man sie nicht ausnutzt, das endet sonst mEn. immer in Programmen von byzantinischer Formelhaftigkeit (AKA boiler plate code) und barocker Verschnörkelung, in der vier- bis zehnfachen Länge, die eigentlich nötig wären, dasselbe in idiomatischem Python elegant zu formulieren. Wenn man dann was sagt erntet man bloß komische Blicke. Weil es funktioniert ja. Der Computer tut ja, was er soll. Aber "Programs must be written for people to read, and only incidentally for machines to execute." - H. Abelson and G. Sussman (in 'The Structure and Interpretation of Computer Programs'). Wenn ein Programm schon aussieht, als wäre die Katze über die Tastatur gelaufen, dann will ich mich gar nicht mehr damit beschäftigen müssen (Mein Lieblings-Beispiel war eine Zeile, die außer der notwendigen Einrückung keine spaces enthielt, die aber trozdem 208 Zeichen breit war). In einer ausufernden Implementation die implementierten abstrakten Konzepte zu suchen, ist extrem mühselig. Warum sehe ich so wenige Programmierer, die, wie Paul Graham vorschlägt, bottom up immer neue Abstraktionen entwickeln, in denen sie dann ihr Programm formulieren? Ja, ich weiß, alle verwenden Klassen und virtuelle Methoden-Aufrufe, aber man könnte doch, gerade in Python, oft eine interne DSL bauen, mittels der sich dann eine bestimmte Problem-Klasse leicht beschreiben und lösen lässt. pyparsing wäre ein Beispiel. Was ich statt dessen zu sehen bekomme, ist ein minimales Basisklassengerüst als Framework, resultierend in Funktionen von mehreren hundert Zeilen Länge, weil alles Abstraktions-Vermögen top down gerichtet war und schon verbraucht wurde. Irgendwo muss man ja stehenbleiben, wenn man von oben nach unten designt, und alles, was noch weiter unten ist, sind eben besagte Arrays und for-Schleifen, und Variablen als Daten-Töpfchen zum zwischen- oder Endlagern von Ergebnissen.

Überhaupt top-down-Analysen: wenn wir als Programmierer ein Programm schreiben, dann analysieren wir zwar zuerst das praktische Problem, das durch das Programm gelöst werden soll, und dazu verfertigen wir eine wie auch immer geartete Beschreibung des Problems. Die Kunst besteht aber darin, eine kurze und elegante Beschreibung des Problems zu finden, die dann eine ebenso kurze und elegante Lösung nach sich zieht. Und zwar auf allen Ebenen. Die Mittel der Wahl dazu sind Abtraktion und Generalisierung. Meine These ist jedenfalls, dass die Kunst der Programmierung zunächst mal darin besteht, die richtigen Abstraktionen und Generalisierungen für jede Ebene zu finden. Wir sehen das Gegenteil doch täglich hier im Forum bei den Anfängern. Neben den typischen Problemen, dass sie die Standard Lib und die Syntax nicht kennen, sehen deren Programme aus wie Kraut und Rüben, weil sie nicht abstrahieren und aller Code sich auf genau einer Ebene bewegt, gerne auch mit GUI und multi threaded. Alles ist bis zum Erbrechen vollgestopft mit ad hoc if-Schleifen, und der Zustand des Programms ist verteilt auf unzählige globale Variablen, weil sie noch nicht gelernt haben, Zustand einzukapseln und ihn nur mittels - ggf. polymorpher - Operationen kontrolliert und unter Einhaltung notwendiger Invarianzen zu ändern, damit nachher wieder ein neuer konsistenter Zustand besteht. Die Zauberworte hier sind "Zustand" und "polymorph", womit eigentlich schon die ganze OO beschrieben wäre. Wo dabei welches Rädchen und Schräubchen hinkommt und auf welche Abstraktions-Ebene, das muss man lernen, aber das ist nichts, was einem Technologie oder Frameworks abnehmen könnten. Da komme ich nun doch wieder zum Ausgangspunkt zurück, dem Informatik-Unterricht. Ich fände es begrüßenswert, wenn man den Kindern in der Schule und in der Hochschule vermitteln könnte, dass der Kern der Programmierung nicht technisch ist, sondern analytisch, und wenn man ihnen geistige Werkzeuge an die Hand geben könnte, mit denen sie bessere Problem-Beschreibungen und a fortiori auch bessere Problem-Lösungen erzeugen können. Wie man das macht weiß ich allerdings auch nicht, da ich kein Didaktiker bin. Aber Python als erste Programmiersprache ist schon mal ein guter Anfang.

[lunar]

@pillmuncher: Das Gymnasium ist keine spezielle Vorbereitung auf ein Informatik- oder Mathematik-Studium, sondern auf die allgemeine Hochschulereife. Da diejenigen, die nicht Informatik oder Mathematik studieren, später eigentlich nur rechnen müssen, legt das Gymnasium folglich auch nur die Grundlagen zum Rechnen, im Bezug auf Funktionen eben Differential- und Integralrechnung. Philosophie- oder Chemie-Studenten, ja nicht einmal Programmierer, brauchen zum Leben und Arbeiten nun mal weder formale Logik noch eine genaue Vorstellung vom Funktionsbegriff ...

Im Informatikstudium zumindest werden diese Grundlagen aber normalerweise schon im ersten Semester gelehrt. Kenntnisse vom Lambda-Kalkül, die über grundlgende Vorstellung von Berechenbarkeit und Entscheidbarkeit hinausgehen, zähle ich allerdings nicht zu den Grundlagen. So interessant die Beschäftigung mit dem Lambda-Kalkül auch ist, man muss akzeptieren, dass dessen unmittelbare praktische Relevanz für die meisten Programmierer gegen null konveriert.

Haskells Typsystem ist auch nicht der Weisheit letzter Schluss, weil es komplexer ist als das einfach typisierte Lambda-Kalkül. In der Praxis schlägt sich das beispielsweise in allerlei Problemen mit Typklassen nieder. LISP ist auch nicht perfekt, unter anderem auch deswegen, weil sich damit wirklich jeder seine eigene DSL für sein Problem zimmert, und dabei soweit abstrahiert, dass die Lösung hinter all der Abstraktion oft genug überhaupt nicht mehr zu erkennen ist. In Python oder Haskell käme niemand auf die Idee, die Fakultät über Church-Numerale zu implementieren, weil damit so schick von konkreten Zahlen abstrahieren kann, und nur noch Funktionen braucht. In LISP aber scheint derlei geradezu Qualitätsmerkmal eines guten Programmierers zu sein, mit dem Resultat, dass es oftmals unmöglich ist, fremde Programme unmittelbar zu verstehen.