Unterricht für Programmier-Anfänger*innen: Der Weg ist zweitrangig

Ich will dabei herausarbeiten, dass der Weg (sprich das „Wie“) in der Ausbildung zweitrangig ist. Viel bedeutender sind die Lehrenden mit ihren fachlichen und didaktischen Kompetenzen und die Tatsache, dass sie nach „ihren speziellen Lehrmethoden“ unterrichten dürfen.

Viele unterschiedliche Wege im Informatik-Unterricht

Fragen Sie 1.000 Informatik-Lehrer*innen, welches der richtige Weg im Informatik-Unterricht ist, erhalten Sie mit Sicherheit 1.000 verschiedene Antworten:

• Der erste Streitpunkt ist, mit welchem Programmierparadigma begonnen werden soll.
• Der zweite Streitpunkt (teilweise heftig geführt) ist die zu verwendende Programmiersprache.
• Der dritte Streitpunkt ist dann die Entwicklungsumgebung (IDE).
• Erst danach kommen methodische und andere Differenzen.

Ich glaube (ohne wissenschaftlichen Beleg), dass die Rangfolge bei den Programmierparadigmen beim Einstieg in die Programmierung wie folgt lautet:

1. Prozedural / Strukturiert / Imperativ
2. Objektorientiert
3. Funktional
4. Logisch

Dies bedeutet, dass noch sehr oft prozedural bzw. strukturiert eingestiegen und mit dem logischen Paradigma fast gar nicht begonnen wird. Dr. Sperber hat z.B. in seinem Beitrag ein Plädoyer für den Einstieg mit einem funktionalen Paradigma gehalten (zur Erinnerung: eine von 1.000 Meinungen).

