Der Grund, warum ich auf Smalltalk gestoßen bin, sind zwar die eToys, aber die sind in der Unterstufe relevant. Dort lernen die Schüler (bei mir mittlerweile mit Scratch) die Grundstrukturen imperativer Programme. In Klasse 10 soll dann das objektorientierte Paradigma im Mittelpunkt stehen, und Squeak bietet in meinen Augen die schöne Möglichkeit, hier das Innenleben des aus der Unterstufe vertrauten Werkzeugs zu erkunden. Deshalb probiere ich das dieses Jahr aus.
Achgottchen... erst imperative Programmierung und dann OO? Völlig falsche Reihenfolge, aus didaktischer Sicht, das versaut die Denkstrukturen.
Z.B. werden zu Beginn immer Scheifen programmiert. Wozu gibt es das
"foreach element in liste von Objekten machmalwasdamit ..." ... Iteratoren, wie in Squeak ETOYS auch. Du hast wegen Schleifen konstrukten Scratch eingeführt. Nur - man braucht sie einfach nicht, sie sind auch in OO-Programmierung unbedingt zu vermeiden ... Ich brauche mir nur OO-Code anzuschauen, und wenn ich da irgendwelche Zähl-Schleifen drin finde, weiß ich - Der Mensch hat OO überhaupt nicht verstanden - ein Grund, ihn/sie aus dem Team zu schmeißen ...
Was ich gerne wüßte - eine Frage an die produktiv arbeitenden Squeaker:
Wie sieht der typische Workflow bei GUI-Programmierung in Squeak aus?
*lach* Hmm, mir scheint, daß Du versuchst, "imperatives/prozedurales" Programmieren in reine OO-Denke hinein zu tragen ... In XING ist ein interessanter Thread , schon was älter über "Angestaubtes Smalltalk" ...
Baut ihr GUIs üblicherweise via Maus aus Morphen zusammen und erzeugt daraus dann irgendwie neue Klassen, oder ist der typische Weg doch der, alles quelltextorientiert im Browser zu konzipieren? (Nach Erlernen der Grundkonzepte, sollen die Schüler schließlich ein 'typisches' Projekt umsetzen.)
Ich schreibe mir alles mit reinem Smalltalk zusammen, und wenn das Objekt auf dem Schirm erscheint, gehe ich in Neuer Morph-> in Datei speichern, lege ihn außerhalb des Images ab, oder ziehe ihn in eine neue Flap hinein ...findest Du im OLPC Image 1111 + Updates unter Objekte -> Connectoren. Die .morph - Objekte kannst Du dann auch in andere Images hineinziehen. Z.B. haben wir mal Autorennen gemacht, mit 4 Personen, jeder hat sein Auto konstruiert, welches andere Auto's auf einer blauen Fahrbahn überholen können soll, natürlich vorausschauend und kollisionsfrei ;-) Was great fun ....
Warum ausgerechnet Squeak 3.9:
Die eToys sind hier nur eine Randerscheinung. Die Ablaufmodellierung soll in einer typischen Programmierumgebung erprobt werden, also geht es um Smalltalk.
Nun, Du kannst Dir ja den Code anschauen, welcher ein Morph erzeugt hat, und dann "händisch" weiter programmieren ... so wie Du die Squeak - Uhr ja kopiert hast, und dann veränderst ...
Soviel ich auf den Mailinglisten gelernt habe, sind dafür die images von squeak.org 'zuständig'. Abgesehen davon bin ich zu wenig Fachmann, um die Qualitäten verschiedener images wirklich würdigen zu können.
Hmmm, das OLPC - Image z.B. hat eine "repeattimes" - Kachel, da hättest Du dann wohl Deine Schleifen ... Was eigentlich kann Scratch nun besser oder mehr als ETOYS? Mir erscheint es nur "hübscher" ...
Unterrichtlicher Kontext:
Das große Thema in den vier Unterrichtsjahren heißt Modellierung unter objektorientierten Vorzeichen. Was die Schüler lernen sollen, ist übersichtliche und strukturierte Darstellung von 'Information'. Kurz gesagt, ist das wichtigste der Umgang mit verschiedenen Formen von Diagrammen und die Erkenntnis, daß diese ein richtig wertvolles Vehikel sind. Alles was mit Rechnern zu tun hat (also z.B auch das Programmieren) ist ein *Neben*produkt des Unterrichts.
Wo sind da die Erfolgserlebnisse?
Immer vorausgesetzt, daß die Schüler überhaupt qualifiziertes Lehrpersonal haben, lernen sie:
- Klasse (bislang 10. Klasse):
Klassen und Objekte. Dazu gehört ganz massiv (vereinfachtes) UML, an sich auch Datenkapselung (wie von Dir angesprochen) und das Nachrichtenkonzept). Umgesetzt wird das (in meinen Augen eher ungeeigneterweise) mit Vektorgraphiken, Textdokumenten, Präsentationen und Hypertext.
Geht alles mit Squeak ... Textverarbeitung, wo die Buchstaben sogar einen selbstgemalten Wasserfall herunterfließen ... Präsentationen? -> Schau Dir mal in OPLC 1111 + Updates den Ereignisrecorder oder
- Klasse (im Moment eben auch 11. Klasse):
Ablaufmodellierung, insbesondere die klassischen imperativen Strukturen.
Ich würde mich weigern, so etwas überhaupt noch zu unterrichten ...
Im Prinzip z.B. eine Sache für eToys, denen bislang aber die Schleifen fehlten.
dank Iteratoren ist nix mehr mit Schleifen. Gottseidank!
Scratch paßt hier wie die Faust aufs Auge.
Es passt auf Deine mentalen Modelle, Deine Denkstrukturen. Nur - Deine Schüler werden versaut mit veralteten Denkweisen ... das hat keine Zukunft ...
Von der Modellierung her propagieren die Schulbücher an dieser Stelle Struktogramme - ich selber finde Flußdiagramme 'besser'.
Typisch für Menschen, die OO noch nicht so verinnerlicht haben ... Ereignisse (Events) Nachrichten, Methoden .... wie willst Du das mit Flußdiagrammen überhaupt darstellen?
- Klasse (ab 2007/8):
Datenflüsse und Datenmodellierung, insbes. auch ER-Modell und Datenbanken
Auweia. Entity-Relationship - Diagramme ... bei OO-Datenbanken, siehe Magma völlig überflüssig ...
10, Klasse (ab 2008/9, im Moment auch noch 11. Klasse):
OOM und OOP, mehr 'M' als 'P'. Konkrete Umsetzung steht noch aus. (Wer Smalltalk propagieren will, kann gern die Schulbuchverlage anbohren.)
Wesentliche Grundkonzepte sind den Schülern, für die das Tutorial gedacht ist, also bereits vertraut (etwas das Objekt-Konzept). Zudem gibt es im Unterricht auch einen Lehrer, der den roten Faden etwas ziehen kann.
Java ist gegen Smalltalk völlig frustrierend ... Ruby, Python gehen auch noch, und dann hört es schon auf ... alles andere ist meiner Meinung nach völliger Schrott. Wenn ich noch an meine C++ - Kurse denke, die ich gehalten habe ... da mußt Du oft erst 2 A4 - Seiten tippen, um endlich die Datenmodelle so zu haben, wie Du sie brauchen kannst, siehe STL, und in Smalltalk brauche ich 3 Zeilen ...
Ein Vergleich mit anderen Programmiersprachen ist in dem Kontext bedeutungslos, weil das hier für die Mehrheit der Schüler die erste Sprache ist, die sie überhaupt lernen.
Umso besser. Es wird Zeit, daß die neue Generation auf Smalltalk umsteigt ... Exupery ist ja auch ein Smalltalk - Maschinencode - Compiler, der schon recht fix läuft, aber noch in Entwicklung ist ... Speed ohne Ende.
Squeakspezifische Spezialtricks sind auch sekundär, da die Schüler primär 'typische' Dinge lernen sollen. Freilich sind sie ein wenig das Salz in der Suppe, aber an der Stelle muß ich auch offen erklären, daß ich die wenigsten selbst kenne. Squeak eröffnet sich mir auch erst nach und nach. (Da geht es unter anderem auch noch um so Probleme wie sich nicht mehr öffnen oder speichern lassende Projekte - 'Unterricht in Echtzeit' ;-) )
Verschachtelte Projekte? Ich habe für Unterricht immer schittweise ein Projekt sauber vorgemacht, sodaß der Schüler an jeder Stelle neu einsteigen kann....
Viele Grüße, Guido
stepken wrote:
Der Grund, warum ich auf Smalltalk gestoßen bin, sind zwar die eToys, aber die sind in der Unterstufe relevant. Dort lernen die Schüler (bei mir mittlerweile mit Scratch) die Grundstrukturen imperativer Programme. In Klasse 10 soll dann das objektorientierte Paradigma im Mittelpunkt stehen, und Squeak bietet in meinen Augen die schöne Möglichkeit, hier das Innenleben des aus der Unterstufe vertrauten Werkzeugs zu erkunden. Deshalb probiere ich das dieses Jahr aus.
Achgottchen... erst imperative Programmierung und dann OO? Völlig falsche Reihenfolge, aus didaktischer Sicht, das versaut die Denkstrukturen.
Z.B. werden zu Beginn immer Scheifen programmiert. Wozu gibt es das
"foreach element in liste von Objekten machmalwasdamit ..." ... Iteratoren, wie in Squeak ETOYS auch. Du hast wegen Schleifen konstrukten Scratch eingeführt. Nur - man braucht sie einfach nicht, sie sind auch in OO-Programmierung unbedingt zu vermeiden ... Ich brauche mir nur OO-Code anzuschauen, und wenn ich da irgendwelche Zähl-Schleifen drin finde, weiß ich - Der Mensch hat OO überhaupt nicht verstanden - ein Grund, ihn/sie aus dem Team zu schmeißen ...
Ja, das mag in Entwicklerteams so funktionieren. Ich weiß ja nicht, wie viel Erfahrung du mit dem deutschen Bildungssystem hast, aber es gibt Rahmenrichtlinien, an die sich der Lehrer halten muss und die in jedem Bundesland wieder anders sind. Du magst ja recht haben mit deinen Ausführungen und das ist nicht die reine Smalltalk-Lehre, es geht ja nicht darum, die Schüler alle zu Programmierern zu machen. Die Reihenfolge, in der Stoff behandelt wird, ist in den Rahmenrichtlinien festgelegt (also, dass z.B. zuerst die Grundstrukturen drankommen). Und das ist auch nichts Negatives. Hast du mal das Buch von Stephane Ducasse (Squeak Learning Programming with Robots) gelesen? Er führt da auch wunderbar diese Grundstrukturen ein und das ist einfach etwas, was Schüler in diesem Alter erfassen und verstehen können. Das ist doch der Zweck der Programmiersprache im Unterricht, die Dinge, die man programmiert, zu verstehen.
Unterrichtlicher Kontext:
Das große Thema in den vier Unterrichtsjahren heißt Modellierung unter objektorientierten Vorzeichen. Was die Schüler lernen sollen, ist übersichtliche und strukturierte Darstellung von 'Information'. Kurz gesagt, ist das wichtigste der Umgang mit verschiedenen Formen von Diagrammen und die Erkenntnis, daß diese ein richtig wertvolles Vehikel sind. Alles was mit Rechnern zu tun hat (also z.B auch das Programmieren) ist ein *Neben*produkt des Unterrichts.
Wo sind da die Erfolgserlebnisse?
Immer vorausgesetzt, daß die Schüler überhaupt qualifiziertes Lehrpersonal haben, lernen sie:
- Klasse (bislang 10. Klasse):
Klassen und Objekte. Dazu gehört ganz massiv (vereinfachtes) UML, an sich auch Datenkapselung (wie von Dir angesprochen) und das Nachrichtenkonzept). Umgesetzt wird das (in meinen Augen eher ungeeigneterweise) mit Vektorgraphiken, Textdokumenten, Präsentationen und Hypertext.
Geht alles mit Squeak ... Textverarbeitung, wo die Buchstaben sogar einen selbstgemalten Wasserfall herunterfließen ... Präsentationen? -> Schau Dir mal in OPLC 1111 + Updates den Ereignisrecorder oder
Ich finde schon, dass Schüler auch mit herkömmlichen Textverarbeitungssystemen umgehen können sollten. Glücklicherweise heißt das nicht mehr unbedingt, dass alle Word lernen, sondern bei guten Lehrern schon, dass man die Grundprinzipien lernt und dann auch recht schnell ein neues System bedienen kann.
- Klasse (im Moment eben auch 11. Klasse):
Ablaufmodellierung, insbesondere die klassischen imperativen Strukturen.
Ich würde mich weigern, so etwas überhaupt noch zu unterrichten ...
Im Prinzip z.B. eine Sache für eToys, denen bislang aber die Schleifen fehlten.
dank Iteratoren ist nix mehr mit Schleifen. Gottseidank!
Scratch paßt hier wie die Faust aufs Auge.
Es passt auf Deine mentalen Modelle, Deine Denkstrukturen. Nur - Deine Schüler werden versaut mit veralteten Denkweisen ... das hat keine Zukunft ...
Du urteilst ganz schön hart. Das mag aus deiner Sicht ja alles stimmen, aber im Schulsystem kann man nicht machen, was man will, selbst wenn man davon überzeugt ist, recht zu haben. Veränderungen erreicht man nur schrittweise, frag mal die Leute, die das seit Jahren versuchen! Man muss sich da mit Beamten auseinandersetzen, die den Kern des Problems gar nicht erfassen. Es wird an verschiedenen Stellen versucht, Smalltalk und Squeak in die Schulen zu bringen und das ist eine Sysiphos-Arbeit. Es ist ein Wunder, dass noch nicht alle aufgegeben haben. Wenn man dann noch kommt und alles umwerfen will, weil es veraltet ist und keine Zukunft hat, braucht man entweder einen Schulleiter, der einem freie Hand lässt (was wohl kaum vorkommen dürfte), oder eine Privatschule, in der man sich zwar auch an die Vorgaben der Rahmenrichtlinien halten muss, aber viel mehr Gestaltungsspielraum hat oder man kann gleich einpacken. Also versucht man es "durch die Hintertür", orientiert sich an den Vorgaben und benutzt alternative Software.
Von der Modellierung her propagieren die Schulbücher an dieser Stelle Struktogramme - ich selber finde Flußdiagramme 'besser'.
Typisch für Menschen, die OO noch nicht so verinnerlicht haben ... Ereignisse (Events) Nachrichten, Methoden .... wie willst Du das mit Flußdiagrammen überhaupt darstellen?
Ich weiß es aus eigener leidvoller Erfahrung, wie lange es dauert, ehe man das verinnerlicht hat, ich bin noch nicht an dem Punkt, dass ich sagen würde, ich habe es vollkommen verstanden. Und so geht es natürlich jedem Lehrer. Das ist für mich das Hauptproblem, zu vermitteln, was das Besondere an Squeak und Smalltalk ist, eben weil es so anders ist als alle anderen Sprachen und Werkzeuge. Es wird als "Spielzeug" abgetan, egal ob ich Etoys oder Botsinc mache. Und dann geht es in der Schule eben nicht nur um die eine Programmiersprache, sondern um Modellierung, da hilft eine Vielfalt, um abstrahieren zu lernen.
- Klasse (ab 2007/8):
Datenflüsse und Datenmodellierung, insbes. auch ER-Modell und Datenbanken
Auweia. Entity-Relationship - Diagramme ... bei OO-Datenbanken, siehe Magma völlig überflüssig ...
Ja, schön, wenn du denn OO-Datenbanken nimmst. Du kannst aber nicht auf einen Schlag alles Bekannte abschaffen und durch komplett Neues ersetzen. Er-Diagramme sind wieder eine Methode, Zusammenhänge zu veranschaulichen und was ein Schüler z.B. dabei lernt, ist Modellierung. Noch ein bisschen Kontext: ich unterrichte Lehrer (berufsbegleitend) an der Uni, habe es geschafft, dass sie auch Squeak-Etoys kennen lernen und einige setzen es sogar im Unterricht ein. Ich habe auch schon selbst Schülerkurse mit Etoys gemacht. Selbst bin ich Informatikerin und befasse mich seit einiger Zeit etwas mit Informatik-Didaktik.
Viele Grüße, Rita
stepken schrieb:
Achgottchen... erst imperative Programmierung und dann OO? Völlig falsche Reihenfolge, aus didaktischer Sicht, das versaut die Denkstrukturen.
Z.B. werden zu Beginn immer Scheifen programmiert. Wozu gibt es das
"foreach element in liste von Objekten machmalwasdamit ..." ... Iteratoren, wie in Squeak ETOYS auch.
Ich würde das auch eine Schleife nennen. Was denn sonst? Und Abläufe muss man in Smalltalk auch programmieren, also begriffen haben, was der Unterschied von einer Sequenz, Verzweigung oder eben Schleife ist.
Natürlich ist es schön, wenn man zeigen kann, dass man in den neueren Sprachen oft nicht mehr so denken muss, wie ein Prozessor/Computer. Wenn es geht, vermeide ich die Zahlen auch.
Ich brauche mir nur OO-Code anzuschauen, und wenn ich da irgendwelche Zähl-Schleifen drin finde, weiß ich - Der Mensch hat OO überhaupt nicht verstanden - ein Grund, ihn/sie aus dem Team zu schmeißen ...
OK, ich schmeiß dann alle Schüler raus, die noch so denken ;-). Ich denke, man muss beides kennen, ausprobiert haben. Dann wird man auch in vielen Fällen wirklich begründet dafür sein, _nicht_ stur zu zählen, weil es verständlicher, fehlersicherer ist. Andererseits mag es Fälle geben, wo eine Zählschleife einfacher zu verstehen ist. Über Stil kann man immer endlos streiten. Beispiele und Gegenbeispiele überzeugen.
Rita schrieb:
Ja, das mag in Entwicklerteams so funktionieren. Ich weiß ja nicht, wie viel Erfahrung du mit dem deutschen Bildungssystem hast, aber es gibt Rahmenrichtlinien, an die sich der Lehrer halten muss und die in jedem Bundesland wieder anders sind. Du magst ja recht haben mit deinen Ausführungen und das ist nicht die reine Smalltalk-Lehre, es geht ja nicht darum, die Schüler alle zu Programmierern zu machen. Die Reihenfolge, in der Stoff behandelt wird, ist in den Rahmenrichtlinien festgelegt (also, dass z.B. zuerst die Grundstrukturen drankommen). Und das ist auch nichts Negatives. Hast du mal das Buch von Stephane Ducasse (Squeak Learning Programming with Robots) gelesen? Er führt da auch wunderbar diese Grundstrukturen ein und das ist einfach etwas, was Schüler in diesem Alter erfassen und verstehen können. Das ist doch der Zweck der Programmiersprache im Unterricht, die Dinge, die man programmiert, zu verstehen.
100% deiner Meinung, Rita.
Schöne Grüße,
Christian
squeak-ev@lists.squeakfoundation.org