SqueakInf11-Schlager Anmerkungen

On Mar 13, 2007, at 23:24 , Stefan Schmiedl wrote:

Wenn es das nicht gäbe, müsste man's erfinden ;)

>> Das Tolle an der Smalltalk-"For-Schleife" ist, dass sie nur ein
>> Iterator über Zahlenintervalle ist.
>
> Das ist richtig. Entspricht aber "vom Gefühl her" genau der alten
> BASIC/C-For-Schleife, weil "nur" über Zahlen iteriert wird, und die
> gelten anscheinend nicht als Objekte. Sonst wäre Guido nicht so
> versessen drauf, sie nicht zum Abarbeiten von Collections herzunehmen.

Naja, da hat er ja im Prinzip auch recht. Allzu oft sehe ich eben die  
Zahlschleifen, mit denen die Leute per #at: und #at:put: in den  
Objekten rumfuhrwerken. Das machen besonders gern diejenigen, die  
sich über die fehlende Indizierungssyntax aufregen, "a[i]" sieht eben  
zugegebenermaßen nicht halb so schlimm aus wie "a at: i". Dass das  
aber sofort viel besser lesbar und weniger fehleranfällig wird, wenn  
man nicht händisch Indizes generiert sondern einfach über die Objekte  
iteriert, ist schwer in die verbildeten Köpfe zu bekommen.

Insofern wäre es schon gut, eben *nicht* mit den Zählschleifen  
anzufangen. Leider kenne ich aber kein Informatikbuch, in dem  
Algorithmen nicht mit mathematischer Indexnotation eingeführt werden.  
Beispiel Sortieren - vor lauter Indexakrobatik sieht man doch da nie  
und nimmer das Prinzip! Vergleiche mal einen Quicksort-Algorithmus  
aus irgendeinem Buch mit dem hier:

qsort
        self isEmpty ifFalse: [
                ^(self select: [:each | each < self first]) qsort ,
                {self first} ,
                (self select: [:each | each > self first]) qsort]

Natürlich gibt es manche Probleme bei denen man Indizes braucht, aber  
das sind weniger als man denkt. Das eigentliche Problem ist auch  
nicht die Zählschleife an sich, sondern dass sie an jeder passenden  
und noch mehr unpassenden Stellen eingesetzt wird. Das kommt von den  
Büchern, aber auch von Sprachen, die nichts besseres unterstützen.

- Bert -

Bert Freudenberg (14.03. 00:07):

> >Aber nicht doch ... gibt's atAll: wirklich? Boah! Jahrelang übersehen!
>
> Wenn es das nicht gäbe, müsste man's erfinden ;)

ob man das dann noch verstehen kann? :-D

> Das eigentliche Problem ist auch  
> nicht die Zählschleife an sich, sondern dass sie an jeder passenden  
> und noch mehr unpassenden Stellen eingesetzt wird.

Damit sind wir beim Kern der Sache angelangt, denke ich. Es ist eine
Frage des Urteilsvermögens und des Vorwissens des Programmierenden.
Und die "totale Abschaffung" der Zählschleife ist da genau so verkehrt
wie die generelle Anwendung derselben.

Je mehr Werkzeug man hat, um so größer ist die Wahrscheinlichkeit
(sich nicht an das richtige erinnern zu können) ein wirklich passendes
zu finden.

Gute Nacht, allerseits.

s.

Hallo, Stefan!
Du meinst Traits, oder Iteratoren mit anonymen Funktionen, um das
Problem der Kapselung zu umgehen?