Bei den Programmiersprachen ist die erste große Entscheidung: Nimmt man eine, die tatsächlich auf dem Arbeitsmarkt nachgefragt wird (JavaScript, Java, Python, C# etc.) oder nimmt man eine, die (angeblich) für Anfänger*innen besser geeignet ist. Dabei spielen auch visuelle Sprachen bzw. build-your-own-blocks-Sprachen wie Scratch und Snap! eine Rolle, bei denen nur Puzzle-Teile zusammengefügt werden statt Quellcode geschrieben wird. Oder wie es ein Informatikdidaktik-Professor der FU Berlin bei einer Veranstaltung für Lehrer*innen sinngemäß sagte: „Ich verstehe nicht, wie man Anfängerunterricht ohne Scratch machen kann!“ (Zur Erinnerung: eine von 1.000 Meinungen).

Bei den Lernumgebungen verhält es sich wie bei den Programmiersprachen. Soll trotz der Gefahr, Anfänger*innen zu überfordern, eine professionelle IDE wie VisualStudio, NetBeans, IntelliJ, Eclipse etc. oder eine didaktisch reduzierte IDE wie z.B. JavaEditor im Unterricht genutzt werden? Gerade auch Lernumgebungen, bei denen mit Bildern gearbeitet wird, scheinen erst einmal großes Interesse bei Kindern und Jugendlichen zu erzeugen:

• Schildkröten, die Kreise etc. zeichnen (JavaTurtle)
• australische Wombats oder Raketen (Greenfoot)
• Katzen (Scratch)
• Haus mit Sonnenaufgang und -untergang (BlueJ)

Die Seite https://www.programmierenlernen24.de/java-programmieren-lernen/ schlägt z.B. Eclipse als IDE für Java vor (zur Erinnerung: eine von 1.000 Meinungen).

Zwei konkrete Wege: Strukturiert oder objektorientiert einsteigen?

Seit der Jahrtausendwende gab es weltweit einen großen Streit in der Informatik-Didaktik. Das eine Lager zählte viele gute Gründe für einen sog. objects-first-Einstieg (also einen Start mit dem objektorientierten Paradigma) in den Informatikunterricht auf. Das andere Lager lieferte genauso viele gute Argumente, warum man zuerst imperativ/strukturiert/prozedural einsteigen und erst später auf die OOP eingehen sollte (objects-later). Die Lager standen sich relativ unversöhnlich gegenüber: jedes war von seinem Weg überzeugt.

Im Rahmen meiner Dissertation machte ich zwischen 2006 und 2012 eine empirische Studie, bei der ich die beiden Wege miteinander verglich. Die Resultate der Studie deuten darauf hin, dass die Debatte um objects-first bzw. objects-later von geringerer Bedeutung ist als bis dahin angenommen. Ich zitiere:

„Die Debatte sollte sich m. E. eher auf die Vor- und Nachteile jedes einzelnen Weges konzentrieren, speziell auf die Prozessunterschiede. Die Fragestellung braucht in Zukunft nicht mehr zu lauten, mit welchem der beiden Paradigmen die Lehrerin bzw. der Lehrer in den Informatik-Anfangsunterricht einsteigt, da bezogen auf ein Schuljahr (mit ca. 100 Schulstunden) die Klassen den gleichen Lernerfolg hatten. Der Unterrichtende muss sich vielmehr fragen, warum bestimmte Themen von den Schülern als schwierig erlebt bzw. mangelhaft gelernt werden, warum bestimmte Themenübergänge Schwierigkeiten bereiten und wie das subjektive Erleben und der Lernerfolg gesteigert werden können“.¹

Was für diese beiden Wege gilt, gilt wahrscheinlich für alle: jeder Weg hat seine bestimmten Vor- und Nachteile.

Viele gute Wege unabhängig von Programmiersprache, IDE und Paradigma

Während meiner Dissertationszeit gab es eine sehr nützliche Einrichtung: ein sog. Doktoranden-Kolloquium, bei dem sich ca. zweimal im Jahr alle deutschsprachigen (aus Deutschland, der Schweiz und Österreich) Informatikdidaktik-Doktoranden trafen, um über ihre Dissertations-Bemühungen zu berichten. Die Vorgehensweise bei der Mehrheit aller Themen war (vereinfacht) wie folgt:

1. Der Doktorand hat ein spezielles Tool / eine spezielle Programmiersprache / eine spezielle Methode im Unterricht angewandt.
2. Die Lernergebnisse im Informatik-Unterricht haben sich daraufhin verbessert.

Daran erinnerte ich mich, als ich im Beitrag von Dr. Sperber sein Plädoyer für den Einstieg mit einem funktionalen Paradigma und für einen didaktischen Ansatz der sog. Konstruktionsanleitungen las (zur Erinnerung: eine von 1.000 Meinungen).

Ich glaube allen Personen, dass sie von ihrem Weg überzeugt sind. Ich glaube auch, dass die meisten, ausgehend von ihrem „alten“ Weg, durch ihren neuen Weg wirklich den Unterricht verbessert haben. Aber immer nur im Kontext zu ihrer Lehrperson und zu ihren Überzeugungen.

Die verschiedenen Wege sind immer gekennzeichnet von dem Paradigma, der Programmiersprache, der IDE, sonstigen Methoden und den Adressaten.

Die Programmiersprache ist eher ohne Bedeutung: Kennt man eine, kennt man (fast) alle. Natürlich innerhalb eines Paradigmas (objektorientiert, funktional, logisch). Für das objektorientierte Paradigma bedeutet dies z.B., dass es für den Lernerfolg keinen Unterschied darstellt, ob die Programmiersprache Java oder C# oder … ist.

Auch eine Diskussion über das beste Paradigma halte ich nicht für zielführend: ein Anhänger der funktionalen Programmierung wird argumentieren, dass die ganze Welt aus Funktionen besteht, ein Anhänger der objektorientierten Programmierung wird in der Welt überall Objekte sehen. Allerdings sollte ein guter OO-Programmierer Basiswissen über die funktionale Programmierung haben und umgekehrt.

Die Wahl einer Programmiersprache ist in der Praxis oft vom Anwendungsproblem oder der Firmenphilosophie abhängig. Zusätzlich gibt es Programmiersprachen, die nicht nur ein Paradigma verwirklichen. Z.B. ermöglicht Java über die Lambdas den Einzug der funktionalen Programmierung in die objektorientierte Programmierung. Und das ist auch gut so. Im Informatik-Unterricht haben sich viele Sprachen gut bewährt. Zudem sind IDE und Programmiersprache oft miteinander gekoppelt. Und natürlich hat jede IDE ihre speziellen Vor- und Nachteile.

Doch auch wenn der Weg zweitrangig ist, so muss er doch adressatengerecht sein. Der Unterricht mit Kindern und Jugendlichen wird sich vom Unterricht mit Erwachsenen unterscheiden. Ein einmaliger Schnupperkurs wird anders strukturiert sein als der Unterricht in der Berufsschule (für z.B. Fachinformatiker*innen).

Der Weg ist nicht das Ziel, sondern der „gute“ Lehrende!

Wenn der Weg zweitrangig ist, was steht dann auf dem ersten Rang? Wenden wir uns jetzt dem wichtigsten Einfluss zu: den Lehrenden! Diese müssen heutzutage ein Bündel von Kompetenzen in sich tragen:

1. Fachkompetenzen

War es vielleicht früher das Wissen über Kontrollstrukturen, Such- und Sortieralgorithmen, Struktogramme und Programmablaufpläne, so ist heute einiges mehr gefragt:

• verschiedene Vorgehensmodelle (Wasserfall, V-Modell, Scrum etc.),
• UML (Klassen- und Objektdiagramm, Aktivitäts- und Anwendungsfalldiagramm, Sequenz- und Zustandsdiagramm etc.),
• mindestens zwei Programmierparadigmen,
• professionelle Quelltexterstellung (Design Pattern, Clean Code, Git etc.),
• Datenbanksysteme (ER-Modell, Normalisierung, SQL, NoSQL),
• Datenschutz und Datensicherheit,
• Web- und App-Programmierung,
• Aktuell: KI
• und die Fähigkeit mit GitHub, StackOverflow etc. neue Themen anzugehen.

2. Didaktische und pädagogische Kompetenzen und Methodenkompetenzen

Methodenkompetenzen kann sich jeder Mensch (falls gewillt) aneignen. Hierfür gibt es genug Bücher, Beispiele und Fachleute. Bei den didaktischen und pädagogischen Kompetenzen wird es hingegen schwieriger. Da würde ich (aufgrund meiner Erfahrungen mit meinen Kolleg*innen und den sog. Quereinsteigern) provokativ sagen: Zum/r Lehrenden kann man eher nicht gemacht werden, zum/r Lehrenden ist man geboren. Hat man eine natürliche Autorität, hat man ein Händchen für Lernende und merkt man, wann diese einschlafen oder überfordert sind (etc.)?

3. Tool-Kompetenzen

Zielführend für den Lernerfolg sind auch sog. Tool-Kompetenzen: Ein/e Lehrende/r sollte idealerweise kurz vom JavaEditor oder der IntelliJ-IDE nach Greenfoot, Scratch, Snap!, BlueJ oder JavaTurtle wechseln können, um etwas zu visualisieren und/oder den Unterricht abwechslungsreicher zu gestalten.

Quintessenz

Die Quintessenz dieses Beitrags lautet: Jeder der gefühlt 1.000 Wege hat spezielle Vorteile und spezielle Nachteile! Es gibt nicht den Königsweg!

Viel wichtiger als die Wege sind die Lehrenden. Und es ist wichtig, dass die Lehrenden ihren Weg unterrichten dürfen, von dem sie überzeugt sind.

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

[1] Dissertation, Seite 385

Herr Dr. Ehlert ist seit 2019 Herausgeber und Mitautor des Schulbuches: Anwendungsentwicklung in Theorie und Praxis.

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.