How Not to Fail at Programming Education - meine Erkenntnisse von der TaCoS, Teil 2
Kategorien: Studium, Python

Am ersten Tag der TaCoS hatte ich das ungute Gefühl, dass das Publikum nach den Vorträgen sehr diskussionsunwillig war. Vielleicht weil alle Fragen immer sowieso schon beantwortet waren, vielleicht weil sie sich nicht getraut haben, vielleicht weil sie die präsentierten Themen erstmal verdauen mussten. Ich hatte dann die Befürchtung, dass meine Session (ganz am Ende des zweiten Tags) völlig schiefgehen würde - sie war als anderthalbstündige Diskussionsrunde mit einleitendem Vortrag geplant, und ich machte mir Sorgen, dass es danach keine oder nicht genug Gesprächsbeiträge geben würde.

Ich konnte das Problem aber dann dadurch vermeiden, dass ich am Ende meines Vortrags konkrete Fragen in den Raum stellte. So fühlten sich die Zuhörenden direkter aufgefordert, ihre Erfahrungen und Meinungen mit den anderen Anwesenden zu teilen.

Während wir diskutierten, schrieb ich mit und erstellte so eine Liste der Kriterien, die für Computerlinguistikstudierende besonders wichtig sind, wenn sie an Programmierkursen teilnehmen. Hier eine Auswahl der besonders eifrig diskutierten Themenbereiche:

  • Klausuren zu schreiben, in denen man auf Papier Programmcode schreiben muss, hassen alle.
  • Programmierprojekte in Kleingruppen zu entwickeln und abzugeben mögen zwar nicht alle, aber es wird allgemein als sehr sinnvolle Übung betrachtet. Man lernt, sich mit anderen abzusprechen, Programme klar zu strukturieren (auch mithilfe von Versionskontrolle, Kollaborationstools und anderen Planungsstrategien) und in separate Aufgabenbereiche aufzuteilen, und das Schreiben von lesbarem Code sowie das Lesen fremden Codes wird gut trainiert. Ein Nachteil ist das Problem, verschiedene Fähigkeitslevel in der Gruppe unter einen Hut zu bringen, und natürlich gibt es dann noch das Problem des oder der "faulen Dritten", der oder die die anderen die ganze Arbeit erledigen lässt.
  • Das Lösen größerer Programmierhausaufgaben gefällt vielen nicht, obwohl einige es ebenfalls für gutes Training halten. Ich persönlich gehöre zu denen, die einen komplizierten Algorithmus erst dann verstehen, wenn sie ihn implementiert haben. Andere mochten es nicht, dass der Rahmen so fest vorgegeben ist und es sozusagen nur genau eine richtige Lösung gibt, das führt dann zu Motivationsmangel.
  • Wenn es größere Programmierhausaufgaben gibt, stellen einige Dozentinnen ein Gerüst für den Code zur Verfügung, in dem zum Beispiel schon alle Funktionen, die benötigt werden, enthalten sind. Die Aufgabe besteht dann darin, jede einzelne Funktion zu implementieren. Viele haben bei unserem Gespräch zu Bedenken gegeben, dass man in solchen Fällen möglicherweise zuwenig selbst über die Struktur der Aufgabe nachdenkt und nur noch die "Fleißarbeit" erledigt. Der Vorteil ist, dass die Struktur von Anfang an sinnvoll ist - ich halte es für hilfreich, dass man dadurch gute Beispiele für Programmstrukturen sieht und daraus lernen kann, welche Vorgehensweisen nützlich sind, sodass man sich auch beim Entwurf eines komplett eigenen Programmes an diesen Dingen orientieren kann.
  • Ein weiterer Vorteil von Hausaufgabengerüsten ist, dass so schneller erkennbar ist, was man nun eigentlich genau tun soll, die Aufgabenstellung wird dadurch verständlicher.
  • Ein Vorteil für die Lehrenden ist, dass das Gerüst dafür sorgt, dass alle abgegebenen Programme auf die gleiche Weise getestet werden können. Das spart Arbeit und erleichtert den Vergleich zwischen den Lösungen.
  • Das Thema "Meine erste Programmiersprache" wurde auch diskutiert, aber wir konnten uns nur auf zwei Dinge widerspruchsfrei einigen: NICHT JAVA (weil es viel zu viel Overhead hat und man für ein "Hello World"-Beispiel gefühlt 40 Zeilen braucht), und MÖGLICHST NICHT PERL (weil diese Sprache zu hässlichem Programmieren einlädt). Funktionale/logische Programmiersprachen wurden sehr gelobt, aber nicht als Werkzeug zum Programmieren, sondern eher als Methode, logisches Denken zu lehren.
  • Ein Teilnehmer der Session fand es gut, in möglichst maschinennahen Sprachen zu programmieren. Alle anderen fanden es gut, mit möglichst menschenfreundlichen Sprachen den Einstieg in die Programmierung zu finden.
  • Fast alle fanden es wichtig, mehrere Programmiersprachen zu vermitteln. Erstens, um vergleichen zu können, was der Unterschied ist, aber dann auch als Übung, falls man für einen Job später eine neue Sprache lernen muss/möchte - dann kann man auch dem neuen Arbeitgeber demonstrieren, dass man in der Lage ist, sich in neue Sprachen einzuarbeiten.
  • Für den Kontext des Computerlinguistikstudiums stieß mein Vorschlag, theoretische Konzepte verstärkt zu unterrichten, auf erstaunlich wenig Begeisterung. Die Anwesenden hielten es für besser, nur Programmiersyntax und konkrete Probleme der Computerlinguistik zu besprechen und auf Klassendiagramme oder Speicherarchitektur weitgehend zu verzichten.


