[Squeak-ev] Scratch in Deutschland/Österreich/Schweiz - und bei squeak.de?

[stepken]

Markus Schlager schrieb:
> Also ich wäre in der Tat ausgesprochen an diesen Tutorien interessiert,
> stehe ich doch konkret vor dem Problem, einen guten Weg zu finden, meinen
> Schülern Dinge beizubringen, die ich selbst nicht kann. Da ist es immer
> gut, allein schon zu sehen, auf welche Ideen andere für vergleichbare
> Zwecke kommen, die offensichtlich mehr Ahnung von der Materie haben.
>
>   
Ich frage mich hier ernsthaft, wieviel Ahnung einige Smalltalk Hacker 
wirklich von Didaktik und den wirklichen Problemen mit Squeak im 
Schulunterricht haben.
> * 'Mein Ding' besteht im Moment darin, Wege zu finden, mit Squeak im
>   Unterrichtseinsatz am Gymnasium vernünftige Dinge zu tun, die sich mit
>   dem Lehrplan vertragen. Zielgruppe sind die Jahrgangsstufen 6,7,9,10.  
>   Die Lehrpläne sind im Internet veröffentlicht.
Wo genau? Das würde mich auch noch interessieren, damit ich meine 
Tutorials direkt schon ordnen kann.
>   Was ich z.B.  
>   ausgesprochen gut brauchen könnte, wären
> - Datenflussdiagramme, die etwas tun (z.B. rechnen, Strings verarbeiten,
>   Skripte starten... -- rechnen können meine Diagramme schon)
>   
Ist Dir schon einmal aufgefallen, diese frappierende Ähnlichkeit 
zwischen den ETOYS / Scratch Programmierkacheln und Nassi/Shneidermann 
Diagrammen?

http://de.wikipedia.org/wiki/Nassi-Shneiderman-Diagramm

Und da steht auch drin, dass sich diese Diagramme nicht für 
Objektorientierung eigenen, wofür dann UML 2.0 entwickelt wurde. 
Schluss: ETOYS ist zwar objektorientiert geschrieben, selber aber kann 
man damit keine objektorientierte Programmierung lernen.

Und tatsächlich ist es so, dass Du mit Scratch/ETOYS halt nur an ganz 
wenigen Stellen was von OO (Polymorphie) merkst.

Viel interessanter ist es, Petri-Netze der Programmstrukturen zuvor zu 
malen, z.B. mit WoPeD. Da kann man dann auch noch die Prozesslogiken 
austesten. Die Zukunft geht genau dort hin. Wenn ich Programmcode sehe, 
bin ich geneigt, daraus erst einmal die Entscheidungslogiken zu 
extrahieren (das geht z.B. mit Python Smalltalk oder Ruby sehr gut, 
daraus dann XML zu extrahieren und nach PNML zu konvertieren, damit man 
die Programmflusslogiken, also den Möglichkeitsraum der Zustände, die 
ein Programm annehmen kann, analysieren und Fehler nachweisen kann, z.B. 
mit WoPeD

Es gibt da eine Reihe von Tools für verschiedene Programmiersprachen, wo 
es um die Sicherstellung der logischen Fehlerfreiheit von Programmen und 
ihren impliziten Ablaufslogiken geht. Ich habe z.B. mal so etwas 
analysiert, als es um mögliche Deadlocks beim Multiprocessing ging. Die 
Anregung war das "Philosophenproblem", welches mit Petrinetzen simuliert 
werden kann.
> - Visualisierungen von Smalltalk-Code in Form von UML-Diagrammen,
>   idealiter auch so, daß die UML-Diagramme der Ausgangspunkt sind und
>   entsprechenden Smalltalk-Code generieren. BlueJ ist hier die
>   Standardkonkurrenz.
>   
Ochja. Rational Rose, nun IBM, Plugin in Eclipse ist ja auch ladbar aus 
dem Internet. Nur - die Einarbeitungszeit beträgt mind. 1 Jahr für 
ausgebildete Informatiker. Muss wirklich mit UML Kanonen auf Kinder 
geschossen werden? Ich denke nicht. Nassi-Shneidermann genügt vollauf.
> - Ideen für schlaue Projekte, die sich etwa mit einer 10. Klasse bei
>   zweistündigem Informatikunterricht sinnvoll realisieren lassen.
Recht wenig. Ich weiss aus Berichten aus Schulen, dass viele Lehrer mit 
BlueJ und Java arbeiten. Und auch da treten unglaublich viele Probleme 
auf, z.B. fängt es damit an, dass Kinder kein Windows, sondern Mac OS X 
zuhause haben, und nicht wissen wie sie die Library vom Lehrer in den 
Classpath einbinden sollen. Lehrer weiss es auch nicht. Ich rate: 
Weniger ist mehr. Lieber anspruchsvollere Aufgaben in Scratch und dann 
ETOYS, als mit UML anfangen. Nassi genügt vollauf, um Denkstrukturen zu 
trainieren. Man kann mal auch mal das eine oder andere Flussdiagramm  in 
UML übertragen. Aber nicht den Unterricht damit gestalten!

Datenbanken .... tsss. Die müssen erst einmal Mengenlehre nochmal 
wiederholen, bevor man die an SQL ransetzt. Und dann kommt noch dazu, 
das SQL eben OO untypisch ist, siehe "impedance missmatch":
http://www.google.de/search?q=%22impedance+mismatch%22+stepken&hl=de&client=opera&rls=de&hs=sHJ&lr=lang_de&sa=X&oi=lrtip&ct=restrict&cad=9


Gru/3, Guido Stepken