Re: [Squeak-ev] Re: Squeak 4.1: Wie Übergang zum "textual scripting pane"?

[Markus Schlager]

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