Etoys/Squeak vs. Scratch (Diskussionsbeitrag von Ralf Romeike)

Im (neuen) Heft 163/164 der Zeitschrift ist ein Diskussionsbeitrag von  Ralf Romeike erschienen, der sich kritisch mit Etoys/Squeak auseinandersetzt und die Überlegenheit von Scratch als Werkzeug der informatischen Bildung nachzuweisen sucht. Mit Recht stellt er gewisse Mängel von Etoys/Squeak fest; doch wird der denkende Leser, der im gleichen Heft einen Aufsatz zur objektorientierten Modellierung mit Smalltalk/Squeak findet, rasch die Unwesentlichkeit der Einwände erkennen.

Den entscheidenden Vorzug von Etoys/Squeak kann Romeike nicht abstreiten, nämlich dessen Offenheit: die Tatsache, dass kein Unterschied zwischen Werkzeug und Produkt besteht. Benutzer und Entwickler haben gleiche Möglichkeiten und Rechte (wie Bert Freudenberg einmal zutreffend festgestellt hat). In Bezug auf die informatische Bildung heißt dies, dass Schüler und Schülerinnen in ihrer Rolle als Benutzer zugleich Entwickler sind, dass sie also einerseits, das Softwaresystem erkundend, am Vorbild lernen und andererseits dieses System aus- und umgestalten, gegebenenfalls verbessern können. Damit wird die Forderung der modernen Lern¬theorie erfüllbar, „dass sich Wissen nicht ‚übertragen‘ lässt, sondern vielmehr in kon¬kreten Situationen jeweils neu auf dem Hintergrund der eigenen Erfahrungswelt konstruiert werden muss“ (Bildungsstandards Informatik, 2008, S. 5).

Etoys/Squeak ist ein Werkzeug, das allen möglichen didaktischen Systemen und Produkten, wie beispielsweise Scratch, im Hinblick auf die genannten Ziele informatischen Lernens turmhoch überlegen ist. Es ist an der Zeit, dass die Squeak-Gemeinde dies offensiv vertritt und durch Unterrichtsvorschläge überzeugend nachweist.

R. Baumann

Lieber Herr Baumann, hallo Liste,

Am 04.11.2010 20:19, schrieb R. Baumann:
> die Überlegenheit von Scratch als Werkzeug der informatischen Bildung
> nachzuweisen sucht.

Nein, ich male eben nicht nur schwarz/weiß. Ich habe mich bemüht,
verschiedene Aussagen Ihres vorausgegangenen Artikels, die m.E. so nicht
haltbar sind (z.B. Scratch in der Oberstufe sei eine Missachtung der
Fähigkeiten der Schüler), fundiert zu kritisieren.
Dazu gehören auch verschiedene Begründungen, warum sich Scratch "besser"
zum Einstieg in die Programmierung eignet, u.a. unter der Prämisse,
Kreativität zu fördern, was Ihnen, trotz gesetztem Ziel, m.E. in Ihren
Beispielen nicht gelungen ist. Schade, dass Sie die "Einwände" nur als
unwesentlich abtun. Wenn Sie einmal 25 Schüler der 7. Klasse mit den
Werkzeugen unterrichten, werden Sie vermutlich schnell merken, dass die
Argumente eben nicht unwesentlich sind.

Ein "Werkzeugstreit", zumal solch ähnlicher Werkzeuge, bringt uns aber
nicht weiter. Wichtig wäre es wirklich aufzuzeigen, wie man mit
Etoys/Squeak guten weiterführenden Informatikunterricht machen kann. Und
warum auch nicht als Fortführung nach einem Einstieg mit Scratch? Die
Grundlagen sind ähnlich und wären gelegt. Leider habe ich noch nicht
viele überzeugende Beispiele gesehen, würde mich aber über solche freuen!

Beste Grüße,
Ralf

PS: Wer die LOG-IN-Artikel nicht kennt aber lesen möchte, kann mir gern
eine Mail senden, dann schicke ich sie zu.

On 11/4/2010 4:18 PM, R. Romeike wrote:
> PS: Wer die LOG-IN-Artikel nicht kennt aber lesen möchte, kann mir gern
> eine Mail senden, dann schicke ich sie zu.

Ja bitte.

Ciao,
   - Andreas