Zum Schluss der Diskussion stellte jemand in Frage, ob wir überhaupt Programmierkurse brauchen. Aber ein Computerlinguistikstudium ohne Programmierkurse kam uns allen dann zu theoretisch und trocken vor. Wir hätten dann die Anwendungsorientierung, auf die wir uns manchmal etwas einbilden, vermisst. Wir beschlossen, dass mindestens ein Python-Grundkurs angebracht ist, um Motivation zum Programmieren zu generieren und den Grundstein für interessante CL-Projekte zu legen. Ob noch mehr programmiert wird und in wievielen Sprachen, unterscheidet sich sowieso danach, wie eng das jeweilige Institut mit der Informatik zusammenarbeitet.

Kommentare

Name:


Nachricht:


Sicherheitsabfrage:
Bitte den abgebildeten Code in das Feld eintragen.

Neu laden

ke (21.05.2015, 17:40)
Ich bin da in allen Punkten mit dem wiedergegebenen Tenor einig bzw. in dem letzten Punkt mit dir: ein bisschen Speicherarchitektur ist schon wichtig, glaube ich, und wenn man OOP macht, dann auch Klassendiagramme. Ob sich OOP indes überhaupt lohnt, da bin ich noch gespalten. Ich halte es für manche größeren Softwareprojekte für wichtig, aber in der Computerlinguistik kann man, glaube ich, auch ganz gut ohne auskommen.

Zu Hausaufgabengerüsten: Statt deren kann man auch eine Testsuite zur Verfügung stellen. Die gibt auch eine sinnvolle Struktur vor (i.e. definiert implizit das API), aber die Studis müssen den Hauptcode immer noch komplett selbst hinschreiben – ist vielleicht in manchen Fällen ein guter Kompromiss. Eine mögliche Gefahr ist, dass die Studis die Aufgabe nicht lösen, sondern nur irgendwie die Testsuite zufriedenstellen, und dann tausend Diskussionen entstehen ala: "Ja, aber es hat doch funktioniert!"

Ich habe Testsuites noch nicht selbst zum Unterrichten eingesetzt, aber vielleicht in der Zukunft mal. Ich habe sie aber als Kursteilnehmer auf coursera.org mehrfach miterlebt, da wurde dann auch das Bewerten der Arbeiten vollständig automatisiert, dadurch, dass es eine zweite Testsuite gab, die die Studis nicht zu sehen kriegen. Mit einer geeigneten Plattform ließe sich dieses System, denke ich, auch im universitären Rahmen einsetzen, und in Verbindung mit unverzüglichem Feedback und mehreren Versuchen dürfte es auch die oben geschilderte Gefahr weitgehend neutralisieren.
Esther Seyffarth 2017 • Impressum