Neues Squeak-Buch und Aktualisierung Vereinsseite

Guten Morgen an alle deutschsprachigen Squeaker,

ich habe in der letzten Woche etwas Zeit gehabt, um die Vereinsseite zu
aktualisieren. Das betrifft hauptsächlich die Rubrik "Euler-Probleme
gelöst", aber auch in anderen Bereichen habe ich kleinere Änderungen
vorgenommen. Bei Tippfehlern, unverständlichen Beschreibungen oder
Copy/Paste-Entgleisungen bitte ich wie immer um einen kurzen Hinweis,
damit das korrigiert werden kann.

Und ich freue mich, ein neues Squeak-Buch ankündigen zu dürfen. Unter
dem Titel "Objektorientiertes Programmieren mit Squeak/Smalltalk" zeigt
der Autor Rüdeger Baumann, wie man mit Squeak - gezielt und mit
einfachsten Mitteln - hochkomplexe Probleme löst. Die ersten 100 Seiten
führen den Leser mit Hilfe von eToys an die objektorientierte
Programmierung heran. Dabei kommt der große Vorteil von Squeak als
Sprache zum schnellen Prototyping voll zum tragen.

Sehr gelungen finde ich die häufigen Ausflüge in die Geschichte und die
Verweise auf die Personen hinter der Mathematik. Das erleichtert das
Lesen und macht den ansonsten sehr abstrakten Bereich um einiges
menschlicher. Die vielen geometrischen Abbildungen tragen dazu bei,
Mathematik nicht als reinen Formalismus zu begreifen, sondern als etwas
Schönes und Interessantes.

Wenn ich in einem Satz zusammenfassen müsste, wie ich das Buch einordne,
so würde ich es - sowohl von den Themen als auch vom Layout her - am
ehesten mit "Gödel, Escher, Bach" von Douglas Hofstadter vergleichen.

Mein Kompliment
Enno

PS: Zu den Bestellmöglichkeiten kann ich noch nicht viel sagen, da ich
auch nur über den "Draft" verfüge. Das hole ich aber ganz sicher noch
nach.

Danke, Enno, für die freundlichen und wohlwollenden Worte.

Das Buch ist eigentlich nur als Versuch gedacht, um zur Diskussion zu stellen und zu erproben, was man mit Squeak in der Schule eventuell machen kann. Es sollte damit das Urteil der Expert(inn)en eingeholt werden.

Squeakern und Squeakerinnen, die bereit sind, kritische Anmerkungen zu machen und einige Hinweise zu geben, kann ich gerne ein Vorabdrucks-Exemplar (kostenlos) übersenden.

R. Baumann

Lieber Rüdeger,
ich interessiere mich sehr für Squeak und Fragen zur Didaktik der Lehre
des Programmierens und hätte gerne eine solche Vorabkopie.
Ich würde aber auch ein Exemplar des Buches  kaufen.
Viele Grüße
Michael

Michael, schick mir bitte über E-Mail an

baumann-garbsen@t-online.de

deine Postadresse.

Kaufen kannst du es, wenn es (beim LOG-IN-Verlag) erschienen ist.
Das dauert aber noch eine Weile.

Gruß Rü

"R. Baumann" <[hidden email]> writes:

Hallo Rüdeger,

> Das Buch ist eigentlich nur als Versuch gedacht, um zur Diskussion zu
> stellen und zu erproben, was man mit Squeak in der Schule eventuell
> machen kann. Es sollte damit das Urteil der Expert(inn)en eingeholt
> werden.  Squeakern und Squeakerinnen, die bereit sind, kritische
> Anmerkungen zu machen und einige Hinweise zu geben, kann ich gerne ein
> Vorabdrucks-Exemplar (kostenlos) übersenden.

Was mich mal interessieren würde ... Für welche Klassen/Altersstufe ist
das Buch gedacht? Meine Schulzeit liegt gut 20 Jahre zurück. Die meisten
Themen sind mir zwar irgendwo mal über den Weg gelaufen, aber ob das
schon in der Schulzeit war, kann ich nicht mehr sagen. Andererseits war
der Informatikunterricht zu dieser Zeit auch gerade erst im Aufbau.

Zum Schluss noch eine kritische Bemerkung von mir. :)
Ich vermisse einen Index! Kann man den noch ergänzen?