Überlegen ist nun Etoys/Squeak aus pädagogischer Sicht sicherlich in
vielerlei Hinsicht. Es kommt bei den Kiddies kaum Frust auf, Spiel
überwiegt. Wenn ich mir allein überlege, wie lange ich für so einen
Quatsch in C++ oder Java bräuchte?

#(1 2 3 4) + 5.

#(6 7 8 9)

#(3 #(3 4) #(5 6 7)) * 3.1415.

#(9.4245 #(9.4245 12.566) #(15.7075 18.849 21.9905))


6 Dinge allerdings machen mir Kopfschmerzen:

1. Einmal Smalltalk - die wollen nie wieder andere Programmiersprachen
erlernen!

2. Smalltalk ist Hacken, kein modernes Software Engineering, wie man
z.B. mit JAVA und BlueJ lernen kann.

3. Multiprozessorunterstützung fehlt bislang (RoarVM kommt wohl bald)

4. Erziehung zur Frusttrationstoleranz. Sich mal auch "durchbeissen
müssen" durch Bits und Bytes

5. Sinnlos erworbenes Wissen, da kein Entscheider Squeak einsetzen wird.

6. Zu hohes Abstraktionsniveau für Einsteiger


zu 6)

The Elements of Computing Systems: Building a Modern Computer from First
Principles ... Von Noam Nisan,Shimon Schocken
http://books.google.de/books?id=THie6tt-2z8C&printsec=frontcover&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false

Wer sich das in Ruhe mal durchliest, wird viele neue Erkenntnisse haben.
Nicht nur, dass das pädagogische System von Shocken sich nicht nur um
Programmierung dreht, sondern ebenfalls um den Entwurf der dazu
gehörigen Hardware, was elementare Einblicke in die Wechselwirkung von
Hard - und Software gibt, kein - man kann einen Computer mit Hardware
simulieren und im Betrieb beobachten. Und später das auch in FPGA oder
ASIC giessen. So erfährt man auch, was es mit diesen Firmware - Treibern
unter Linux auf sich hat! ;-) Z.B. ist es recht anschaulich erklärt, wie
man ein PONG Spiel mit nur wenigen hundert Byte realisiert.

Ich verwende das System zur Ausbildung von Informatik - Studis an der
Berliner Uni. Erinnert mich an die Zeit, wo ich selber noch Chips
gelötet habe.

zu 3)

Schaue ich mir das neue C++0x, die Programmiersprache GO, Haskell an, so
komme ich mit diesen Werkzeugen zu jedem Ziel. Automatische
Parallelisierung steckt bereits in den neuen Libraries.

In Kürze werden alle Computer Mehrprozessorsysteme sein, ARM, INTEL,
GPGPU's sogar massiv. Ein Parallelrechner mit 512 Prozesoren ist für
unter 1000€ zu haben!

Smalltalk besitzt z.B. im Gegensatz zu Haskell keinerlei eingebauten
Parallelismus. In Haskell sind alle verwendeten Algorithmen
*GRUNDSÄTZLICH* parallelisierbar. Keine Library, die nicht
vollautomatisch alle verfügbaren Prozessoren ausnutzt. C++0x wird da
kaum hinterher stehen, GO ebenso. Smalltalk ist zwar theoretisch auf der
RoarVM lauffähig, aber *ALLE* verwendeten Algorithmen in den Libraries
sind Single - Prozessor Algorithmen. Smalltalk müsste, um eine Zukunft
zu haben, angesichts der MP - Welle, *komplett* eingestampft und mit
Parallelalgorithmen völlig neu implementiert werden.

Zu RoarVM siehe: http://forums.instantiations.com/viewtopic.php?f=12&t=5523

Damit komme ich zu 5.)

Es ist für einen Schüler einfach vertane Zeit, Smalltalk zu lernen, wenn
er nach Schulschluß einen Nebenjob in einer Programmierfirma mit C++0x
oder Java haben könnte.

MfG, Guido Stepken

Hallo Guido,

On Fri, 5 Nov 2010, Guido Stepken wrote:

[...]
>
> 5. Sinnlos erworbenes Wissen, da kein Entscheider Squeak einsetzen wird.
[...]
>
> Zu RoarVM siehe: http://forums.instantiations.com/viewtopic.php?f=12&t=5523
>
> Damit komme ich zu 5.)
>
> Es ist für einen Schüler einfach vertane Zeit, Smalltalk zu lernen, wenn er
> nach Schulschluß einen Nebenjob in einer Programmierfirma mit C++0x oder Java
> haben könnte.

