SqueakInf11-Schlager.pdf
Hallo, Markus!
Vielen Dank für Dein Tutorial, hätte noch einige Anmerkungen dazu...:
Für den Einsteiger ist es schwer, aus der Fülle der Informationen ein korrektes, mentales Modell aufzubauen, und dann die Details korrekt einzuordnen. Aus didaktischer Sicht halte ich es für besser, zuerst ein mentales Modell von Smalltalk, Squeak, Etoys zu vermitteln und dann erst mit Details zu beginnen. So fände ich es sehr hilfreich, wenn man auf die Unterschiede zwischen Smalltalk und konventionellen Programmiersprachen hinweist. In Smalltalk greift ein Programm nicht in einen Datenbereich hinein, es wird also ein Objekt nicht von außen verändert, sondern es wird kommuniziert -> Sender an Receiver - "Schminke Dich!", und das Objekt (Frau, z.B.) weiß dann selber, wie es sich anmalt, weil - nur es kennt sich selber am besten ... Das erklärt auch, daß viele Methoden nur bei bestimmten Objekten verfügbar sind. So weiß sich ein Text oder eine Kurve selber einzufärben, während z.B. das Farb-Halo bei Pixelgrafiken keine Auswirkungen hat. Weiterhin unterscheidet Squeak zwischen Vektor-Objekten und Pixelobjekten, wobei das Malprogramm nur geschickt suggeriert, daß man Pixel vergrößen könnte -> Es rechnet beim Vergrößern die Bauklötze weg. Das hast Du zwar später erklärt, aber der Zusammenhang mit Halo's die z.B. da sind, aber nix bewirken - der lohnt sich schon früher zu erwähnen ... -> Spart Frust ... Weiterhin wäre die Unterscheidung zwischen Objekt und seiner Repräsentation sehr wichtig. Erstelle ich nämlich mittels eines Behälters mit "Objekt an Zeiger..." eine Animation, so kann man z.B. nicht durch Skalieren eines Frames im Behälter in die Animation eingreifen -> es wird immer das Originalobjekt genommen, obwohl es im Behälter z.B. skaliert wurde. Nur so ist z.B. das mit Ziehe Kostüm an .. zu erklären -> der Behälter wird zu einer Kleiderkammer, wo immer abwechselnd ein Kostüm herausgegeben wird, was sich das Objekt dann überzieht.
S. 72 GGT -> Warum nicht auch den KGV daraus errechnen? KGV = Produkt beider Zahlen/GGT
S. 76 -> Kann ein Programm nicht aus vielen Algorithmen gleichzeitig bestehen?
S. 84 -> Warum Python? Warum nicht in Smalltalk das Beispiel?
S. 87 -> Flussdiagramme. Ist Dir schon aufgefallen, daß die Kacheln in den Etoys Skripten exakt den Nassi-Shneydermann - Diagrammen entsprechen? (Struktogramme bei Dir genannt?) Wozu also Flußdiagramme und UML?
.sar - Pakete, das Standard-Format für Softwarepakte, kann man laden mit SARInstall installSAR: 'Paman.sar'.
Überhaupt, warum nimmst Du Squeak 3.9? Das OLPC - Image 1111 (latest version) von tinlizzy mit den Online Patches hat sehr viele Bugs korrigiert, darunter z.B. Text in/über mehrere Kurven hintereinander fließen lassen funktioniert nun klasse, Installtion von Zusatzfonts, RepeatTimes - Kachel in Etoys, Connectoren - richtig geil ..(kann man Motor mit Kurbelwelle, Pleuel .. in wenigen Minuten animieren), schau Dir mal "Curvy Connectors" (mit Shift Taste ziehen) und das Verhalten von Random - Connectors an ... (Die rasten ineinander ein, "verfolgen" Mittelsenkrechten ...u.s.w. ... feine Dinge. Erwähnst Du natürlich wegen dem Abstieg auf 3.9 nicht ... OLPC auf 3.8 basierend ist viel weiter, als sie 3.9 Version von Squeakland.
Daß man zuerst immer ein Projekt aufmachen soll, finde ich sehr wichtig. Ansonsten verstrickt man sich bei Projekten in Projekten, die sich plötzlich nicht mehr laden lassen ...
Außerdem bin ich ungücklich, daß das Auto oder die Mondlandefähre als Beispiele von Dir nicht geschätzt werden.
Mich hat dies hier fasziniert, Physik Animation:
http://icampus.mit.edu/MagicPaper/
Hier das Video:
http://vowe.net/archives/007742.html
Squeak kann sowas aber auch ... ich implementiere gerade in einige Etoys - Objekte spezielle Eigenschaften, die lernen fallen. So habe ich z.B. in Objekt Kugel folgendes implementiert. Die Kugel kann nun einen selbstgemalten Hang herunterrollen, beschleunigt, hüpft, springt, nimmt bergab fahrt auf und bremst ab, wenn ein Hügel kommt, und titscht mit anderen Kugeln herum ... Billiard... So kann ich z.B. eine Half-Pipe malen, und von rechts und links Kugeln fallen lassen, die sich treffen, übereinander springen, aneinander abprallen ... Ich habe da EToys - Kacheln gemacht - "feel gravity" "feel material" "feel friction" ... weiß noch nicht, ob das das richtige Konzept ist .. (Vorschläge?) Jedenfalls fährt nun mein Auto schon den Berg herunter und springt über Schluchten ... das mit den Massenträgheitsmomenten muß ich noch implementieren ... etwas schwieriger ... dauert noch ein paar Tage ... Ich werde es jedoch nur für das OLPC Image machen, 3.9 ist hinter dem Mond, und für mich tot ...
Interessant ist auch die Generierung von Morphen - Welt->Neuer Morph-> Alphabetische Liste ... Calendar ... eine Fülle von Objekten, die da unter OLPC - 1111 zur Verfügung stehen ... auch kann man Bilder in Squeak herein laden ...
So habe ich z.B. von der Merzedes - Benz Homepage ein Auto aus verschiedenen Perspektiven geladen, immer 5° - Winkel und fahre nun mit diesem 3-D Auto über einen Gelände Pacours, per Joystick gesteuert ... Photorealistisch ... Funktioniert mit EToys, Behälter und Zeiger auf Objekte in Behälter mit Richtungsänderung koppeln ...
Auch läßt Du unerwähnt, daß diese Zeiger "Objekt auf Zeiger" eigentlich Iteratoren sind ... Etoys bietet ja nun fast alles an, was OO - Programmierung ausmacht ...
Außerdem wäre hilfreich, wenn man z.B. Text aus einem Herzchen über eine Kurve in ein anderes Herzchen fließen läßt, das einmal zu zeigen, wie es in Etoys geht, und das dann mit 10 Zeilen reinem Smalltalk - Code zu vergeichen -> Das gibt einem das Gefühl, daß man wirklich versteht, was EToys eigentlich für Code generiert dahinter ... Ich habe auch einige Skripte, z.B. die Mondlandefähre mit Joysticksteuerung einfach mal händisch im Workspace nachprogrammiert ...
So, das wäre es erst einmal ... Soweit meine Anregungen ...
Have fun, Guido
Hallo Guido!
Erst einmal vielen Dank für deine Anmerkungen. Wie es aussieht, muß ich wohl ein paar Sachen erzählen, um das eine oder andere verständlicher zu machen.
Zunächst einmal zu mir selber: Im Grunde habe ich von Squeak und Smalltalk keine Ahnung, komme auch nicht aus der Informatik, sondern bin von meiner Ausbildung her (reiner) Mathematiker (war einmal in der algebraischen Geometrie zu Hause) und Lehrer für Mathematik und Physik mit einer berufsbegleitenden Nachqualifikation für Informatik. Eine Sache, die in meinem Tutorial passiert, ist daher z.B. ein schlichtes Mitprotokollieren meines eigenen Erlernens von Smalltalk.
Was sich ohnehin woanders in für mich brauchbarer Form findet. habe ich (soweit für meine Zwecke nötig) verlinkt, aber nicht dupliziert - dazu gehören natürlich drive-a-car und lunar-lander sowie die sonstigen Standardprojekte. Diese Dinge finden sich z.B. in Heiko Schröders Tutorial, auf das ich die Schüler als erstes auch angesetzt habe. In meine Folien aufgenommen habe ich dagegen (in meinen Augen) grundlegende Techniken im Umgang mit eToys, die ich, ehrlich gesagt, nirgends vernünftig dokumentiert gefunden habe, sondern durch Herumprobieren und (kontinuierliches) Mitlesen von Mailinglisten gelernt habe. Squeak als Entwicklungsumgebung findet sich immerhin fremdsprachig dokumentiert, aber die Begeisterung meiner Schüler, sich Informationen aus französischen oder spanischen Quellen zusammenzusuchen, hält sich in Grenzen.
Zum Sinn und Zweck des Tutorials:
An sich geht es hier nicht (primär) um Squeak, sondern um den Informatikunterricht an einem bayerischen Gymnasium, momentan in der 11, Jahrgangsstufe, künftig (und dann nicht mehr nur an einigen wenigen Gymnasien wie bislang) dann (ab Schuljahr 2008/9) in der 10. Klasse. Dadurch steht es in einem Kontext (Lehrplan), der auch erklärt, warum UML und Flußdiagramme hier eine wesentliche Rolle spielen. Das große Thema im Unterricht heißt nicht 'Programmieren' sondern 'Ablaufmodellierung'. Squeak/Smalltalk hat die Rolle eines Beispiels, um Modellierungstechniken umzusetzen. Was die Lehrerbildung in Bayern anbelangt, werden die Kollegen vermutlich primär auf Java getrimmt, was sich wohl auch in den (noch zu schreibenden) Schulbüchern widerspiegeln wird. Was ich hier mache, ist, Alternativen auszuprobieren und sie in einem Lehrernetzwerk auch ein wenig zu propagieren. Die letzten Jahre habe ich mit Python gearbeitet (das ist auch der Grund, warum in den Folien der Heron-Algorithmus (noch nur) in Python implementiert ist - ich wußte in dem Moment schlicht noch nicht, wie man das in Smalltalk macht).
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.
Was ich gerne wüßte - eine Frage an die produktiv arbeitenden Squeaker:
Wie sieht der typische Workflow bei GUI-Programmierung in Squeak aus? 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.)
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. 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.
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.
Immer vorausgesetzt, daß die Schüler überhaupt qualifiziertes Lehrpersonal haben, lernen sie:
6. 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.
7. Klasse (im Moment eben auch 11. Klasse):
Ablaufmodellierung, insbesondere die klassischen imperativen Strukturen. Im Prinzip z.B. eine Sache für eToys, denen bislang aber die Schleifen fehlten. Scratch paßt hier wie die Faust aufs Auge. Von der Modellierung her propagieren die Schulbücher an dieser Stelle Struktogramme - ich selber finde Flußdiagramme 'besser'.
9. Klasse (ab 2007/8):
Datenflüsse und Datenmodellierung, insbes. auch ER-Modell und Datenbanken
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.
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. 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' ;-) )
Schöne Grüße
Markus ----------------------------------------------- Markus Schlager m.slg(at)gmx.de
Hallo Markus,
on Sun, 11 Mar 2007 23:48:26 +0100, you wrote: ...
Was ich gerne wüßte - eine Frage an die produktiv arbeitenden Squeaker:
Wie sieht der typische Workflow bei GUI-Programmierung in Squeak aus? 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.)
Erst einmal vielen Dank für Deine Arbeit an+mit Squeak!
Zu Deiner Frage: der "typische" Ansatz bei der GUI-Programmierung wird von der späteren Verwendung geprägt. Soll das erzeugte GUI in ein gut wartbares Produkt integriert werden so wird oftmals (früher oder später) eine quelltextorientierte Beschreibung erzeugt. Wesentlich dabei ist das Vorhandensein von Werkzeugen die die Wartung dieses speziellen GUIs erleichtern oder gar erst ermöglichen. Auch die (Un-)Möglichkeiten des Transports zum (zur Integration in den) nächsten Computer haben einen direkten Einfluss.
Soll das GUI aber nur zum "Vergnügen" dienen und/oder muss es der nächste Kollege auch nicht gleich verstehen dann ist der Weg egal :)
Beide Ansätze sind in meiner Erfahrung unabhängig von der Entwicklungsumgebung; sofern sie (so wie bei Squeak) überhaupt unterstützt werden.
/Klaus
Hallo Markus,
MS> Wie sieht der typische Workflow bei GUI-Programmierung in Squeak aus? MS> Baut ihr GUIs üblicherweise via Maus aus Morphen zusammen und erzeugt MS> daraus dann irgendwie neue Klassen, oder ist der typische Weg doch der,
typisch kann ich Dir nicht sagen, ich nutze Beides.
Je unklarer mir das GUI ist, desto eher fange ich grafisch an.
Am Ende ist es bisher immer Quelltext geworden. Ich bin aber vielleicht ein Sonderfall, ich hab' meistens eine Papierskizze gemacht und es dann runtergeschrieben. Hat wohl historische Gründe.
Tschöö
Herbert mailto:herbertkoenig@gmx.net
Hallo Ihr Lieben, da ist ja mal richtig was los auf der Liste. Da muss ich doch auch mal meinen Senf dazugeben:
Am Sunday, 11. March 2007 14:21 schrieb stepken:
Für den Einsteiger ist es schwer, aus der Fülle der Informationen ein korrektes, mentales Modell aufzubauen, und dann die Details korrekt einzuordnen. Aus didaktischer Sicht halte ich es für besser, zuerst ein mentales Modell von Smalltalk, Squeak, Etoys zu vermitteln und dann erst mit Details zu beginnen. So fände ich es sehr hilfreich, wenn man auf die Unterschiede zwischen Smalltalk und konventionellen Programmiersprachen hinweist.
Das scheint wohl das Wesen der Schuldidaktik zu sein, dass man zuerst ein Thema durchnimmt, dann das nächste usw, jedes mit ziemlich vielen Details. Erst im Laufe der Jahre (und vielleicht auch der jugendlichen Entwicklung) wächst dann ein mentales Modell. Bei Erwachsenen machen das die Dozenten ja gerne anders, da gibt man zuerst einen Überblick und schmeißt mit Begriffen rum, und in der nächsten Iteration wird das alles erklärt. Mir tun nur die armen Schüler leid, die zuerst UML lernen, und die dazu passende Programmiersprache erst ein Jahr später. Ich als Nebenfachinformatikerin fand das Programmieren immer am schönsten. "Wo bleiben da die Erfolgserlebnisse" frage ich mich auch. Aber wenn die Lehrpläne nun mal so sind.....(das Thema hatten wir ja nun hier schon).
Überhaupt, warum nimmst Du Squeak 3.9? Das OLPC - Image 1111 (latest version) von tinlizzy mit den Online Patches hat sehr viele Bugs korrigiert,
Was ist OLPC? Gibts das auf Deutsch, oder ist mein Einsatz gefragt?
Monday 16:27:33
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 ...
Na, dann viel Spaß! Sowas kommt im professionell-industriellen Umfeld immer "prima" an, es sei denn, es steht gerade eine Kündigungswelle an... Hoffentlich ist dann die Zählschleife nicht von einer werdenden Mutter programmiert, die nicht gekündigt werden darf. Tut mir leid, aber wenn ich "hat OO nicht verstanden" oder "aus dem Team schmeißen" lese, werde ich zynisch oder aggressiv.
Vielleicht liegt hier der Grund versteckt, warum so wenig Stellen für Smalltalk-Entwickler ausgeschrieben sind (ich habe jedenfalls in den letzten Wochen keine einzige gesehen). Die Smalltalker haben alle OO verstanden, und werden deswegen nicht aus ihren Teams geschmissen und deswegen werden keine Nachfolger gesucht. Rätsel, rätsel....
Liebe Grüße Esther
Esther Mietzsch (14.03. 14:18):
Überhaupt, warum nimmst Du Squeak 3.9? Das OLPC - Image 1111 (latest version) von tinlizzy mit den Online Patches hat sehr viele Bugs korrigiert,
Was ist OLPC? Gibts das auf Deutsch, oder ist mein Einsatz gefragt?
Ich tippe auf "One Laptop Per Child", wenn ich mich recht entsinne, läuft squeak auf der Kiste.
Vielleicht liegt hier der Grund versteckt, warum so wenig Stellen für Smalltalk-Entwickler ausgeschrieben sind (ich habe jedenfalls in den letzten Wochen keine einzige gesehen). Die Smalltalker haben alle OO verstanden, und werden deswegen nicht aus ihren Teams geschmissen und deswegen werden keine Nachfolger gesucht. Rätsel, rätsel....
Ein Teufelskreis. Die Großen, die früher die dicken Smalltalk-Projekte hatten, sind auf Java o.ä. umgestiegen und weigern sich nun, irgendwas anderes in ihren IT-Pool mit aufzunehmen.
Wir haben's versucht ... Das GUI für eine Simulationssoftware für einen Autobauer hätten wir gar zu gerne mit Dolphin Smalltalk gemacht. Die IT-Abteilung hat aber auftragsgemäß durchgesetzt, dass der Unternehmensstandard (Java oder .net) unangetastet bleibt.
Das ist wieder die CYA-Mentalität, die nur sehr konservative Entwicklungen zulässt, weil die mit dem kleinsten persönliches Risiko behaftet sind.
s.
On Wed, 14 Mar 2007 14:18:08 +0100, Esther Mietzsch wrote:
Hallo Ihr Lieben, da ist ja mal richtig was los auf der Liste. Da muss ich doch auch mal meinen Senf dazugeben:
:)
Tut mir leid, aber wenn ich "hat OO nicht verstanden" oder "aus dem Team schmeißen" lese, werde ich zynisch oder aggressiv.
Nun ja, bei uns hier löst sowas, wenn überhaupt, gerade mal gähnende Langeweile aus :)
Vielleicht liegt hier der Grund versteckt, warum so wenig Stellen für Smalltalk-Entwickler ausgeschrieben sind (ich habe jedenfalls in den letzten Wochen keine einzige gesehen). Die Smalltalker haben alle OO verstanden, und werden deswegen nicht aus ihren Teams geschmissen und deswegen werden keine Nachfolger gesucht. Rätsel, rätsel....
Ach, wirklich (kein Smalltalker gesucht)?
- http://www.google.com/search?q=smalltalk&gl=US
und dem Web browser so lange "refresh" geben bis das Wort Smalltalk unter "Sponsored Links" auftaucht. Firmen die wirklich was davon verstehen, suchen Smalltalker.
Habe allerdings auch schon'n Smalltalker erlebt, der [garnicht mal so lange her] bei dsbzgl. Interviews durchgefallen ist ... (äh, nicht ich!).
Cheers Klaus
Liebe Grüße Esther
Nachdem der Thread zur Ruhe gekommen zu sein scheint, möchte ich mich bei allen Diskutanten für die Beiträge bedanken. Ihr habt mich ein gutes Stück weiter gebracht,
Markus ----------------------------------------------- Markus Schlager m.slg(at)gmx.de
Hallo, Squeaker!
Tips für Einsteiger in Smalltalk:
http://e-books.zfn.uni-bremen.de/e-book-SMALLTALK.html
Alan Kay meinte mal, er habe einen Fehler begangen, als der den Begriff ObjektOrientierung schuf - bei Smalltalk hätte es besser "message oriented programming" geheißen...
Ein sehr erstaunliches Werk von Thomas Kühne zur FUNKTIONALEN Programmierung mit OO-Sprachen, mal wieder ein neues, altes Paradigma der OO-Welt.
www.mm.informatik.tu-darmstadt.de/~kuehne/tfps/*fps-sans-escher*.pdf
Wünsche viel Spaß mit den Mammut-Werken ... habe sie auch schon *fast* durch ...
Guido Stepken
Hallo, Squeaker!
Tips für Einsteiger in Smalltalk:
http://e-books.zfn.uni-bremen.de/e-book-SMALLTALK.html
Alan Kay meinte mal, er habe einen Fehler begangen, als der den Begriff ObjektOrientierung schuf - bei Smalltalk hätte es besser "message oriented programming" geheißen...
Ein sehr erstaunliches Werk von Thomas Kühne zur FUNKTIONALEN Programmierung mit OO-Sprachen, mal wieder ein neues, altes Paradigma der OO-Welt.
www.mm.informatik.tu-darmstadt.de/~kuehne/tfps/*fps-sans-escher*.pdf
Wünsche viel Spaß mit den Mammut-Werken ... habe sie auch schon *fast* durch ...
Guido Stepken
Hi Guido,
Tips für Einsteiger in Smalltalk:
http://e-books.zfn.uni-bremen.de/e-book-SMALLTALK.html
Alan Kay meinte mal, er habe einen Fehler begangen, als der den Begriff ObjektOrientierung schuf - bei Smalltalk hätte es besser "message oriented programming" geheißen...
Ein sehr erstaunliches Werk von Thomas Kühne zur FUNKTIONALEN Programmierung mit OO-Sprachen, mal wieder ein neues, altes Paradigma der OO-Welt.
www.mm.informatik.tu-darmstadt.de/~kuehne/tfps/*fps-sans-escher*.pdf
Wünsche viel Spaß mit den Mammut-Werken ... habe sie auch schon *fast* durch ...
Besten Dank für die Tipps, ersteres kannt ich noch gar nicht online --
hast Du schon ein Login für unseren Wiki (squeak.de)? Dann könntest Du das dort gleich eintragen. Das bekommst Du über eine Mail an Andreas.
Liebe Grüsse,
Markus
Markus Gaelli schrieb:
Hi Guido,
Tips für Einsteiger in Smalltalk:
http://e-books.zfn.uni-bremen.de/e-book-SMALLTALK.html
Alan Kay meinte mal, er habe einen Fehler begangen, als der den Begriff ObjektOrientierung schuf - bei Smalltalk hätte es besser "message oriented programming" geheißen...
Ein sehr erstaunliches Werk von Thomas Kühne zur FUNKTIONALEN Programmierung mit OO-Sprachen, mal wieder ein neues, altes Paradigma der OO-Welt.
www.mm.informatik.tu-darmstadt.de/~kuehne/tfps/*fps-sans-escher*.pdf
Wünsche viel Spaß mit den Mammut-Werken ... habe sie auch schon *fast* durch ...
Besten Dank für die Tipps, ersteres kannt ich noch gar nicht online --
Ja, finde ich klasse, auch für Informatik - Unterricht geeignet. Ist Smalltalk - 80 das alte Smalltalk/V 16 Bit. Lief damals schon recht gut, da hatte ich aber nur wenig mit Smalltalk am Hut ..
hast Du schon ein Login für unseren Wiki (squeak.de)? Dann könntest Du das dort gleich eintragen.
Och, mach Du das doch einfach ...
http://www.mm.informatik.tu-darmstadt.de/~kuehne/tfps/fps-sans-escher.pdf
Ein herausragendes Werk, was Entscheidern von Mammut-Projekten gute Argumente *für* Smalltalk geben kann.
Frage an Dich: Mal abgesehen von der Geschweifte - Klammer Syntax, die nur Squeak kennt, welche Unterschiede gibt es noch in der Sprache zu anderen Smalltalk - Versionen?
Das bekommst Du über eine Mail an Andreas.
Danke, schauen wir mal ...
LG, Guido
Mikael Kindborg und Kevin McGee haben sich auf recht einfach verständliche und vergnügliche Weise mit der Mächtigkeit der grafischen Programmierung mittels der Logik - Kacheln in EToys auseinandergesetzt, und die Grenzen dieser Art der Programmierung erläutert. Thema: "Graphical rewrite rules, Semiotics"
Visual Programming with Analogical Representations: Inspirations from a Semiotic Analysis of Comics Mikael Kindborg and Kevin McGee Department of Computer and Information Science Linköping University, SE-58183 Linköping, Sweden {mikki, kevmc}@ida.liu.se http://www.ida.liu.se/~mikki/comics/JVLC_Kindborg_McGee_Paper_October_2006.p...
Interessanterweise zeigen sich hier auch die Grenzen der Kombination UML 2.0, JAVA, JBOSS, Eclipse, also des überall fälschlicherweise für äußerst "produktiv" gehaltenen Werkzeuges 'Rational Rose', nun IBM. Die Idee: Eine Heerschar von Programmierern schubsen lange Zeit grafisch nur Logiken auf dem Bildschirm zurecht, woraufhin dann Rose ein Code - Rohgerüst mit unzähligen Klassen, SQL - Strukturen ... auswirft, welche dann nur noch "händisch" ergänzt werden brauchen. JBOSS kümmert sich um die Verkapselung der Progrämmchen und Daten in Containern, welche dann auf der Suche nach freier CPU- Zeit durch das SUN-Netzwerk flitzen: "The net ist the computer!" IBM hat dieses Problem mit der Unvereinbarkeit von riesigen Datenmengen mit dem Design hinter JBOSS schon lange erkannt, bietet spezielle Maintraimes an, welche dann die typischen Performance - Dezifixe duch die Architektur auffangen. Problem - JAVA skaliert nicht so, wie gewünscht, jedenfalls nur unter bestimmten Voraussetzungen. Das gescheiterte Projekt FISCUS sollte allen eine Warnung sein.
'Things should be made simple, but not simpler!' - der Spruch von Einstein gilt auch für die grafische Programmierung. Natürlich sollte Programmierung so einfach gemacht werden, wie möglich, weswegen grafische Programmierung sicherlich zum 'state of the art' gehört. Squeak vereinigt auf wunderbare Weise diese beiden Welten. Man kann zwischen Kacheln und Programmcode hin - und herschalten, bzw. einige Skripte nur händisch in Smalltalk programmieren. Variblen aus EToys können einfach auch ausgelesen und mit Smalltalk Code verändert werden, Ausgaben von OO-Datenbankqueries erscheinen ganz einfach wieder in den Textfenstern, welche man sich aus dem Objektbaukasten an eine Stelle gezogen hat. Tippt man in ein Fenster eine Zahl ein, so landet diese unverzüglich in der OO-Datenbank, und zwar verändert sich der Zahlenwert in der OO-Datenbank während des Tippens kontinuierlich. Weil jeder Buchstabe, jede Ziffer ein eigenes Objekt ist, kann man sogar wie selbstverständlich zu mehreren an Texten schreiben. Völlige Transparenz also - keine Caches, keine Puffer, kein "OK-Button", der die Daten gesammelt aus der Maske in die Datenbank überträgt. Alles überflüssig. Auch kein 'kümmern' um Speicherverwaltung mehr. Das vereinfacht sehr die Programmierung. Ich lese immer wieder, daß viele bei Squeak nach Werkzeugen zur Programmierung einer GUI fragen. Von JAVA, .NET, KDE (Linux) her kommend hat sich bei Entscheidern ein völlig veraltetes geistiges Modell tief in die Hirne gebrannt. Man sucht nach einem 'GUI-Builder' der XML - Code mit einem Anschluß an die Event-Handler erzeugt. So würde beim Verschieben oder öffnen eines Fensters intern der XML - Baum modifiziert. Damit hat man erreicht, daß die GUI unabhängig vom eigentlichen Programm wird, womit Net-Computing dann wirklich beginnen kann. Interessanterweise wird gerade damit ein Konzept wieder neu erfunden, welches schon UNIX mit X-Windows seit ewigen Zeiten beherrschte, und den auch Squeak schon von Anfang an erfüllte.
Squeak hingegen ist da noch viel weiter im Design. Alles, was sichtbar ist, ist Objekt, (Text, Text, der Linien folgt, ...) ist drehbar, bewegbar, anfassbar, programmierbar, und diese Objekte lassen sich auch über Netzwerk verschieben. Nicht nur, daß man Menü's während der Bedienung sich dauernd drehen lassen kann, oder man den Schwierigkeitsgrad von Tetris erhöht, indem man das Fenster sich dauernd drehen läßt, oder das Menü wie ein Herz pochen läßt. Alles, was denkbar ist, kann gemacht werden, und diese Vielfalt ist so groß, daß man als erfahrener JAVA, C++, C#, DEPHI Programmierer ob dieser erschlagenen Vielfalt nur noch ins Staunen kommt, und in Squeak verzweifelt wieder nach den 'Primitives' der MFC sucht - nur es gibt sie nicht. Ganz Squeak mit Morphic ist GUI, in sich selber geschrieben. Nun - hier ist sogar Microsoft noch lange nicht angekommen. .NET ist nicht vollständig in .NET geschrieben, und schon garnicht Quellcode - offen.
Squeak läuft nicht nur in der neuesten OPLC als Plugin im Browser, sondern Squeak *ist* sowohl Programmier - Umgebung als auch GUI - Builder, als auch Debugger, als auch Anwendungsprogramm selber - es gibt keine Trennung. Bei der Microsoft - Architektur ist alles sauber getrennt, und durch Interfaces miteinander verbunden. Allein schon die Einarbeitung nur in die MAPI dauert schon länger (eigene Erfahrung), als die Einarbeitung in Squeak und das Erlernen von Smalltalk zusammen. Squeak ist natürlich auch Ersatz für Flash, bzw. sogar für Shockwave, und darüber hinaus noch viel einfacher zu programmieren. Man kann auch Flash 3 in Squeak ablaufen lassen, und mit Squeak sogar .swf generieren.
Risiken der Programmierung in Smalltalk mit Squeak? Smalltalk ist seit den 80er Jahren unverändert, riesige Bibliotheken (auch SOAP, ... Manipulation von XML-Bäumen, Interfaces aller Art) existieren, man stolpert über sie, wenn man sich z.B. Squeak und die Routinen im Image mal genauer anschaut ... Import eines XML - Baumes in eine OO-Datenbank? Hmmmm. Trivial. Anzapfen eines Datenstromes aus einer Datenbank, einem Webserver, einem FTP-Server, SOAP/RPC-Server? So trivial, daß noch nicht einmal ein Menü-Button in irgendeinem Anwender - Programm dafür existiert. Das ist *das* Manko in Squeak. Microsoft ist da viel geschickter. Allein schon zur Bedienung der SQL - Datenbank hat Microsoft ein irrsinniges Werkzeug geschrieben, wo dem Anwender suggeriert wird, damit beherrsche er nun alles. Nix ist. Schon bei etwas komplizierteren Queries kommt man nicht drumherum, sein eigenes Hirn zu quälen, man muss dann doch wieder die Grundlagen der relationalen Datenbankprogrammierung erlernen. Und wenn auch nur ein einziges Feld vom Typ her verändert werden muß, fliegen den Programmieren wieder Unmengen von Code um die Ohren. Hierin liegt das Geheimnis der effizienten Programmierung von großen Projekten mit Smalltalk begründet. Eine Untersuchung von IBM der 70er Jahren (Programmiersprache C, auch mit C++ zu vergleichen) hat ergeben, daß ein Programmierer je Tag nur ganze 5!!! Programmzeilen beiträgt, die dann auch im endgültigen Code verbleiben. Bei Smalltalk ist dies ein vielfaches höher. Refactoring wird stark vereinfacht. Natürlich unterstützt Squeak auch Unit-Testing. Unit-Tests kommen ja aus der Smalltalk - Umgebung, sie wurden für Smalltalk erfunden....
Ich denke, daß solche Dinge auch mal kommuniziert werden müssen. Angesichts der vielen kollektiven Irrtümer in der Entscheiderwelt sollten Smalltalk - Enthusiasten sich mal zusammen tun, und Fakten zusammentragen. Ergänzungen, Kritik zu meinen (vielleicht etwas verqueren) Ansichten always welcome....
Wünsche viel Spaß mit Squeak
Guido Stepken
Hallo Guido,
on Mon, 19 Mar 2007 13:53:47 +0100, you wrote: ...
Ich denke, daß solche Dinge auch mal kommuniziert werden müssen. Angesichts der vielen kollektiven Irrtümer in der Entscheiderwelt sollten Smalltalk - Enthusiasten sich mal zusammen tun, und Fakten zusammentragen. Ergänzungen, Kritik zu meinen (vielleicht etwas verqueren) Ansichten always welcome..
Finde ich ganz toll, was Du so über Squeak schreibst (und über IBM, MS$ & co).
Habe allerdings einige Zweifel dass die von Dir ganz zutreffend als Herausragend angeführte (Squeak) Eigenschaften in dem von Dir gewünschten Ausmass skalieren.
Hast Du zufällig Beispiel(e) mit Smalltalk Teams von industrieller Grösse (ab etwa 10 aufwärts), bei denen die Produktivität gemessen wurde (Applikation unwichtig). Bin ein Function Point Veteran und würde so einen Vergleich schätzen.
Wünsche viel Spaß mit Squeak
Danke, ditto!
Cheers Klaus
Guido Stepken
Hast Du zufällig Beispiel(e) mit Smalltalk Teams von industrieller Grösse (ab etwa 10 aufwärts), bei denen die Produktivität gemessen wurde (Applikation unwichtig). Bin ein Function Point Veteran und würde so einen Vergleich schätzen.
Danke, ditto!
Cheers Klaus
Hallo Klaus,
ich habe zwar keine direkten Projekte, aber aus Sicht FPA und COCOMO II ist Smalltalk sehr interessant. Die FPA liefert ja "nur" den Umfang einer Software, der Aufwand kommt ja erst später heraus. COCOMO II nimmt hier die Anzahl dere Quellzeilen (Source Lines of Code - SLOC) als einen der Eingangsparameter. Und diese ist bei gleicher Anzahl an FPs von der Sprache abhängig. Tabellen wie http://www.qsm.com/FPGearing.html zeigen für Smalltalk im Mittel 32 SLOC/FP an, Java oder C# liegen hingegen bei etwa 60. Hier zeigt sich bereits, welchen Einfluss die Wahl von Smalltalk haben könnte, ausgehend davon, dass die weiteren Randbedingungen gleich wären. Leider wird an den Unis aber ja niemand mehr in Smalltalk ausgebildet. *seufz*
Liebe Grüße
mue
Hallo Frank,
on Mon, 19 Mar 2007 16:27:44 +0100, you wrote:
Hast Du zufällig Beispiel(e) mit Smalltalk Teams von industrieller Grösse (ab etwa 10 aufwärts), bei denen die Produktivität gemessen wurde (Applikation unwichtig). Bin ein Function Point Veteran und würde so einen Vergleich schätzen.
Danke, ditto!
Cheers Klaus
Hallo Klaus,
ich habe zwar keine direkten Projekte, aber aus Sicht FPA und COCOMO II ist Smalltalk sehr interessant. Die FPA liefert ja "nur" den Umfang einer Software, der Aufwand kommt ja erst später heraus.
Eine FPA ist unvollständing solange das Projekt am Ende nicht nachgemessen wird, in etwa so wie (nil zork) :)
COCOMO II nimmt hier die Anzahl dere Quellzeilen (Source Lines of Code - SLOC) als einen der Eingangsparameter. Und diese ist bei gleicher Anzahl an FPs von der Sprache abhängig. Tabellen wie http://www.qsm.com/FPGearing.html zeigen für Smalltalk im Mittel 32 SLOC/FP an, Java oder C# liegen hingegen bei etwa 60.
Danke für den Link (das Material basiert tatsächlich auf "completed function point projects"). Übrigens, der Hersteller von Mapper behauptet einen besseren Wert als bspws. Cobol ;-) Und was man in LotusNotes oder PeopleSoft an vergleichbarem programmieren könnte, wird mir als Kenner bestimmt für immer verschlossen bleiben (diese Liste sieht aus wie "designed" für die Kunden von qsm.com).
NB die Zeit welche die Entwickler für die Suche nach "in der Sprache" lösbare / gelöste Probleme suchen, hat zwar auch einen enormen Einfluss, bleibt jedoch bei irgendwelchen SLOC Vergleichen eher unberücksichtig.
Hier zeigt sich bereits, welchen Einfluss die Wahl von Smalltalk haben könnte, ausgehend davon, dass die weiteren Randbedingungen gleich wären. Leider wird an den Unis aber ja niemand mehr in Smalltalk ausgebildet. *seufz*
Ist doch auch garnicht nötig für Leute mit OO-Hintergrund; Lehrplan:
1] Smalltalk hat 5 Konstante: nil, false, true, self (super) und thisContext.
1.a] und die natürlichen Zahlen :)
2] Smalltalk hat unäre, binäre und keyword message selectors (sorry, Denglish).
3] alles andere darfst Du selber machen und/oder herausbekommen (Guido! :)
Cheers Klaus
Liebe Grüße
mue
Hallo Klaus ...
Eine FPA ist unvollständing solange das Projekt am Ende nicht nachgemessen wird, in etwa so wie (nil zork) :)
Ich wuerde gerne noch einen Schritt weiter gehen: Jedes Schaetzverfahren ist ohne eine Rueckkopplung und Justage der Parameter unvollstaendig.
Danke für den Link (das Material basiert tatsächlich auf "completed function point projects"). Ãbrigens, der Hersteller von Mapper behauptet einen besseren Wert als bspws. Cobol ;-) Und was man in LotusNotes oder PeopleSoft an vergleichbarem programmieren könnte, wird mir als Kenner bestimmt für immer verschlossen bleiben (diese Liste sieht aus wie "designed" für die Kunden von qsm.com).
Naja, OK, ich kann einiges auch icht immer nachvollziehen. Das stimmt schon. Man muss wohl die Sprachen auch imemr in verlgeichbar loesbare Aufgabenstellungen separieren. Die Zahlen fuer die SLOC/FP finden sich dafuer hingegen in vielen Tabellen wieder. Diese nehme ich nur gerne, da sie recht vollstaendig ist. Die Werte der anderen Tabellen weichen nicht sehr stark ab.
NB die Zeit welche die Entwickler für die Suche nach "in der Sprache" lösbare / gelöste Probleme suchen, hat zwar auch einen enormen Einfluss, bleibt jedoch bei irgendwelchen SLOC Vergleichen eher unberücksichtig.
Einen Spracheinfluss kenne ich hier leider auch nicht, wohl aber das Einbeziehen weiterer harten oder weichen Constraints (ja, ich kann auch Denglisch). Sowohl die FPA als auch spaeter COCOMO II ziehen ja eine Vielzahl von weiteren Kriterien fuer die Gewichtung und Schaetzung heran.
Ist doch auch garnicht nötig für Leute mit OO-Hintergrund; Lehrplan:
1] Smalltalk hat 5 Konstante: nil, false, true, self (super) und thisContext.
1.a] und die natürlichen Zahlen :)
2] Smalltalk hat unäre, binäre und keyword message selectors (sorry, Denglish).
3] alles andere darfst Du selber machen und/oder herausbekommen (Guido! :)
Cheers Klaus
Hihi, in dem Sinne sicherlich richtig. Aber Du kennst vielleicht auch "Watt der Buer nich kennt, datt frett hey nich." oder so. Mir geht es einfach um die Vermittlung von Alternativen, also auch Lisp und Prolog. Und nicht immer nur Java, Java, Java (oder vielleicht auch mal PHP *lol*).
Liebe Gruesse
mue
Hallo Frank,
On Mon, 19 Mar 2007 18:00:20 +0100, you wrote:
Hallo Klaus ...
...
Ist doch auch garnicht nötig für Leute mit OO-Hintergrund; Lehrplan:
1] Smalltalk hat 5 Konstante: nil, false, true, self (super) und thisContext.
1.a] und die natürlichen Zahlen :)
2] Smalltalk hat unäre, binäre und keyword message selectors (sorry, Denglish).
Mönsch, hast Du aber tolle Sonderzeichen :)
3] alles andere darfst Du selber machen und/oder herausbekommen (Guido! :)
Cheers Klaus
Hihi, in dem Sinne sicherlich richtig. Aber Du kennst vielleicht auch "Watt der Buer nich kennt, datt frett hey nich." oder so. Mir geht es einfach um die Vermittlung von Alternativen, also auch Lisp und Prolog. Und nicht immer nur Java, Java, Java (oder vielleicht auch mal PHP *lol*).
Das wiederum versteht meiner-einer nunmehr ganz und garnicht an der "ihr lehrt die falsche Sprache" resp. "wir können nicht *die* richige Sprache lehren" Debatte:
Das ordinäre Squeak .image bspws. hat genügend herumliegende und (wieder-) gebrauchsfähige Komponenten, die man zu einer Java-IDE zusammenkomponieren kann; incl. Debugger (Decompiler würde schwierig); incl. "mönsch, das sieht ja aus wie Java"; incl. "heh, benimmt sich ja auch wie Java".
Sollte zum Lehren doch eigentlich völlig ausreichen und nur die zukünftigen Gewinner vom Turing Test würden, wenn überhaupt, einen Unterschied bemerken.
Wenn mir mal jemand 'ne Liste mit dem Minimum an Klassen auf dem classpath[1] für den Lehrbetrieb macht+pflegt (Konsistenz), dann könnte ich damit aufhören immer nur Compiler für die Smalltalk/Self/Pepsi/Cola Sprachen zu schreiben ;-)
Cheers Klaus
[1] http://www.gnu.org/software/classpath/faq/faq.html
Liebe Gruesse
mue
On Mar 19, 2007, at 4:27 PM, Frank Mueller wrote:
Leider wird an den Unis aber ja niemand mehr in Smalltalk ausgebildet. *seufz*
Naja, ganz so stimmt das ja auch nicht:
http://www.squeak.de/SqueakindeutschsprachigenHochschulen/
wenn noch jemand was weiss, Mail an mich/alle oder gerne direkt eintragen...
Liebe Grüsse,
Markus
Guten Abend!
On 3/19/07, Markus Gaelli gaelli@emergent.de wrote:
Erstmal herzlichen Dank für den Verweis aufs HPI! :-)
Das Fachgebiet von Prof. Hirschfeld setzt Smalltalk eigentlich in fast allen Lehrveranstaltungen ein. Die OLPC-(Bei)Spiele sind z. B. im vergangenen Wintersemester in der turnusmäßigen Veranstaltung "Software-Architekturen" (3. Semester Bachelor-Studium) entstanden. Im kommenden Sommersemester wird es eine Vorlesung "Virtuelle Maschinen" geben, in der u.a. mit Smalltalk-VMs gearbeitet wird...
Die Erfahrungen sind durchaus positiv!
Viele Grüße,
Michael Haupt
squeak-ev@lists.squeakfoundation.org