Hallo Uwe,

ich moechte unbedingt auf Dein Kochrezept reagieren: sich selber kochende Kartoffeln oder sich selber servierende Essen sind mir sehr unheimlich - aber so wird objekt-orientierte Programmierung offensichtlich meistens gelehrt, verstanden und implementiert. "Zauberei" halt...

Warum lassen wir die Kartoffel nicht einfach was sie ist? - Ein "Nahrungsmittel" bzw. ein "Material". Von sich aus kann diese Kartoffel - zumindest in dem von Dir beschriebenen Kontext - ueberhaupt nichts. Dazu bedarf es bestimmter Werkzeuge, die den Zustand der Kartoffel veraendern koennen - und natuerlich einen Akteur, der Tools auf die passenden Materialien anwendet - der das Messer nimmt und damit die Kartoffel schaelt und / oder in Viertel schneidet.

Automaten koennen die zuvor entworfenen Tools (Werkzeuge) nehmen und die Kartoffeln schaelen (lassen), Wasser und Kartoffeln in einen Topf geben, Hitze hinzufuegen und das ganze solange kochen lassen, bis die Kartoffeln den Zustand "gekocht" erreichen. Ein weiterer Automat koennte aehnliches mit dem Fleisch machen (lassen). Und als letztes nimmt ein Automat die beiden ersten Automaten, um ein (fast) vollstaendiges Gericht zu servieren.

Mit den Automaten waeren wir dann wieder bei der prozeduralen Entwicklung - so schlecht ist dieser Programmier-Stil nun wirklich nicht.

Wir muessen nicht jedesmal eine neue Kartoffel erfinden, nur weil wir eine andere Art der Zubereitung oder ein neues Menue entworfen haben.

Dieses "Werkzeug Automat Material" Paradigma (WAM) stammt urspruenglich von Heinz Zuellighoven. Wenn ich es recht sehe, ist er zwar heute der Typ-Sicherheit wegen ein Verfechter von Java, aber seine ersten praktischen Erfahrungen mit kommerziellen, objekt-orientierten Software-Projekten hatte er mit SmallTalk gesammelt.

Aus meiner vereinfachten Sicht setzt der WAM-Ansatz dem im SmallTalk-Kontext entworfenen Model-View-Controller (MVC) Paradigma einfach noch die Krone auf.

Juergen.


Hübner, Uwe wrote:
Käme auf einen Versuch an ob das wirklich so unerträglich aussieht.

Aber man könnte noch etwas anderes machen:
Einen 'ungefähre' Farbe-Vergleich einführen.
Der würde dann True liefern wenn man von der Farbe nicht allzu
weit entfernt ist. Der müsste allerdings den Vergleich auf Gleichheit ersetzen, sonst hat man wieder eine potentielle Fehlerquelle.

Aber was wir definitiv nicht brauchen sind Menschen die guten
Willens sind, sich für den Einsatz der Etoys im Unterricht interessieren und dann vor die Wand laufen.

Im Marketing gibt es die Erkenntnis, dass es deutlich einfacher ist
einen Kunden zu verlieren. Der rennt dann rum und erzählt allen wie
schlecht das Produkt ist. Aber man muss 10 Kunden begeistern, damit
es einen gibt der das weitererzählt.

Dann lieber die Etoys soweit abspecken, dass nur noch robustes
E-Zeugs übrigbleibt. Ich war zum Beispiel von der Robustheit
von Scratch total begeistert. Dabei ist Scratch vom Prinzip her
genau so aufgebaut wie die Etoys, aber die Benutzeroberfläche ist
deutlich suggestiver.

Die Version 3.9 der Etoys ist jedenfalls (soweit ich das bisher beurteilen
kann) ein Schritt (oder zwei) in die richtige Richtung.

Allerdings weiß ich nicht in wie
weit mein prozeduraler Programmierhintergrund mir hier einen Streich
gespielt hat. Aber ich denke prozedurale Sprachen sind leichter
zu verstehen weil sie nach dem Prinzip der Kochrezepte arbeiten:

1. Koche(Kartoffeln)
2. Brate(Fleisch)
3. Nachdem Gekocht(Kartoffeln) und Gebraten(Fleisch)
     Serviere(Essen)

Dagegen wäre Smalltalkorientiertes kochen etwa so
(ohne wirklich viel Ahnung von Smalltalk zu haben):

Kartoffeln koche dich     Fleisch brate dich
  Sende Fertig              Sende Fertig

Nachdem Kartoffeln Fertig
  Nachdem Fleisch Fertig
    Essen serviere dich

Gruß Uwe

MSC Vertriebs GmbH
registered office : Stutensee
Jurisdiction and registered Mannheim, Germany, HRB No. 10 3631
Managing Director: Manfred Schwarztrauber, Lothar Kümmerlin, Rüdiger Kuhn

Gleichmann & Co. Electronics GmbH
registered office : Frankenthal
Jurisdiction and registered Ludwigshafen, Germany, HRB No. 21305
Managing Director: Manfred Schwarztrauber, Thomas Klein

-----Ursprüngliche Nachricht-----
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Bert Freudenberg
Gesendet: Donnerstag, 10. April 2008 16:52
An: Squeak in Germany / Squeak in Deutschland
Betreff: Re: [Squeak-ev] Einfaches EToy-Projekt funktioniert nicht!
Wichtigkeit: Hoch


On 10.04.2008, at 07:30, Hübner, Uwe wrote:
Danke Bert.
Wahnsinn!

Ursprünglich war ich ja noch viel weiter und habe verschiedene Dinge ausprobiert...

Sollte man das nicht ein wenig 'robuster' machen?
Wie soll ein armer Lehrer auf so etwas kommen?


Das einzige, was man da machen könnte, ist das Zeichnen der Konnektoren auf 
"pixelig" umzustellen. Aber das will doch keiner, oder?

- Bert -



Antwort per Email an