Das mag sein, aber derartige Schüler sind in meinen Augen eine recht
kleine Minderheit (diejenigen, die dann z.B. bei dir an der Uni
aufschlagen), die sich ohnehin schon selber mit C++ oder C#
auseinandergesetzt hat, ehe sie bei mir dann in der 10. Klasse eine
objektorientierte Sprache lernen soll. Bei der Mehrheit der Schüler ist
das zentrale Lernziel m.E. weniger das Beherrschen einer Sprache, als
vielmehr die Einsicht, daß sich die Planungs- und Modellierungsansätze,
die hier trainiert werden, auch im richtigen Leben (jenseits von Bits und
Bytes) sinnvoll einsetzen lassen.

Schöne Grüße

Markus

On Fri, 5 Nov 2010, R. Romeike wrote:

> Ein "Werkzeugstreit", zumal solch ähnlicher Werkzeuge, bringt uns aber
> nicht weiter. Wichtig wäre es wirklich aufzuzeigen, wie man mit
> Etoys/Squeak guten weiterführenden Informatikunterricht machen kann. Und
> warum auch nicht als Fortführung nach einem Einstieg mit Scratch? Die
> Grundlagen sind ähnlich und wären gelegt. Leider habe ich noch nicht
> viele überzeugende Beispiele gesehen, würde mich aber über solche freuen!

Das ist genau der Weg, den wir bei uns bestreiten:

7. Klasse, einstündig:   Ablaufmodellierung mit Scratch

10. Klasse, zweistündig: OOM mit Etoys, dann OOP mit einer 'klassischen'
Programmiersprache. Bei mir wird es diesmal Smalltalk mit Pharo.

Hoffentlich schaffe ich es dieses Jahr, mein Programm ordentlich und
veröffentlichbar zu dokumentieren.

Ich selber empfinde Scratch als einfacher und robuster zu bedienen, für
die Schüler auch übersichtlicher und weniger fehlerträchtig, was mir als
Lehrer das Arbeiten erleichtert. Die Etoys muß man als Lehrer schon ganz
schön gut kennen, wenn man Schüler als erstes darauf losläßt. Da tauchen
doch immer wieder Smalltalk-Fehlermeldungen auf, die auch mich noch zum
Rätseln bringen. In der 10. Klasse macht mir das aber nichts, weil es eine
Gelegenheit ist, den Schülern auch schon einmal die Smalltalkebene hinter
Etoys zu zeigen. Außerdem sind sie da schon routinierter und haben von
Scratch her ein Gefühl, wie das im Prinzip gehen muß. Trotzdem bleibt es
spannend, wenn sich ein Projekt plötzlich nicht mehr speichern lassen will
oder Schüler kreativ die Etoys-Kacheln per Halo verstümmelt haben.

Schöne Grüße

@Ralf: Könntest du mir die Artikel bitte schicken. Danke.

Markus Schlager schrieb:
> Das ist genau der Weg, den wir bei uns bestreiten:
>
> 7. Klasse, einstündig:   Ablaufmodellierung mit Scratch
Auf dem Treffen beim HPI hat Jens Mönig den Nachfolger von Scratch
vorgestellt.

Vorteil: Das didaktisch sehr wertvolle Prinzip der vorgeformten
verschiebbaren, wie Lego ineinander greifenden Logikkacheln hat er auf
ganz Smalltalk ausgeweitet.
Also nicht nur, dass man in Scratch nun - was ja auf der Idee von Etoys
mit seinen Logikkacheln basiert - in einer eigenen
Grafikprogrammiersprache durch schubsen von Kacheln neue Algorithmen
generieren kann, sondern er hat das komplette, darunterliegende
Smalltalk in Logikkacheln überführt, die man hin- und her- schubsen kann.
Diese "Zusatz-GUI" hat er "Elements" genannt.". Sie müsste eigentlich
leicht auf jeden Smalltalk Dialekt übertragbar sein, der auf einem alten
Squeak basiert. (Pharo, ...)

Für mich war das Programmieren wie von einem anderen Stern. (und das
nach 21 Programmiersprachen, die ich inzwischen so gelernt habe).

