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.
Ü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&sou...
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:
[...]
- 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
Guido Stepken gstepken@googlemail.com writes:
Hallo Guido,
Einige Anmerkungen zu deinen Kopfschmerzen
- 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. :)
- 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/
- 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 :)
- Erziehung zur Frusttrationstoleranz. Sich mal auch "durchbeissen
müssen" durch Bits und Bytes
Slang, Plugins, FFI
- 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.
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.
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 gstepken@googlemail.com wrote:
6 Dinge allerdings machen mir Kopfschmerzen:
alles nur Einbildung ;->
- 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.
- 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.
- 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.
- 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.
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:
- 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
squeak-ev@lists.squeakfoundation.org
-
Andreas Raab -
Enrico Schwass -
Guido Stepken -
Markus Schlager -
R. Baumann -
R. Romeike -
Stefan Schmiedl