Von der Kachelprogrammierung zu Smalltalk: Begründungen?

Markus hat kürzlich darauf verwiesen, dass das Fehlen der Wiederholungs-Kachel in Squeak "wenig zwingend" ist. Einverstanden. Er führt auch das Fehlen von Methoden mit mehreren Parametern als Beschränkung an. Stimmt.
Nun meine Frage: Könnte man den Übergang zu Smalltalk nicht auch dadurch motivieren, dass mit der Verwendung von Eingabe- und Ausgabefenstern (FillInTheBlankMorph, Transcript) ein "Programmieren im Dialog" möglich wird? Wie ist diese Begründung informatisch bzw. didaktisch-methodisch einzuschätzen?

Dank für Hinweise.

R. Baumann

Hallo,
Am Freitag, 15. April 2011 09:34:43 schrieb R. Baumann: Meine Etoys-Schützlinge wollten noch nie, dass der Benutzer ihrer selbst
programmierten Spiele etwas eingibt.
Allerdings hatte ich letzens folgende Aufgabe, die ich beinahe mit "richtigem"
Programmieren gelöst hätte: Jedesmal, wenn die Spielfigur auf ein bestimmtes
Feld kommt, soll in der Ecke ein Monster erscheinen, das dann die Spielfigur
verfolgt. Eigentlich klappte das ganz gut mit Klonen, aber es ist mir nicht
gelungen, für die Klone dann wieder Kacheln zu haben, die ich hätte nutzen
können, um die Monster z.B. individuell zu steuern. Das programmierende Kind
hat dann großzügig auf die inidivuelle Steuerung der Monster verzichtet.
Also, ich denke in "freier Wildbahn" findet sich immer mal was, was mit
Kacheln halt nicht mehr geht, aber so richtig zwingend ist es dann doch nie.
Gruß
Esther

Gibt es nicht Knobelaufgaben und Rätsel, bei denen man eine Eingabe machen, für die man also einen Dialog programmieren muss?
Ab welchem Alter bzw. Schuljahr können Kinder selbst solche einfachen Dialoge (nach Vorbild, bei einem Rätsel) selbst programmieren?
Ab welchem Alter bzw. Schuljahr können sie das EVA-Prinzip, einen Programmablaufplan, eine algorithmische Struktur verstehen?
Wann kann man frühestens das Wort "Algorithmus" einführen?

Dank für Hinweise.

R. B.

Hallo Esther,

On Thu, 28 Apr 2011, Esther Mietzsch wrote:

Das finde ich in der Tat einen guten Punkt für den Übergang
Etoys->Smalltalk (und zwar gleich richtig mit dem Systembrowser). Ein
großer Unterschied zwischen der Kachel- und der 'richtigen'
Programmiererei besteht schon darin, dass man beim 'richtigen'
Programmieren eben *Klassen* programmiert, sprich Vorlagen für
gleichartige Objekte, von denen man mehrere haben kann/möchte. Bei den
Kacheln dagegen hat man es nur mit Singletons/einzelnen Objekten zu tun.
Geschwister und Duplikate sind eine Möglichkeit, so etwas Klassenartiges
anzunähern, aber immer mit dem Haken, dass Geschwister etwa oft sehr
synchron agieren. Das ist manchmal nicht ganz durchsichtig, vor
allem aber für die Kachelprogrammiererei zuweilen ganz schön trickreich.
Man bastelt da immer erst einen konkreten Prototypen, der dann hoffentlich
serienreif ist. Beim 'richtigen' Programmieren entwirft man eher einen
abstrakten Bauplan.

Zu deinem Problem mit der Individualisierung der Monster: Das geht mit den
Kacheln vermutlich genauso wie klassisch objektorientiert: Wenn die
Monster alle zur selben Klasse gehören, können sie sich nur durch ihren
Zustand, sprich die Werte ihrer Instanzvariablen unterscheiden.
Entsprechend bräuchten die Monster Variablen, die - je nach Position oder
Rolle - bei jedem einzelnen Monster unterschiedliche Werte annehmen können
(das geht bei Geschwistern). Die Skripte müssten sich dann auf diese
Variablen beziehen - etwa mittels Fallunterscheidungen oder über
Parameter.

Markus

On Thu, 28 Apr 2011, R. Baumann wrote:

> Gibt es nicht Knobelaufgaben und Rätsel, bei denen man eine Eingabe machen,
> für die man also einen Dialog programmieren muss?
> Ab welchem Alter bzw. Schuljahr können Kinder selbst solche einfachen
> Dialoge (nach Vorbild, bei einem Rätsel) selbst programmieren?
> Ab welchem Alter bzw. Schuljahr können sie das EVA-Prinzip, einen
> Programmablaufplan, eine algorithmische Struktur verstehen?
> Wann kann man frühestens das Wort "Algorithmus" einführen?

Im Informatiklehrplan für das bayer. Gymnasium passiert das in der 7.
Jahrgangsstufe. Im Mathematiklehrplan nähert man sich dem EVA-Prinzip
ebenfalls ab der 7. Jahrgangsstufe an - ausgehend von Termen und
Zuordnungen in Diagrammen.