http://web.cecs.pdx.edu/~black/publications/refactoringsACM.pdf  womit
wir bei Pattern der "funktionalen Programmierung" wären .... Aber Du
hast schon recht, zwei Schleifen meist besser....
> Ich bin in Bayern zur Schule gegangen und hab hier auch fürs Lehramt
> studiert. Mit mir musst du langsam reden. Was ist der Inhalt und die
> Oberfläche der Funktion 1/x?
>
>  
Sorry, die Funktion rotiert um die x-Achse.
> Wo ist das Problem? Du kannst die Farbe doch gar nicht reinschütten, weil
>
>  
Nunja, ich wollte nur auf das Problem hinweisen, daß ich bei einem
solchen Körper begrenztes Volumen bei unendlicher Oberfläche habe, von
mir aus kann man das auch bei x=100 deckeln und ich brauche mehr als
3.14 Liter Farbe, wenn ich das Teil anmale, als wenn ich es ausgieße und
den Rest rausschütte. Ein logisches Paradoxon.
>> Logische Widersprüche in der Mathematik kenne ich zuhauf....
>>    
>
> Wissen wir seit Gödel, dass es so was geben muss. Aber was hat das mit
> der Verstehbarkeit eines Systems zu tun, das du nie selbst erfinden
> könntest?
>
>  
Ochja.... ich finde Mathematik zwar verständlich, es ist aber ein sehr
unlogisches Handwerkszeug.... im Studium habe ich mich daher auf eine
neue Art Mathe eingelassen, Differenzialformen - Symplektische Algebra
... hat mir normaler Mathematik nix mehr zu tun ... siehe Skript
Zwirnbauer ....
>> Lisp durchsucht bei Mehrfachvererbung ja die Klassenhierarchie in einer
>> vordefinierten Reihenfolge. Die erste Oberklasse wird genommen.
>>    
>
> Was meinst du damit? Wofür wird die "erste Oberklasse" genommen?
>
>  
Muß das Beispiel mal rauskramen ...
>> Bei C++
>> muß der Klassenname vorangestellt, also genau bestimmt werden. Unter
>> bestimmten Voraussetzungen, gerade im Zusammenhang mit
>> Grabage-Collection und Mehrprozessorsystemen gibt es gigantische
>> Schwierigkeiten, auch beim Compilerbau ...  daher -> Konzept wackelig.
>>    
>
> 1. Bei C++ oder Lisp?
>  
Lisp und auch bei C++ kann man so richtig Mist bauen damit.
> 2. Hab ich mit GC bei Einfachvererbungs-Sprachen wie Smalltalk nicht
>    die gleichen Probleme? Was hat GC überhaupt mit Vererbung zu tun?
>  
Alles bläht sich enorm auf, und im Falle der Mehrfachvererbung, sogar
rekursiv, wird es mit dem RAM kritisch ... das hat Auswirkungen auf die
GC. Ist komplizierter zu erklären ... siehe Google.
> 3. Nur weil die Implementation nichts taugt, muss ein Konzept nicht
>    wackelig sein.
>
>  
Ok. Sind meine Erfahrungen bisher ...
>> Außerdem kann es passieren, daß die Laufzeit des Programms explodiert,
>> völlig unvorhergesehen, z.B. dann, wenn sich die Katze in den Schwanz
>> beißt, sprich Oberklassen von Unterklassen umdefiniert werden.
>>    
>
> Was heißt, dass Oberklassen von Unterklassen umdefiniert werden?
>  
Jein. Die Instanzen mussen sich verändern. Im Falle dessen, daß Klassen
auch Objekte sind, verändern sich die Klassen dann ja auch mit. Je nach
Implementierung...
> Viel Zeugs eben, das das System unheimlich langsam macht. Rails ist
> das Vista der Ruby-Webframeworks. Vor vielen Jahren hat Avi Bryant
> ein Framework namens IOWA in Ruby begonnen, das er Kirk Haines vererbt
> hat. In nächster Zeit wird's da endlich die offizielle Version 1.0 geben
> und von der Geschwindigkeit und dem Ressourcenbedarf her ist das um
> Klassen besser.
>
>  
Aha, danke für den Hinweis.
> Gemstone war nicht ganz billig, als ich das letzte Mal nachgeschaut hab.
> Was mach ich, wenn ich das Geld nicht hab?
>
>  
Gemstone fragen, ob die Dir als Lehrer kostenlos eine geben, für
Unterricht. Haben die kein Problem mit, denke ich. Aha, fein, schaue ich mir an.
> 300 GB Textdaten? Unter 1/10 Sekunde? Mit Squeak? Cool. Wie groß ist
> denn da die Indexdatei?
>
>  
Mit Squeak noch nicht probiert, aber mit Glimpse habe ich Benchmarks
gefahren. Die Indexdatei schwankt etwas entsprechend der Verschiedenheit
der Dateninhalte und der Größe der Datenbank.... aber liegt bei 1.5-5%
des Datenvolumens. Nur - die Indizierung dauert ellenlange ...
verbraucht sehr viel Speicher. Google macht das ebenso - die Server
selber sind Cluster und recht klein. Die Indexer sind mächtig.....
> s.
>
>  

