On Sun, 18 Jul 2010, R. Baumann wrote:
Ich selber habe früher auch daran gedacht, genau diesen Weg zu gehen: Kachel-Programmierung mit Etoys und dann durch die Falltüre 'Textversion des Skriptes' hinab in die Tiefen von Smalltalk.
Sehr gut - es ist der "Königsweg" Smalltalk!
Nein, finde ich nicht mehr so ganz. Es ist ganz in Ordnung, weil man einfach zeigen kann, was wirklich hinter dem ganzen steckt, weil ein Schüler sieht, daß das in der Programmiersprache auch nicht viel anders aussieht als bei den Kacheln. Richtig hilfreich wird es, wenn man mit Kopien und Geschwisterinstanzen arbeitet und die Schüler beim Programmieren dummerweise die Kachel einer falschen Instanz erwischen, sodaß dann im Quelltext statt 'self' plötzlich ein anderer Name steht. Ja, man kann damit manche Dinge ganz gut erklären und zeigen.
Aber wie geht es dann weiter? Man könnte die Schüler einzelne Etoys-Skripte in der Textansicht schreiben lassen. Aber warum sollten sie das tun, wo sie die Skripte doch zusammenklicken können? Worin bestünde aus deren Sicht der Mehrwert?
Wenn das Ziel 'objektorientierte Programmierung' heißt, stellt sich auch die Frage, wo diese Skripte denn eigentlich 'sind'. Und da landet man dann bei seltsam benannten Unterklassen 'PlayerXY' einer sehr komplexen Klasse 'Player'. Und ausgerechnet diese Klasse implementiert Prototypen, also nicht gerade typisch für Klassen.
Von der Modellierung her lernen die Schüler andererseits, daß der Königsweg zu neuen Funktionalitäten über Vererbung und Unterklassen führt.
Wenn ich zwischendurch Konzeptionelles mit den Kacheln zeigen will, kann ich ja auf das Etoys-Image zurückgreifen. Was ich da nie einfach geschafft habe, war, aus etwas mit Kacheln Programmiertem eine Unterklasse zu erzeugen.
Was heißt das? Wozu wird das benötigt?
Konkret, was ich einmal versucht habe:
Ziel: Massenpunkte im Schwerefeld. Plan: Nimm Etoys-Ellipsen aus dem Objektkatalog, erweitere sie um physikalische Attribute und Methoden (masse, geschw, beschl etc.) und packe das Ergebnis in eine neue Unterklasse.
Es gibt schließlich den Programmieren-Knauf im Halo (den mit dem Schraubenschlüssel). Und der bietet einen Menüeintrag 'Unterklasse anlegen'. Gelesen - getan. Und? Es entsteht eine Unterklasse des *Morphs*, deren Instanzen aber nicht einmal das aktuell gemalte Bild haben, sondern ein Standardsymbol (etwa die Zeichenpalette) zeigen. Die neue Klasse weiß als Unterklasse des Morphs natürlich auch nichts von meinen tollen neuen Attributen und Skripten. Pustekuchen.
(P.S. natürlich weiß ich mittlerweile, daß ich einen Massenpunkt als Unterklasse einer Ellipse eher schlecht modelliert habe, aber ich wollte an sich eine Unterklasse des Darstellers, nicht des Kostüms.)
Irgendwann steht so oder anders der Schritt an, Workspace und Browser einzuführen. Ich denke, ich würde das eher früh machen - ich denke hier freilich an die Zielgruppe Zehntkläßler, die in der siebten Klasse mit Scratch oder Etoys die Kachelprogrammiererei bereits einmal kennengelernt haben und Kontrollstrukturen wie Verzweigung oder Wiederholung bereits kennen.
Eine andere Frage ist dann auch noch die, wie man seine Werke eigentlich abspeichern will/soll. Da tendiere ich mittlerweile voll zu Monticello, sobald es ans Smalltalk-Programmieren geht, weil ich als Lehrer ja auch an die Werke meiner Schüler herankommen können möchte.
Bis ich dann irgendwann darauf gestoßen bin, wie trickreich die Klasse 'player' gemacht ist.
Was soll eigentlich die Theatermetaphorik (player, costume etc)? Wo kommt das her, wer hat das aufgebracht?
Die naive Vorstellung ist: Es gibt Objekte und Skripten; letztere dienen dazu, den Objekten vorzu"schreiben", was diese zu tun haben. Was sollen in diesem Zusammenhang "Spieler" und "Kostüme"?
Die Skripte sind so etwas wie die Regieanweisungen oder das Drehbuch, wobei ich eher sagen würde, die Skripte beschreiben, *wie* ein Darsteller etwas zu machen hat. Die Theatermetaphorik gibt es auch bei Scratch, wo die Welt sogar 'Bühne' heißt. Player und Morph/Bild bzw. Spieler und Kostüm bieten, finde ich, eine recht gute Veranschaulichung des Prinzips der Trennung von Modell und View. Mir sind sie mittlerweile recht sympathisch.
Etoys-Image, ggf. mit Alt-W oder Alt-, ein Weltmenü öffnen, unter Hilfe den Einstellungsmanager öffnen, dort nach 'friendly' suchen und etoysfriendly deaktivieren - und das Image speichern. Dann kommt man einfach an Browser, Workspace und Inspektoren. Bei Bedarf kann man auch die Standard-Entwicklerklappen installieren. Noch hat man dann ein Squeak3.x-Image (stimmt das, Bernd?).
Das scheint mir zu umständlich.
Finde ich eigentlich gar nicht einmal besonders umständlich. Zumal es auch genügt, wenn der Lehrer einmal ein so umgebautes Image zur Verfügung stellt. Wenn ich zuverlässig mit Kacheln arbeiten wollen würde, würde ich in jedem Fall diesen Weg gehen. Es ist das Image, bei dem ich mir am sichersten sein kann, daß die Kachelprogrammierung in allen Facetten funktioniert. Aber ich weiß ehrlich nicht, ob man die Kacheln überhaupt noch braucht, wenn man mit den Schülern Smalltalk programmieren will.
Aber davon habe mich ohnehin verabschiedet, weil das Programmieren der Morphe auch in Smalltalk nicht wirklich schwierig ist, wenn man die entscheidenden Nachrichten gefunden hat.
Aber die erst einmal finden, ist doch das Problem.
Richtig, aber das ist in erster Linie ein Problem der Dokumentation, nicht des Images. Das Finden wird freilich umso einfacher, je leerer ein Image ist. Squeak3.9 ist besonders voll, denke ich.
Markus