Dialoge lassen sich, denke ich, auch mit den Text-Morphen ganz gut machen.
FillInTheBlankMorph finde ich insofern etwas schwierig, als man dort beim
Programmieren üblicherweise nur Klassenmethoden benutzt und eigentlich gar
keine Instanz mit eigenem Objektbezeichner erzeugt. Da wird der Schüler
dann sofort damit konfrontiert dass (in Smalltalk) Klassen auch nur
Objekte sind. So gesehen ist FillInTheBlankMorph ganz anders als so gut
wie alle Klassen, die die Schüler selber programmieren werden. Ich selber
halte das Erzeugen von Farben oder Sonderzeichen über Klassenmethoden für
einen einfacheren und leichter verstehbaren Weg auf die Klassenseite der
Methoden.

Markus

Markus schrieb:

> FillInTheBlankMorph finde ich insofern etwas schwierig, als man dort beim
> Programmieren üblicherweise nur Klassenmethoden benutzt und eigentlich gar
> keine Instanz mit eigenem Objektbezeichner erzeugt.

Das verstehe ich leider nicht. Kann man nicht ganz naiv und klassisch-algorithmisch mittels FillInTheBlankMorph) im Workspace und mit Transcript programmieren? Wo sind da Klassenmethoden?

Ab wann sind die Schüler frühestens in der Lage, Browserprogrammierung und Begriffe wie "Klassenmethode" zu verstehen?

Gruß R. Baumann

On Fri, 29 Apr 2011, R. Baumann wrote:

> Markus schrieb:
>
>> FillInTheBlankMorph finde ich insofern etwas schwierig, als man dort beim
>> Programmieren üblicherweise nur Klassenmethoden benutzt und eigentlich gar
>> keine Instanz mit eigenem Objektbezeichner erzeugt.
>
> Das verstehe ich leider nicht. Kann man nicht ganz naiv und
> klassisch-algorithmisch mittels FillInTheBlankMorph) im Workspace und mit
> Transcript programmieren? Wo sind da Klassenmethoden?

Laut Methodenkommentar ist die typische Verwendung der Klasse doch die:

  FillInTheBlankMorph request: 'What is your favorite color?'

Bzw. wenn das Ergebnis weiterverarbeitet werden soll:

  antwort := FillInTheBlankMorph request: 'What is your favorite color?'

#request:  ist eine Klassenmethode von FillInTheBlankMorph, die
vorübergehend eine Instanz dieser Klasse erzeugt - und gleich wieder
verschwinden lässt: Mit erledigter Eingabe ist auch das Eingabefenster
weg. Mich hat das irritiert.

Das übliche Vorgehen sonst sieht dagegen so aus:

  objekt := Klasse new. "Aufruf des Konstruktors der Klasse"
  objekt mache: etwas.  "Nachricht an die Instanz"
bzw.
  ergebnis := objekt liefere: etwas.

In obigem Beispiel steht aber:

  Klasse mache: etwas. "Nachricht an die Klasse - als Objekt"
bzw.
  ergebnis := Klasse mache: etwas.

Ich selber hatte jedenfalls anfangs so meine Schwierigkeiten, die
Funktionalität von FillInTheBlankMorph zu verstehen. Das ging schon damit
los, dass ich die Methode #request: im Browser zunächst gleich gar nicht
gefunden habe.

Freilich mag man einwenden, daß #new auch eine Klassenmethode ist.
Praktisch bekommt man damit aber kaum zu tun, weil sich das, was man etwa
in Java in den Konstruktor schreibt, in Smalltalk doch so gut wie immer in
#initialize abspielt, was wieder eine Nachricht ist, die an eine
frischgebackene Instanz der Klasse geschickt wird, nicht an die Klasse
selbst. Meinen Schülern gegenüber bezeichne ich #initialize auch als den
Konstruktor der Klasse. Darf ich das oder ist das richtig falsch?

Klassenmethoden sind, denke ich, eher fortgeschrittene Programmierkunst.
Ich selber habe jedenfalls noch nicht viele programmiert.

>
> Ab wann sind die Schüler frühestens in der Lage, Browserprogrammierung und
> Begriffe wie "Klassenmethode" zu verstehen?

Für unsere Sechstkläßler ist das Konzept Objekt <-> Klasse
schwierig - jedenfalls so, wie sie es laut Lehrplan lernen müssen: Anhang
von Vektorgrafiken und Textdokumenten. Da läuft es dann im wesentlichen
doch darauf hinaus, dass eine Klasse eine Sammlung von 'gleichartigen'
(sprich gleiche Attribute und Methoden) Dingen ist. Die Idee eines
Konstruktors fehlt eher. Ich weiß nicht, ob sie froh sind, wenn sie gleich
noch die Klasse aller Klassen präsentiert bekommen.

Meine Zehntklässler kommen mit der Browserprogrammierung ganz gut
zurecht. Einzige Gefahr: Zuweilen ziehen sie versehentlich mit der
Maus Methoden von Standardklassen in ihre eigenen Klassen, statt sie zu
kopieren, oder Standardklassen in andere Kategorien.

Meine Siebtklässler kommen mit Scratch gut klar. Im Grunde ist dessen
Oberfläche aber auch nicht anders aufgebaut als der Systembrowser. Ein
Bereich für die Klassenliste (in Scratch die Objekte), ein Bereich für die
Protokolle (Bewegen, Fühlen, Operatoren...) ein Feld für die
Programmierung der Methodenkörper.

Markus