Und wenn du noch ein paar Anekdoten über Mathematiker unterbringen
kannst, wäre das auch toll. Wenn man Mozart als Rockstar verkaufen kann,
dann auch Euklid :)

ciao
Enno

Hallo Rüdiger,

ich würde liebend gern einen Blick auf den Vorabdruck werfen (gern auch
digital).

Übrigens habe ich vor einigen Monaten vom "Amt für Lehrerbildung"
(Hessen) Informatik mit Prolog von Gerhard Röhner bestellt. In dem Heft
war im Zusammenhang mit Prolog dein Name gefallen, ich nehme an das Du
derjenige bist. Da ich selber keine Lehrer bin, habe ich LOG-IN nicht im
Abo. Aber wenn Du derjenige aus diesen Verweisen bist, hätte ich den
Wunsch an deinen damaligen Texten.

Viele Grüße aus Ettlingen bei Karlsruhe
Rolf

Am 28.02.2011 21:53, schrieb R. Baumann:

> ich würde liebend gern einen Blick auf den Vorabdruck werfen (gern auch
> digital).

Anbei die pdf-Datei.

> Übrigens habe ich vor einigen Monaten vom "Amt für Lehrerbildung" (Hessen)
> Informatik mit Prolog von Gerhard Röhner bestellt. In dem Heft war im
> Zusammenhang mit Prolog dein Name gefallen, ich nehme an das Du derjenige
> bist.

Stimmt. Röhners Skript ist das beste, was es auf diesem Gebiet gibt.

> Aber wenn Du derjenige aus diesen Verweisen bist, hätte ich den ...

Ich hatte mal ein kleines Prolog-Buch im Klett-Verlag geschrieben und einige
Aufsätze in LOG IN.

Sag, was du brauchst.

Gruß Rü

Lieber Rüdeger Baumann,

On Mon, 28 Feb 2011, R. Baumann wrote:

> Das Buch ist eigentlich nur als Versuch gedacht, um zur Diskussion zu
> stellen und zu erproben, was man mit Squeak in der Schule eventuell machen
> kann.

So nach und nach schmökere ich in dem Vordruckexemplar herum. Schöne
Ideen! Sehr erfreulich ist aus meiner Warte vor allem auch, daß das Buch
tatsächlich auf den Schulbetrieb abzielt und dort viele typische Inhalte
abdeckt. So tauchen auch typische Beispiele zur Datenflussmodellierung und
Zustandsübergangsdiagrammen auf. Schade, daß hierbei eine in meinen
Augen ganz große Stärke der Etoys nicht zum Zuge kommt: die Verbinder.

Zur Zustandsmodellierung habe ich mir heute das Beispielprojekt für den
Unterrichtseinsatz in der 10. Jahrgangsstufe im Anhang gebastelt. Was mich
an den üblichen Umsetzungen bei diesem Thema stört, ist die Trennung von
Modell und Implementierung:

Einerseits malt man irgendwo den endlichen Automaten, andererseits
programmiert man dann anderswo irgendetwas, das das Denken in Zuständen
implementieren soll. (Leider scheint noch keinem süddeutschen Didaktiker
aufgegangen zu sein, daß hier UnitTests genau das passende wären - wie das
in Squeak ganz elegant geht, sieht man wunderbar im LaserGame-Tutorial.)
Alternativ gibt es dann noch so Spezialprogramme wie Charon zur formalen
Spracherkennung oder Kara, um ähnlich eingeschränkte Probleme zu lösen wie
mit Robot Karol.

Etoys bietet beides: Da läßt sich der Klassiker Verkehrsampel eben
wirklich direkt mit einem daneben gezeichneten Zustandsübergangsdiagramm
steuern! Auch läßt sich dieses Diagramm ganz nach Wunsch durch andere
Ereignisse aller Art beeinflussen. Es läßt sich ein Getränkeautomat mit
Knöpfen malen, bei dem die Knöpfe, wenn man sie anklickt, einen Übergang
im Zustandsübergangsdiagramm auslösen, der dann eine Veränderung am
Getränkeautomaten zur Folge hat - oder eine Drehorgel mit einer
Zeichenkette als 'Lochstreifen' steuern. Damit macht der Rechner genau
das, was die Schüler vom Denken her lernen und begreifen sollen. Einfach
wird das dadurch, daß die Verbinder Quelle und Ziel kennen.