Das Besondere:

Normalerweise kann man in Etoys oder Scratch keine Funktionen
definieren, ohne in den Quellcode eingreifen zu müssen. Das ist häßlich,
weil man das Konzept des Herumschubsens der Kacheln verlassen muss. Also
didaktisch gesehen ein Bruch. Jens hat es geschafft, dass man auch
Funktionen jeder Art, z.B. auch anonyme Funktionen als sog. "first class
objects" behandeln und als Logikkacheln schubsen kann.

So kann man z.B. als Lehrer unter Scratch mit den Kiddies - ohne
überhaupt die Scratch - typische GUI verlassen zu müssen, Mandelbrot
Fraktale auf den Bildschirm zaubern.

In den Logikkacheln von Scratch stecken ja unsichtbar eine Vielzahl von
impliziten, verborgenen Logiken, die der Anwender nicht sieht, von denen
er nichts ahnt.

Wenn ich aber will, kann ich mir genau diese impliziten Logiken der
Logikkacheln selber als Logikkacheln wiederum anzeigen lassen. Jens
Mönig hat es geschafft, die Programmiersprache Smalltalk selber als
System aus Logikkacheln erscheinen zu lassen, wobei der Übergang zur
grafischen "Kunstsprache" Scratch fliessend wird.

Das Konzept der Logikkacheln ist also selber zu einem "general purpose
system" geworden, mit dem sich alles programmieren lässt. Sogar kann man
mit Jens' System selber neue Logikkacheln erzeugen, ohne die GUI und das
Konzept der Logikkacheln verlassen zu müssen.

Ich kann also jede Abstraktionsebene in Smalltalk nun mit Schubsen von
Logikkacheln bewältigen. Nun auch die unterste, Ebene, also den
Smalltalk Code selber.

Dahinter steckt schon eine ganz erhebliche Denkleistung, die logischen
Elemente der Programmiersprache Smalltalk mit den Logikkacheln von
Scratch so nahtlos zu verbinden. Eine Denkleistung, die vor ihm, denke
ich, keiner der Freaks aus der Informatik je geschafft hat.

Insgesamt eine sehr, sehr beachtliche, eine großartige, philosophische
Denkleistung. Angewandte Modelltheorie pur. Da musste wohl erst ein
Jurist ankommen, um den Informatikern zu zeigen, wo der Hammer hängt.

Dieses System ist nun unter dem Namen "Build Your Own Blog" ("BYOB" -
für Google) frei downloadbar.

Have fun, Guido Stepken

Guido Stepken <[hidden email]> writes:

Hallo Guido,

Einige Anmerkungen zu deinen Kopfschmerzen

> 1. Einmal Smalltalk - die wollen nie wieder andere Programmiersprachen
> erlernen!

Das stimmt so nicht. Nur müssen die anderen Sprachen auch
überzeugen. Ich lerne gerade SBCL und auf Scala habe ich auch ein Auge
geworfen. Ganz so ist es also nicht. :)


> 2. Smalltalk ist Hacken, kein modernes Software Engineering, wie man
> z.B. mit JAVA und BlueJ lernen kann.

Pauschalurteil ohne Belege

Auf dieser Seite findet google Alan Kay, Pharo, Smalltalk, etc.

http://softwareengineering.vazexqi.com/


> 3. Multiprozessorunterstützung fehlt bislang (RoarVM kommt wohl bald)

Schön wäre das schon, aber nur ein Bruchteil aller Anwendungen braucht
das überhaupt. Und Videoschnitt macht man nicht mit Smalltalk :)

> 4. Erziehung zur Frusttrationstoleranz. Sich mal auch "durchbeissen
> müssen" durch Bits und Bytes

Slang, Plugins, FFI

> 5. Sinnlos erworbenes Wissen, da kein Entscheider Squeak einsetzen wird.

Was braucht man Entscheider, wenn man sich selbstständig macht?  Der
Kunde/Entscheider muss nicht mal wissen, dass er eine Smalltalklösung
geliefert bekommt. Und Banken und Versicherungen sehen es mitunter ganz
gern, dass man Smalltalk einsetzt.

> In Kürze werden alle Computer Mehrprozessorsysteme sein, ARM, INTEL,
> GPGPU's sogar massiv. Ein Parallelrechner mit 512 Prozesoren ist für
> unter 1000€ zu haben!

