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

[Klaus D. Witzel]

Garnicht mal so schlecht, Guido Stepken, nur weiter so :)

Cheers
Klaus

On Thu, 22 Nov 2007 22:14:52 +0100, stepken wrote:

> 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