Ähnlich sieht es mit Datenflussdiagrammen aus. Wenn man Verbinder
verwendet, können die ganz elegant Datenflüsse ausführen - egal welcher
Art. Man kann klassisch rechnen, Strings verarbeiten oder auch Männchen
Eimer voll Sand schaufeln lassen. Damit das dann leicht bedienbar wird und
sich Teilergebnisse an beliebiger Stelle im Datenfluss mit nur einer
Aktion (z.B. ein einziger Mausklick) abgreifen/erzeugen lassen, benötigt
man nur die Fähigkeit 'sage allen Vorgängern', die sich bei verbundenen
Objekten im Betrachter in der Kategorie 'Verbindungen zu mir findet'. So
wie die Beispiele im Buchvordruck stehen, muß der Benutzer aber alle
Teilschritte selbst in der richtigen Reihenfolge ausführen. Das erscheint
mir eher ungünstig. Ich hänge auch dazu mein Projekt an, das ich in der 9.
Jahrgangsstufe im Einsatz habe.

In München sollte meines Wissens die Entwicklung einer Software für solche
Datenflußdiagramme schon einmal Thema einer fachdidaktischen Doktorarbeit
sein. Ich weiß nicht, ob es je ein Ergebnis gab. Mit den Etoys läßt sich
das recht einfach basteln.

Schöne Grüße

Markus

Weil ich gerade dabei bin, im Anhang auch der aktuelle Stand meines
10.-Klaßtutorials in Pharo.

Start am einfachsten über den ProfStef-Browser unter Help im Weltmenü.

Kommentare/Anregungen erwünscht.

Markus

Nachdem ich mir nicht sicher bin, ob das mit den Anhängen auf der Liste
klappt, vorsichtshalber die mail noch einmal. Die erwähnten Anhänge sind
auch hier im Netz zu finden:

- http://www.lsh-marquartstein.de/schule/unterricht/faecher/informatik/unterrichtsmaterial/info10/zustandsmodellierung/Automatensteuerung.pr/view
- https://www.lsh-marquartstein.de/schule/unterricht/faecher/informatik/unterrichtsmaterial/info9/funktionale-modellierung/Datenfluss-schlager.pr/view

Markus

On Thu, 24 Mar 2011, Markus Schlager wrote:

Lieber Rüdeger Baumann,

On Mon, 28 Feb 2011, R. Baumann wrote:

> Das Buch ist eigentlich nur als Versuch gedacht, um zur Diskussion zu
> stellen und zu erproben, was man mit Squeak in der Schule eventuell machen
> kann.

So nach und nach schmökere ich in dem Vordruckexemplar herum. Schöne
Ideen! Sehr erfreulich ist aus meiner Warte vor allem auch, daß das Buch
tatsächlich auf den Schulbetrieb abzielt und dort viele typische Inhalte
abdeckt. So tauchen auch typische Beispiele zur Datenflussmodellierung und
Zustandsübergangsdiagrammen auf. Schade, daß hierbei eine in meinen Augen
ganz große Stärke der Etoys nicht zum Zuge kommt: die Verbinder.

Zur Zustandsmodellierung habe ich mir heute das Beispielprojekt für den
Unterrichtseinsatz in der 10. Jahrgangsstufe im Anhang gebastelt. Was mich
an den üblichen Umsetzungen bei diesem Thema stört, ist die Trennung von
Modell und Implementierung:

Einerseits malt man irgendwo den endlichen Automaten, andererseits
programmiert man dann anderswo irgendetwas, das das Denken in Zuständen
implementieren soll. (Leider scheint noch keinem süddeutschen Didaktiker
aufgegangen zu sein, daß hier UnitTests genau das passende wären - wie das
in Squeak ganz elegant geht, sieht man wunderbar im LaserGame-Tutorial.)
Alternativ gibt es dann noch so Spezialprogramme wie Charon zur formalen
Spracherkennung oder Kara, um ähnlich eingeschränkte Probleme zu lösen wie
mit Robot Karol.

