Squeak 4.1: Wie Übergang zum "textual scripting pane"?

Wenn man in Squeak 4.1 von einem "Kachelskript" zur Textversion des Skripts übergehen will, kommt die Fehlermeldung: "DoesNotUnderstand: #makeIsolatedCodePaneClassSelector:".
Was lässt sich dagegen tun?

Mit Dank füpr die Hilfe
R. Baumann

Lieber Rüdeger Baumann,

On Thu, 15 Jul 2010, R. Baumann wrote:

>
> Wenn man in Squeak 4.1 von einem "Kachelskript" zur Textversion des Skripts
> übergehen will, kommt die Fehlermeldung: "DoesNotUnderstand:
> #makeIsolatedCodePaneClassSelector:".
> Was lässt sich dagegen tun?
>

Vermutlich im Bug-Tracker ein Ticket eröffnen. Da kenne ich mich aber
nicht so genau aus.

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.

Bis ich dann irgendwann darauf gestoßen bin, wie trickreich die Klasse
'player' gemacht ist.

So gesehen vielleicht folgender Rat: Je nach Einsatzzweck sind
verschiedene squeakbasierte Images im Umlauf. Spontan fällt mir ein:
Etoys, Squeak4.1, Seaside, Pharo (da weiß ich jetzt nicht genau, ob ich
mir Kritik einfange, wenn ich das als squeakbasiert aufliste - mea culpa,
die Hintergrunddetails habe ich nicht voll parat).

Pharo hat seinen Ursprung genau in dem Problemfeld, zu dem wohl auch ihr
Problem gehört: Squeak4.1 ist im Laufe der Jahre gewachsen, es enthält
sehr viele Dinge, die unterschiedlich gut funktionieren. Die Entwickler
von Pharo haben hier erst einmal ordentlich entschlackt und nur das darin
gelassen, was in ihren Augen wichtig und gut gemacht ist. So sollte man in
Pharo wohl weniger Überraschungen erleben dürfen als mit Squeak4.1. Was
mich selber für mein Einsatzszenario Unterricht stört, ist zum einen die
etwas umständliche Klickkombination, um an das Halo eines Objektes zu
kommen, zum anderen das Fehlen von 'Projekten' als unterschiedliche
Sichten auf die Arbeitsoberfläche.

Was es in Pharo z.B. überhaupt nicht gibt, sind die Etoys. Dafür gibt es
aber das Etoys-Image von Squeakland bzw. OLPC. Dieses Image legt seinen
Fokus auf die Kachelprogrammierung. Von daher würde ich zum
Kachelprogrammieren und allem, was im Kern damit zu tun hat, auch nur
dieses Image benutzen.

Konkret:
1. Kachelprogrammieren für die Kleinen:

Etoys-Image, wie es ist

2. Übergang zu Smalltalk im Sinne von Entdecken der
Squeak-Entwicklungsumgebung und der Klassenhierarchie:

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?).

3. Richtiges Smalltalk-Programmieren:

Aus dem Bauch würde ich am liebsten Pharo nehmen, werde aber vielleicht
doch bei Squeak4 landen - vor allem wegen der Projekte, evtl. auch, weil
man dort einfach einen Knopf aus dem Objektkatalog ziehen kann. Da wären
mir Syntaxfärbung und -vervollständigung wichtig.

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. 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.

Markus

Vielen Dank für die hilfreichen Bemerkungen. Noch einige Fragen bzw. Bemerkungen.

> 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!

> 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"?

> Übergang zu Smalltalk im Sinne von Entdecken der
> Squeak-Entwicklungsumgebung und der Klassenhierarchie:

> 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.

Wenn in Squeak 4.1 der Weg von der Kachel- zur Textversion eines Skripts verschüttet ist, muss ich eben bei Squeak 3.9 bleiben. Vielleicht schaufelt die Entwicklergemeinschaft den Weg ja auch wieder frei.

> 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?

> 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.

Viele Grüße

R. Baumann

On 19.07.2010, at 01:31, R. Baumann wrote:

>> 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?

Da müsste man die Leute fragen, die es gebaut haben. Auf der Squeaklandliste.

> 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"?

In erster Näherung sind es tatsächlich nur Objekte und Skripte.

Bei genauerer Betrachtung verstecken sich 2 Smalltalk-Objekte hinter jedem "Etoys-Objekt": Ein Player für das Verhalten, und ein Morph für das Aussehen. Den Morph sieht man auf dem Bildschirm, der Player hat die Skripte.

Softwaretechnisch gesehen implementiert der Player ein prototypen-basiertes System (im Ggs. zum klassen-basierten Smalltalk). Methoden werden einem Objekt hinzugefügt, mit Klassen muss man sich als Etoysnutzer nicht befassen (die Klasse ist immer Player). Man kann einfach ein Objekt kopieren und weitere Methoden hinzufügen. Mit der komplexen Klassenhierarchy z.B. der Morphe muss man sich nicht herumschlagen.

- Bert -

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.
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

Hallo Herr Freudenberg,

vielen Dank für Ihre aufschlussreichen Bemerkungen.

Von Ihnen hatte ich mir auch noch eine Antwort erhofft, warum man in Squeak
4.1 nicht von der Kachelversion eines Skripts zur Textversion übergehen
kann. Markus Schlager vermutet, es ein "bug".

Viele Grüße

R. Baumann

On 20.07.2010, at 15:54, Rüdeger Baumann wrote:

> Hallo Herr Freudenberg,
>
> vielen Dank für Ihre aufschlussreichen Bemerkungen.
>
> Von Ihnen hatte ich mir auch noch eine Antwort erhofft, warum man in Squeak 4.1 nicht von der Kachelversion eines Skripts zur Textversion übergehen kann. Markus Schlager vermutet, es ein "bug".

Stimmt.

- Bert -

wundere mich nur gerade, warum/ob meine mails nicht an die Liste gehen.

Markus