Ja, und der 387 wurde 1987 vorgestellt. Die zusätzliche Rechenkraft hat
kaum einer genutzt. Ist dann auch wieder vom Markt verschwunden. Die PS3
hat zwar 5 oder 6 Cores und die werden auch genutzt. Der Aufwand ist
aber erheblich und die Zielgruppe sehr klein.

Die heutige Rechenleistung wird im Bereich Codecs, Forschung, Spiele
gefordert. Alles keine typischen Smalltalkfelder.

Es wird sich zeigen, was der eingebaute Parallelismus in der Praxis
bringt.

> Es ist für einen Schüler einfach vertane Zeit, Smalltalk zu lernen,
> wenn er nach Schulschluß einen Nebenjob in einer Programmierfirma mit
> C++0x oder Java haben könnte.

http://c2.com/cgi-bin/wiki?MakeItWorkMakeItRightMakeItFast

Ich glaube kaum, dass ein Lehrer im Informatikunterricht C++ in der
gleichen Zeit in dem Umfang unterrichten könnte, wie er Smalltalk
vermitteln kann. Aber wir haben ja eine ausreichende Lehrerdichte hier
auf der Liste. Kann sich ja mal jemand dazu äußern.

Dazu kommt "Lines of code not written"

MakeItWork - MakeItRight. Scheitert da eher der C++ oder der
Smalltalk-Programmierer?

Enno

On Fri, 05 Nov 2010 01:38:23 +0100
Guido Stepken <[hidden email]> wrote:

> 6 Dinge allerdings machen mir Kopfschmerzen:

alles nur Einbildung ;->

> 1. Einmal Smalltalk - die wollen nie wieder andere Programmiersprachen
> erlernen!

aber nur, bis sie nach ein bisschen Spielen mit dem Scratchboard
bei Arduino & Co gelandet sind, dann geht's an C und Assembler.

> 2. Smalltalk ist Hacken, kein modernes Software Engineering, wie man
> z.B. mit JAVA und BlueJ lernen kann.

So ein Schmarrn, mit Verlaub. Der Satz hat zu viele "ist". Meinst
du vielleicht

"Smalltalk wird als Hacken unterrichtet, ohne auf Ideen des
modernen Software Engineering einzugehen"?

In dem Fall liegt's am Lehrer, der viel zu oft Opfer des Lehrplans
ist. Oder es ist einer der Sorte, die jede Sprache als "Hacken"
rüberbringen.

> 5. Sinnlos erworbenes Wissen, da kein Entscheider Squeak einsetzen wird.

Ob Wissen sinnlos erworben wurde, weiß man erst, nachdem man seine
Existenz beendet hat, vorher nicht. Ich persönlich sehe meine Bildung
mit Pfadfinder-Philosophie: "Allzeit bereit" oder, noch passender
"Luck favors the prepared"

Beispiel: In meiner Schulzeit hab ich Programmieren auf einem ZX81
gelernt, BASIC und Assembler. Die Kiste ist dann irgendwann verschwunden,
16-, 32- und neuerdings 64-bit Prozessoren erobern den Markt. War das
damals "sinnlos"?

Nö.

Weil ich vor knapp 30 Jahren Programmieren in der Schuhschachte (1k RAM)
mit der Pinzette (Z80 Assembler, "2A 0C 40" anybody?) gelernt habe,
kann ich heute Aufträge im embedded-Bereich an Land ziehen.

> 6. Zu hohes Abstraktionsniveau für Einsteiger

Das ist so wie beim Autofahren, nicht?

> Es ist für einen Schüler einfach vertane Zeit, Smalltalk zu lernen, wenn
> er nach Schulschluß einen Nebenjob in einer Programmierfirma mit C++0x
> oder Java haben könnte.

Hmpf. Und wenn das erste halbe Jahr vorbei ist?

Schau mal auf M. Felleisens Seite
        http://www.ccs.neu.edu/home/matthias/
unten das letzte Zitat an:

On Teaching Programming: Wir sind froh, dass die Absolventen schon Java können. Programmieren müssen wir denen halt noch beibringen. overheard in a German firm, via Mike Sperber

Wenn im Gymnasium schon "Programmieren" unterrichtet werden soll,
dann bitte im Sinne von "Bildung" und nicht von "Ausbildung".

s.