Etoys bietet beides: Da läßt sich der Klassiker Verkehrsampel eben
wirklich direkt mit einem daneben gezeichneten Zustandsübergangsdiagramm
steuern! Auch läßt sich dieses Diagramm ganz nach Wunsch durch andere
Ereignisse aller Art beeinflussen. Es läßt sich ein Getränkeautomat mit
Knöpfen malen, bei dem die Knöpfe, wenn man sie anklickt, einen Übergang
im Zustandsübergangsdiagramm auslösen, der dann eine Veränderung am
Getränkeautomaten zur Folge hat - oder eine Drehorgel mit einer
Zeichenkette als 'Lochstreifen' steuern. Damit macht der Rechner genau
das, was die Schüler vom Denken her lernen und begreifen sollen. Einfach
wird das dadurch, daß die Verbinder Quelle und Ziel kennen.

Ähnlich sieht es mit Datenflussdiagrammen aus. Wenn man Verbinder
verwendet, können die ganz elegant Datenflüsse ausführen - egal welcher
Art. Man kann klassisch rechnen, Strings verarbeiten oder auch Männchen
Eimer voll Sand schaufeln lassen. Damit das dann leicht bedienbar wird und
sich Teilergebnisse an beliebiger Stelle im Datenfluss mit nur einer
Aktion (z.B. ein einziger Mausklick) abgreifen/erzeugen lassen, benötigt
man nur die Fähigkeit 'sage allen Vorgängern', die sich bei verbundenen
Objekten im Betrachter in der Kategorie 'Verbindungen zu mir findet'. So
wie die Beispiele im Buchvordruck stehen, muß der Benutzer aber alle
Teilschritte selbst in der richtigen Reihenfolge ausführen. Das erscheint
mir eher ungünstig. Ich hänge auch dazu mein Projekt an, das ich in der 9.
Jahrgangsstufe im Einsatz habe.

In München sollte meines Wissens die Entwicklung einer Software für solche
Datenflußdiagramme schon einmal Thema einer fachdidaktischen Doktorarbeit
sein. Ich weiß nicht, ob es je ein Ergebnis gab. Mit den Etoys läßt sich
das recht einfach basteln.

Schöne Grüße

Markus

Danke, Markus, für aufschlussreiche Bemerkungen.

Markus schrieb: "Schade, daß hierbei eine in meinen Augen ganz große Stärke der Etoys nicht zum Zuge kommt: die Verbinder."

Den Vorteil der Verbinder habe ich immer noch nicht begriffen - außer dem rein geometrischen Effekt, dass die verbundenen Teile auch bei Verschieben aneinanderhängen.

Die Datenübertragung muss man doch nach wie vor explizit programmieren - oder ist das nicht nötig?

Die Text-Ellipsen und Text-Rechtecke sind m. E. umständlich zu handhaben. Einfacher geht's, glaube ich, mit gewöhnlichen Ellipsen und Text mit Rand.