Guido

stepken (14.03. 00:56):

Ich persönlich sehe das Problem darin, dass die Zahl der Liter als
Raummaß mit der Zahl der m^2 der Oberfläche verglichen wird. Mein
Kühlschrank hat hinten einen Kondensator, in den weniger Kühlmittel
reinpasst als ich Farbe fürs Anstreichen brauchen würde. Und mein
Kühlschrank ist ein Liebherr, kein Paradoxon.

> Lisp und auch bei C++ kann man so richtig Mist bauen damit.

Natürlich. Aber auch bei Einfachvererbung ist das möglich. Heutzutage
sind Klassenhierarchien flacher als früher, weil mehr mit Komposition
gearbeitet wird als mit Vererbung. Wenn aber "richtig Mist" gebaut wird,
dann liegt es entweder an einer unsauberen Implementation des Konzepts
oder an einem Programmierer, der das Handbuch nicht gelesen hat.

> >2. Hab ich mit GC bei Einfachvererbungs-Sprachen wie Smalltalk nicht
> >   die gleichen Probleme? Was hat GC überhaupt mit Vererbung zu tun?
> >  
> Alles bläht sich enorm auf, und im Falle der Mehrfachvererbung, sogar
> rekursiv, wird es mit dem RAM kritisch ... das hat Auswirkungen auf die
> GC. Ist komplizierter zu erklären ... siehe Google.

hm... versteh ich nicht. Was hat die tatsächliche Referenzierung eines
Objekts für einen Zusammenhang mit seiner Abstammung? Ich gebe gerne zu,
von GC oder Compilerbau nicht wirklich was zu verstehen, aber ich sehe
das als zwei unabhängige Konzepte an.

> >>Außerdem kann es passieren, daß die Laufzeit des Programms explodiert,
> >>völlig unvorhergesehen, z.B. dann, wenn sich die Katze in den Schwanz
> >>beißt, sprich Oberklassen von Unterklassen umdefiniert werden.
> >
> >Was heißt, dass Oberklassen von Unterklassen umdefiniert werden?
> >  
> Jein. Die Instanzen mussen sich verändern. Im Falle dessen, daß Klassen
> auch Objekte sind, verändern sich die Klassen dann ja auch mit. Je nach
> Implementierung...

Äh... so wie in Smalltalk? Auch hier sehe ich den Zusammenhang mit
Mehrfachvererbung nicht. Bitte erleuchtet mich, Ahnungshabende :-)

> >Gemstone war nicht ganz billig, als ich das letzte Mal nachgeschaut hab.
> >Was mach ich, wenn ich das Geld nicht hab?
> >  
> Gemstone fragen, ob die Dir als Lehrer kostenlos eine geben, für
> Unterricht. Haben die kein Problem mit, denke ich.

jo... Microsoft macht das auch so. Nur blöd, dass ich leider nur den
Fisch für heute in der Hand halte und nicht gelernt hab, selbst zu
fischen.

s.
--
Stefan Schmiedl
+-------------------------------+----------------------------------------+
|Approximity GmbH               | EDV-Beratung Schmiedl                  |
|http://www.approximity.com     | Am Bräuweiher 4, 93499 Zandt, Germany  |
|mailto:[hidden email]  | Tel. (09944) 3068-98, Fax -97          |
+-------------------------------+----------------------------------------+

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.

--
Stefan Schmiedl
+-------------------------------+----------------------------------------+
|Approximity GmbH               | EDV-Beratung Schmiedl                  |
|http://www.approximity.com     | Am Bräuweiher 4, 93499 Zandt, Germany  |
|mailto:[hidden email]  | Tel. (09944) 3068-98, Fax -97          |
+-------------------------------+----------------------------------------+

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,

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: 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.pdf

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

--
**
** Frank Mueller / Oldenburg / Germany
**
** http://frank.mweb.de
**

Hallo Frank,

on Mon, 19 Mar 2007 16:27:44 +0100, you wrote:
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.

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

--
**
** Frank Mueller / Oldenburg / Germany
**
** http://frank.mweb.de
**

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 <[hidden email]> wrote:
> http://www.squeak.de/SqueakindeutschsprachigenHochschulen/

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

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 :)

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
>