Ich danke euch schon einmal für die überraschend zahlreichen und ausführlichen Antworten!
hikaru hat geschrieben: 13.08.2021 22:44:35
I. Ich halte es didaktisch für sinnvoller, bei korrekter Lösung nicht einfach nur ein 'ok' auszugeben, sondern tatsächlich die erreichte Lösung
Das kann schon sinnvoll sein. Alternativ könnte man auch das
>output.json weglassen.
hikaru hat geschrieben:
II. Ich finde du nimmst den Schülern mit deinem Programmgerüst zu viel Arbeit ab, bzw. setzt ihnen unnötigerweise Code vor den sie noch gar nicht verstehen können.
Den Boilerplate-Code möchte ich ihnen in diesem Setup wegnehmen (Designziel), hierzu möchte ich ihn sogar noch besser verstecken (importiertes Modul statt copy-paste). Die Schüler schreiben dann eine Art Plugin-Code. Ich sehe die Problematik, wenn diese Art von Instruktion die einzige bleibt. Aber hier soll es um eine konkrete Programmiersprache gehen, ohne das ganze "Plumbing".
hikaru hat geschrieben:
Meiner Erwartung nach werden sich deine Schüler grob in vier Gruppen aufteilen:
1. "Der Eingeschüchterte" hat Angst vor der Black Box und wird sich streng an die aufgezeigten Grenzen ("hier editieren, da nicht") halten. Die Aufgabe wird vermutlich gelöst werden, aber Spaß am Programmieren kommt so nicht auf.
2. "Der Rebell" fühlt sich von den gesetzten Grenzen zur Überschreitung angestachelt. Du stellst zwar die Aufgabe "Sortiert die Namen!", aber was du prüfst ist in Wahrheit "Gibt das Programm 'ok' aus?" Diese Gruppe wird versuchen, dem Programm ein 'ok' zu entlocken. Ob die angedachte Aufgabe dabei gelöst wird ist nebensächlich. Das macht Spaß (was großartig ist), aber der Lernerfolg ist zweifelhaft.
3. "Der Konformist" versteht die Black Box ebenfalls nicht, akzeptiert das aber als "gottgegeben" (hier: Dozent=Gott) und erledigt stur die geforderte Aufgabe ohne dabei wirklich etwas zu lernen. Spaß ist irrelevant.
4. "Der Wissbegierige" wird die Aufgabe erledigen und sich nebenbei zumindest in Grundzügen aus Neugier selbst aneignen, was der Rest des Codes macht. Er lernt (mehr als du beabsichtigt hast) und hat Spaß dabei. Das ist die einzige Gruppe, die tatsächlich von der Übung profitiert.
Der "Eingeschüchterte" wird wohl noch mehr von einer grünen Wiese haben, als vor der Black Box. Dem "Rebell" muss man natürlich klar machen, dass er eine Lösung gemäss Spezifikation schreiben muss. Die Bewertung/Benotung würde natürlich nicht automatisch passieren, sondern durch die Lehrperson. Der "Konformist" wird wohl jedes Setup so ähnlich akzeptieren müssen. Diese Gruppe macht wohl die Mehrheit aus. Der "Wissbegierige" dürfte wohl jedem möglichen Setup etwas abgewinnen können.
Ich finde diese Einteilung sehr interessant, und zu jeder Kategorie fallen mir spontan Leute ein, die dort hineinpassen würden. Dass man alle Gruppen mit einer Lösung gleich gut "abholen" kann, wird jedoch sehr schwierig.
hikaru hat geschrieben:
Fazit: Bring den Schülern zunächst grundlegendes E/A bei! Wenn sie dieses Handwerkszeug beherrschen, dann schiebst du das V dazwischen und sie machen die gesamte Sortierung aus eigener Kraft, was viel befriedigender ist als "durch Reifen zu springen". Die Prüfung machst du extern. Als Kür(!) kannst du hinterher immer noch die Prüfung offenlegen, falls du merkst, dass du genug Wissbegierige vor dir hast um die Kursdynamik zu treiben.
Vielleicht sollte man wirklich mal auf der Kommandozeile anfangen und das Brimborium mit Python gleich weglassen. JSON kann man ja mit `jq` verarbeiten. Ist nicht immer schön, aber so ist halt die Welt.
eggy hat geschrieben: 13.08.2021 22:47:39
Ohne Dich demotivieren zu wollen: wenig.
Stell Dir vor, die Aufgabe ist einen Sortieralgorithmus schreiben.
Und ich geb da als Lösungcode ein: return ["Alice", "Bob", "John", "Mallory"]
Gibt zwar volle Punkte, ist aber trotzdem falsch
Und ich wette, es dauert "keine Stunde" (naja je nach Kenntnisstand halt etwas länger) bis Deine Azubis rausgefunden haben, wie sie das System austricksen
Das ist natürlich das Problem mit praktisch jedem automatisierten Setup. Man könnte natürlich die eine Hälfte der Testfälle vorhalten, um das Problem zu entschärfen. Was aus meiner Beschreibung wohl zu wenig klar wurde: Der Code wird dann schon noch betrachtet.
Meillo hat geschrieben: 14.08.2021 07:57:06
Geht es um die Ausbildung einzelner Personen oder um die Schulung von ganzen Klassen? Im ersten Fall muss man naemlich nicht besonders automatisiert arbeiten, sondern kann die Personen besser individuell dort abholen wo sie stehen.
Ich habe beide Situationen im Auge: im Klassenzimmer soll es den Kern bilden, in der Einzelausbildung ein Lückenfüller, wenn gerade kein Instruktor da ist. In beiden Fällen soll der Lösungscode mit dem Auszubildenden betrachtet werden, halt nicht gleich ausführlich.
meillo hat geschrieben:
Wie ich schon an anderen Stellen geschrieben habe, bin ich kein Freund von Sandkastenprogrammen. Man braucht sie sicher zu einem Teil ganz am Anfang, bevor die Personen ueberhaupt programmieren koennen, dann aber hat mich selbst vor allem das weitergebracht, was fuer mich inhaltlich Sinn hatte.
Der Kurs soll auch ganz am Anfang der Programmierausbildung stehen. Ansonsten finde ich Sandkasten auch nicht ideal, weil sie die Leute zu stark an Java-Enterprise-Settings gewöhnen, wo man praktisch nur einzelne Codeschnippsel in formularartige Templates einfüllt. Schlussendlich soll man ja das komplette Programmieren inkl. Ressourcenverwaltung (Umgang mit Datenquellen usw.) lernen. (Ein schöner
Rant zum Thema.)
meillo hat geschrieben:
Das waren in erster Linie Spiele, aber auch Telefon-/Adressverwaltung, Vokabeltrainer, etc. Diese Anwendungen schaffen durch ihren inhaltlichen Sinn naemlich immer wieder neue Wuensche und Ideen fuer Veraenderungen und Erweiterungen. Damit lernt man am besten Programmieren, finde ich: inkrementelles Erweitern und Umbauen von Code. (Das ist auch viel praxisnaeher als das Bauen von Sandkastenprograemmchen auf der immer wieder neu gruenen Wiese.) Notfalls lieber selber ein Programmgeruest liefern (in einfachem Code) und die Person eine neue Funktion ein-/umbauen lassen als immer wieder Winzprogramme von Grund auf.
Ich bin völlig einverstanden, dass dies der Königsweg ist. Wie gesagt geht es mir aber eher um die ersten Gehversuche.
meillo hat geschrieben:
In 1:1-Situationen finde ich den Dialog besonders wertvoll. Man sollte viele Fragen stellen: Wieso hast du das so gemacht? Wie waere es wenn man das in der Weise tun wuerde? Jenes waere doch auch eine nette Funktion ... Und dann in der Weise die Person ein anfaenglich kleines Programm nach und nach erweitern und umbauen lassen.
Genau in so eine Richtung möchte ich in der 1:1-Situation gehen. (Evtl. sogar inklusive Betrieb der Anwendung auf einem Server, halt je nach Art der Anwendung.) Mein Kurs soll Fingerübungen liefern.
meillo hat geschrieben:
Wenn man den Luxus von 1:1-Situationen hat, finde ich es auch wertvoll, wenn man nicht nur die Ausbildungsperson programmieren laesst und dazu etwas sagt, sondern wenn man ihr auch mal erzaehlt und erklaert was man selber gerade so programmiert, warum man es so macht, welche Sackgassen man ausprobiert hat, wie man zur Loesung gefunden hat, welche Techniken und Hilfsmittel man eingesetzt hat, wie die Gedankenprozesse waren. Dies kommt IMO oft zu kurz.
Das wird sicher in der zweiten Ausbildungshälfte relevant. Das ist leider wirklich etwas, was ich in meiner Ausbildung zu selten erleben durfte.
meillo hat geschrieben:
Gut sind auch Fragestellungen wie: Was macht dieser Code? Warum funktioniert das korrekt? Wo ist der Bug? -- Diese Fragen sind sowohl bei selbst ausfuehrbarem und veraenderbarem Code wertvoll als auch bei kurzen Codeausschnitten, die man im Kopf analysieren muss.
Die Korrektur von Bugs wäre mit meinem angedachten Setup natürlich auch eine Variante. Code lesen ist ja unglaublich wichtig. Wenn man jahrelang programmiert hat, kann man viele Sachen einfach so hinschreiben. Das liegt aber auch daran, dass man diese Sachen eben sehr oft gesehen hat.
meillo hat geschrieben:
In Gruppen/Klassen kann man natuerlich nicht gleichermassen individuell auf die einzelnen Personen eingehen. Solange es aber nicht zu schulisch organisiert ist, wuerde ich dort aber auch versuchen, dass die Personen arbeiten worauf sie Lust haben und worin sie Sinn fuer sich selbst sehen. Dann gerne auch die Fragestellungen und Probleme in der grossen Runde vorstellen lassen und diskutieren.
Das benötigt natürlich einen bestimmten "Reifegrad" der jungen Programmierer. Wenn sie die Grundlagen mal gemeistert haben, finde ich natürlich Dialog viel besser als mit PowerPoint irgendwelche Techniken runterzupauken.
Fazit: Ich werde mal ein paar kleinere Beispiele nach meinem Ansatz an ein paar Testpersonen ausprobieren. Einige Defizite sind mir jetzt klar geworden. Der Kurs soll aber nicht die zwischenmenschliche Interaktion ersetzen, nur für einen ersten und unkomplizierten Feedback-Mechanismus sorgen.