Ich habe mich an der Anleitung von P. A. Dreifuß im französischen OFSET-Wiki informiert (Représentation d'expressions mathématiques). Das scheint mir alles ziemlich umständlich und für Schüler mehr oder weniger unverständlich.

Gruß R. Baumann

Lieber Rüdeger Baumann,

On Fri, 25 Mar 2011, R. Baumann wrote:

> Markus schrieb: "Schade, daß hierbei eine in meinen Augen ganz große Stärke
> der Etoys nicht zum Zuge kommt: die Verbinder."
>
> Den Vorteil der Verbinder habe ich immer noch nicht begriffen - außer dem
> rein geometrischen Effekt, dass die verbundenen Teile auch bei Verschieben
> aneinanderhängen.
>
> Die Datenübertragung muss man doch nach wie vor explizit programmieren -
> oder ist das nicht nötig?

Jein - Datenübertragung ja, Nachrichtenübermittlung nein. Verbinder kennen
Quelle und Ziel, mit denen sie verbunden sind, als Variablen; diese
Variablen kann man auch in Skripten per Zuordnungskachel verändern, sodaß
der Verbinder von Objekt zu Objekt springen kann. Objekte, die
mit Verbindern verbunden sind, haben Kacheln, um den anhaftenden
Verbindern bzw. den Objekten am anderen Ende des Verbinders Nachrichten zu
schicken.

> Die Text-Ellipsen und Text-Rechtecke sind m. E. umständlich zu handhaben.
> Einfacher geht's, glaube ich, mit gewöhnlichen Ellipsen und Text mit Rand.

Weiß ich nicht - Text-Ellipsen und Text-Rechtecke sind eben Ellipsen oder
Rechtecke, in die sich einfach Text hineinschreiben läßt. Sie sind aber
wohl nicht dazu gedacht, diesen Text per Skriptprogrammierung zu
verändern. Da bettet man dann doch besser selber einen Textmorph in eine
Form ein.

Aus der Paketdokumentation der Connectors (zu finden z.B. in Squeak im
SqueakMap Package Loader - für squeak 4.2 scheint es eine überarbeitete
Version zu geben):

---8X--------------------------
Description:
Connectors is an application for making structured/connected drawings in
Morphic. It adds a new kind of Morph (NCConnectorMorph) that can connect
other Morphs together (and stay connected). There are also a number of
other shapes, flaps, and tools for making your own drawings.

It comes with some sample shapes in flaps for making UML class diagram and
state diagrams.

It's also a framework for making your own structured drawing editors.
There is an easy to use API for querying drawing structure, constructing
drawings, and more.

Categories:
  Applications - Applications written in Squeak intended for regular
nonprogramming users
---X8--------------------------

Bezeichnend finde ich hier 'nonprogramming'.

Der Primärfokus lag also wohl darauf, ein Werkzeug zu haben, um Diagramme
(etwa UML, endliche Automaten, Datenflüss) zu zeichnen. Beispiele dafür
findet man in Etoys, wenn man in den Einstellungen (zu erreichen über das
Menü - Alt+, - unter Hilfe) die Einstellung eToyFrienly deaktiviert und
dann bei deutscher Lokalisierung im Objektkatalog alphabetisch 'k'
auswählt. Da gibt es dann Klappen und Knopfleisten für UML und FSM. In
Squeak gibt es nach Laden des Connector-Paketes (es fehlt dort
standardmäßig) im Objektkatalog eine eigene Kategorie 'UML'.

In diesem Sinne lassen sich Verbinder ganz naiv als Linien nutzen, die
kleben bleiben, aber auch Objekte in eine geordnete Reihenfolge bringen.
Mein erster Kontakt mit Verbindern war hier auf der Liste, als
irgendjemand über ein Projekt seines Sohnes, glaube ich, berichtete, der
im Prinzip einen Morph einen Parcour abfahren lassen wollte und dies
letztlich mit Verbindern löste.

Andererseits sind die Etoys aber keine Programmierumgebung, sondern eine
Ideenverarbeitungs und -visualisierungswelt - Zielgruppe Kinder, aber
nicht nur. Auch als Erwachsener und Informatiklehrer darf ich die Etoys
genau dazu benutzen. In dieser Rolle muß ich meinen Schülern Ideen und
abstrakte Konzepte nahebringen. Eine zentrale Idee sind hier
Beziehungen/Assoziationen/Pointer/Zeiger/Links.

In meinen Augen schrecklichstes Beispiel, das ich in der 11. Klasse
umsetzen muß: Implementiere eine verlinkte Liste gemäßt dem
Compound-Pattern. Da soll also von den Schülern eine Datenstruktur
implementiert werden, die es in zahlreichen Programmiersprachen ohnehin
schon fix und fertig gibt. Schön, aber begreifen die Schüler deren
Funktionalität dann wirklich? Bekommen sie eine *Vorstellung* davon, was
beim Löschen/Einfügen tatsächlich passiert? *Sehen* sie das? Noch habe ich
keine 11. Klasse unterrichtet, aber diese Implementierung werde ich
ziemlich sicher mit Etoys machen - nicht in einer klassischen
Programmiersprache. Dann sind die Listenelemente eben Ellipsen oder
Textfelder mit irgendwelchen Werten (Beschriftung/Farbe/sonstetwas - als
Lehrer kann ich auch ohne großen Aufwand ein Projekt vorbereiten, in dem
es in einem Objektlager (liefert Kopien) oder auf einem MakerButton
(Morph-Knopf, liefert Geschwister - wie die Kopie-Kachel) etwa Ellipsen
mit einer Variablen 'wert' von irgendeinem Typ gibt (bei den
Datenflussdiagrammen oder endlichen Automaten mache ich das auch so - ohne
selbst Programmierer zu sein). Für die Werte könnte man Musterobjekte
erzeugen, die dann bei Bedarf z.B. mit der Kopie-Kachel vermehrt werden.

Und was paßt als Visualisierung der Zeiger/Pointer/Links? Die Verbinder!
Und zwar genau. In einer Liste haben die Elemente keine Namen oder
Nummern. Diese Information steckt allein in den Zeigern, die wissen, von
wo nach wo sie zeigen. Verbinder wissen das auch, kennen Quelle und Ziel
- Namen sind unerheblich. Objekte, die mit Verbindern verbunden sind,
können ein- und ausgehenden Verbindern und ihren Vorgängern
oder Nachfolgern Nachrichten schicken. Verbinder
können diese Nachrichten ausführen. So lassen sich etwa per Kachelskript
'Zeiger' umhängen.

Ebenso bei Datenflussdiagrammen oder endlichen Automaten - die
Funktionalität der Verbinder paßt genau:

1. Verbundene Objekte können ihren Nachfolger/Vorgänger ansprechen.

Beim funktionalen Modellieren in Datenflußdiagrammen braucht es den
Vorgänger. Dann kann jede (Teil-)Funktion den gesamten Teilgraphen ihrer
vorausgehenden Teilfunktionen rekursiv aufrufen. Als Lehrer brauche ich
also nur einen Prototypen für einen Teilprozeß zu Basteln: einen
Darsteller, der ein einziges Skript 'führeDeineFunktionAus' sowie eine
Variable für das Ergebnis seiner Funktion kennt. 'führeDeineFunktionAus'
muss als erstes allen Vorgängern eben diese Nachricht schicken - und dafür
gibt es bei verbundenen Objekten eine eigene Kachel. In meinem Beispiel
habe ich in diesen Prototypen gleich noch einen Knopf für das Skript und
einen Beobachter für den Variablenwert eingebettet - Luxus, den man sich
auch sparen kann. Wenn man für die Prototypen Textrechtecke oder
Textellipsen verwendet, kann der Schüler für sein Diagramm einfach eine
Kopie aus einem Objektlager holen, sie nach Belieben beschriften und das
führeDeineFunktionAus-Skript programmieren. Dabei darf er nur die
abschließende Wertzuweisung in die Variable nicht vergessen.

2. Verbinder können Skripte ausführen und kennen ihre Quelle und ihr Ziel.

Das paßt z.B. genau für Zustandsübergänge in endlichen Automaten. Da
braucht es einen Prototypen für einen Zustand, also einen Morph mit einer
Variablen 'istAktiv'. Wenn man will, kann man auch noch Variablen für
'istStartzustand' und 'istEndzustand' spendieren sowie ein Skript, das die
Aktivität visualisiert - etwa durch einen Farbwechsel. Dafür sind die
Textellipsen sehr schön. Der Schüler holt sich vom MakerButton eine solche
angepaßte Ellipse und beschriftet sie mit der Bezeichnung, die er gerne
für den Zustand hätte.

Bleibt der Verbinder. Da ist auch nicht viel Vorarbeit seitens des Lehrers
nötig. Der Verbinder muß

- eine Variable 'auslöser' besitzen, die etwas enthält, was das auslösende
Ereignis repräsentiert - z.B. einen string.

- ein Skript 'führeÜbergangAus' kennen und darin

   - auf Ereignisse warten, die Übergänge auslösen, also laufen; als
Ereignis bietet sich der Wert einer globalen Variablen an, z.B.
'Welts>letzteEingabe'
   - überprüfen, ob die Quelle aktiv ist
   - evtl. Übergangsbedingungen überprüfen
   - Übergangsaktionen auslösen
- ein Skript 'löseAktionAus' kennen, das die ausgelösten Aktionen enthält.

Das genügt auch schon, wenn man den Verbinder in einem Objektlager zur
Verfügung stellt, weil die Verbinder dann Kopien des Prototyps sind und
sich daher ihre 'führeÜbergangAus'-Skripte unterscheiden dürfen. Der
Schüler holt sich einen Verbinder aus dem Objektlager, legt den Wert für
den Auslöser fest und programmiert das Skript für die ausgelösten
Aktionen.

In meinem Beispiel bin ich beim letzten Schritt anders vorgegangen, weil
der bequemste Weg zu Verbindern über einen Verbinder-Knopf geht. Die
erzeugten Verbinder sind dann aber Geschwister, teilen also ihre Skripte
und können sich nur in ihren Variablenwerten unterscheiden. Daher haben
die Verbinder bei mir eine Variable 'zuSteuerndesObjekt' und eine Variable
'auszulösendesSkript'. Diese beiden Variablenwerte muß der Schüler setzen.
An sich die schlechtere, da unflexiblere Lösung - nur *ein* Skript *eines*
Objektes kann aufgerufen werden. Vielleicht baue ich das auch noch um,
aber mir hat der Morph-Knopf so gefallen.

Wer es weniger informatisch-abstrakt mag: Bei Physik-Simulationen könnten
Verbinder einfach zu bedienende Repräsentanten für Kräfte sein. Sie kennen
ihre eigene Geometrie sowie mit Quelle und Ziel die beiden
Reaktionspartner. Abhängig von der Art der zu simulierenden Kraft würde
der Verbinder aus Attributen von Quelle und Ziel (z.B. deren Massen und
Positionen) und ggf. seiner eigenen Geometrie oder eigenen Attributen
(etwa seiner Federhärte) die Kraft (die ja auf Quelle und Ziel wirkt)
berechnen und sich die Körper dann nur noch um ihre eigenen Eigenschaften
wie die Beschleunigung kümmern. Zum Experimentieren könnte man so einen
Verbinder dann einfach mit der Maus (wie Federn) zwischen verschiedene
Massenobjekte hängen und könnte das unterschiedliche Verhalten der Objekte
beobachten. Weil Verbinder Quelle und Ziel kennen, sind die Namen der
Objekte unerheblich. Der Schüler muß nichts umprogrammieren/Kacheln
austauschen, sondern einfach nur den Verbinder umhängen.

Markus

Lieber Rüdeger Baumann,

Den Übergang zur Smalltalk-Programmierung mit dem Fehlen der
Wiederholungskachel in Squeak zu motivieren, halte ich für wenig zwingend.
Die naheliegende Reaktion aus meiner Sicht wäre die, dann eben Etoys zu
benutzen, wie generell eher Konsens sein dürfte, daß man zum
Kachelprogrammieren besser ein Etoys-Image benutzt.

Ich habe auch einmal mit Etoys (damals noch Squeak) begonnen, weil mir der
Wechsel zur Textansicht bei den Skripten gefallen hat und ich an einen
ähnlichen Weg dachte, wie der im Buch beschrieben wird. Aber das erste,
was mich daran gestört hat, waren dann diese aussagekräfitgen
Parameternamen der Form 't1', das zweite die eingeschränkten
Editormöglichkeiten der Skriptfenster.

Die eigentliche Einschränkung, die ich beim Kachelprogrammieren empfinde,
ist das Fehlen von Methoden mit mehreren Parametern. Das kann man zwar
auch schaffen, wenn man einen Parameter vom Typ 'player', also Darsteller
benutzt und dessen Attribute im Skript auswertet, aber das ist eher
trickreich als naheliegend.

In meinen 10. Klassen taucht der Smalltalk-Quelltext aber meist aus ganz
anderen Gründen auf: Schüler programmieren etwas, bei dem sie sich (und
manchmal auch erst einmal ich mich) wundern, warum das nicht (immer)
klappt. Mit den Kacheln sieht man das nämlich nicht immer.

Konkretes Szenario: Die Schüler programmieren bei mir ein
Tausammler-Spiel, in dem ein Käfer Tautropfen einsammeln muß. Entscheidend
ist hier, daß es mehrere Tautropfen gibt, die alle Geschwister sind.

Lösung 1: Die Tropfen warten auf den Käfer.

Lösung 2: Der Käfer sucht die Tropfen.

Anschließend läuft der Tropfen dem Käfer hinterher oder der Käfer
transportiert ihn - das ist egal, wie herum.

Die Schüler programmieren das zuerst für einen Tropfen und erweitern es
anschließend auf mehrere Tropfen. Was üblicherweise passiert, ist
folgendes:

Die Schüler mit Lösung 1 haben keine Probleme. Zumindest ein Teil der
Schüler mit Lösung 2 beklagt sich irgendwann, dass der Käfer immer
denselben Tropfen mitnimmt, egal welchen er gerade überlappt.

Die Kachelskripte sehen praktisch gleich aus:

"Käfer überlappt Tropfen" oder umgekehrt. Wer bei den Kacheln wen
überlappt ist egal. Einziger Unterschied: Bei Lösung 1 ist das ein Skript
des Tropfens, bei Lösung 2 ein Skript des Käfers.

Verschieden werden die beiden Skripte aber, sobald man in die Textversion
blickt: Da steht als einmal "self überlappt Käfer" und einmal "self
überlappt TropfenSoundSo". Und daran läßt sich auch erklären, warum Lösung
2 ein Problem hat und wie man das mit "überlappt irgendein" noch lösen
kann. Zugleich sehen die Schüler hier eine Stelle, an der die Kacheln
einen echten Schwachpunkt haben, weil sie etwas verbergen - es gibt kein
'self'.

Anschließend wechsle ich aber direkt zum Programmieren mit Workspace und
Browser, weil die Syntaxvervollständigung einfach angenehm ist, und ich
ohnehin dorthin will/muß.

Markus

Markus Schlager schrieb:

"Den Übergang zur Smalltalk-Programmierung mit dem Fehlen der
Wiederholungskachel in Squeak zu motivieren, halte ich für wenig zwingend.
Die naheliegende Reaktion aus meiner Sicht wäre die, dann eben Etoys zu
benutzen, wie generell eher Konsens sein dürfte, daß man zum
Kachelprogrammieren besser ein Etoys-Image benutzt."

Einverstanden - ich bin inzwischen auch zu Etoys übergegangen. Squeak ist in vieler Hinsicht stehen geblieben, Etoys ist inzwischen viel weiter.

Markus weiter:

"Das erste, was mich gestört hat, waren dann diese [wenig?] aussagekräftigen
Parameternamen der Form 't1', das zweite die eingeschränkten
Editormöglichkeiten der Skriptfenster."

Die (auch in Etoys 4.1 vorhandenen) wenig aussagekräftigen Parameternamen kann man sofort durch die Schüler (als übung) durch aussagekräftige ersetzen lassen.

Markus:

"Die eigentliche Einschränkung, die ich beim Kachelprogrammieren empfinde,
ist das Fehlen von Methoden mit mehreren Parametern."

Stimmt - dann muss man eben Variablen verwenden.

Noch vielen Dank für die eingehenden Bemerkungen zu den Verbindern; vielleicht werde ich ihren Sinn durchschauen und dann entsprechend verwenden.

Die beiden Beispiele (Automat und Datenflüsse) scheinen mir überprogrammiert; es handelt sich um fertige Software, die die Schüler (nur) verwenden sollen. Meines Erachtens müssten die Schüler die entsprechenden Projekte selbst entwickeln (können), auch wenn sie nicht so perfekt sind.

Gruß Rü

On Sat, 26 Mar 2011, R. Baumann wrote:

>
> Die beiden Beispiele (Automat und Datenflüsse) scheinen mir
> überprogrammiert; es handelt sich um fertige Software, die die Schüler (nur)
> verwenden sollen. Meines Erachtens müssten die Schüler die entsprechenden
> Projekte selbst entwickeln (können), auch wenn sie nicht so perfekt sind.
>

Kommt darauf an, wozu man sie verwenden will. Die beiden Projekte sind als
fertige Software gedacht. Zugleich sind sie aber auch Beispiele dafür, was
man mit Etoys so alles umsetzen kann, ohne groß Klassenbibliotheken einer
Programmiersprache kennen zu müssen.

Das Datenflussprojekt benutzen bei mir Schüler der 9. Klasse, weil sie
etwas über Datenflüsse lernen sollen. Ihre eigenen Programmierkenntnisse
beschränken sich zu dem Zeitpunkt auf etwas Scratch aus der 7. Klasse.

Den Automat verwende ich in der 10. Klasse, um den Schülern die Konzepte
zustandsorientierte Modellierung und Zustandsübergangsdiagramm zu
vermitteln. An diesem Punkt geht es mir nicht um Programmierfähigkeiten
der Schüler, sondern darum, hier, vom Automaten her gedacht, etwas
nettere/vielfältigere Beispiele umsetzen zu können und dabei die Schüler
nicht unbedingt ein komplett neues Werkzeug lernen lassen zu müssen.

Markus