OLPC und Etoys in c't

In der aktuellen c't 07/2007 (derzeit am Kiosk zu haben) ist auf den  
Seiten 138 bis 145 ein großer Bericht zum OLPC-Projekt, und Etoys  
sind mit mehreren Screenshots und ein paar Zeilen Text präsent.

- Bert -

PS: Alle Abbildungen des Laptops sind von meinem Exemplar :)

On Mar 19, 2007, at 9:59 PM, Bert Freudenberg wrote:

> In der aktuellen c't 07/2007 (derzeit am Kiosk zu haben) ist auf  
> den Seiten 138 bis 145 ein großer Bericht zum OLPC-Projekt, und  
> Etoys sind mit mehreren Screenshots und ein paar Zeilen Text präsent.
>
> - Bert -
>
> PS: Alle Abbildungen des Laptops sind von meinem Exemplar :)

:-))

Ich seh das Teil immer wieder gern...
Hats zufällig irgendwo nen Scan?

Liebe Grüsse,

Markus

On Mar 19, 2007, at 22:14 , Markus Gaelli wrote:

Ich nicht. Meine c't hat Rita mit in Königstein, sie führt auch den  
Laptop vor.

Möglicherweise können wir ein Original-PDF von dem Artikel bekommen  
wenn die Zeitschrift aus dem Handel ist.

- Bert -

Ist geplant den Laptop auch mal hier in Bern spazieren zu führen? Wir  
möchte doch gerne mal so ein Teil in live sehen :lechz:

cheers,
Adrian "AA" Kuhn


On 19 Mar 2007, at 22:30 , Bert Freudenberg wrote:

Wir sind dabei, einen CHOOSE-SIG-Beer-Termin zu finden ...

- Bert -

On Mar 20, 2007, at 2:24 , Adrian Kuhn wrote:

Hallo, Squeaker!

Sehr nachdenklich hat mich gemacht, daß immer mehr Firmen auf die sog.
"bewährten" Sprachen und Frameworks (J2EE, JBOSS, RUBY ON RAILS, APACHE
+ PHP, PERL, PYTHON, ... für die Applikationsentwicklung setzen,
vornehmlich Web-basierte Applikationen, allen voran der Apache Server
mit seinen flexiblen Modulkonzept. Interessant ist, wieviel Geld zum
Fenster hinausgeschmissen wird, weil oftmals die Kosten von Entwicklung
und Wartung sowie Hardware aus oft unerfindlichen Gründen explodieren,
sogar Applikationen neu entwickelt werden auf anderen Plattformen. Hier
ein paar Anmerkungen zu den Hintergründen:

Außer Frage steht, daß die Entwicklungskosten umso niedriger sind, je
mächtiger das Framework ist, und ob es für die Aufgabenstellung
entwickelt wurde. Und dann gibt es noch erhebliche Folgekosten zu
bedenken, Debugging, Softwarewartung (Refactoring) und die oft horrenden
Kosten, wenn die Performance nicht ausreicht, Cluster für "load
balancing" nachgerüstet werden müssen, und katastrophal ist es, wenn
eine Applikation dauernd abstürzt. Entscheider verlassen sich nur auf
"bewährtes", den Mainstream. Und kollektive Irrtümer hat es zuhauf gegeben.

Zuerst zur Performance:

Sind reine Interpreter, z.B. Smalltalk, Ruby, Python gegenüber JIT -
Applikationen

David Shaffner hat sich 2005 die Mühe gemacht, die Performance von
Squeak gegen VisualWorks gegen Jigsaw Java gegen Python, Ruby und Apache
getestet.
http://wiki.squeak.org/squeak/539 Er ist hier zu finden:
http://www.cs.westminster.edu/~shaffer/Smalltalk/

Was er dort anspricht und misst, muß man erst einmal in Deutsch
übersetzen. Async I/O und Async File I/O sind zunächst einmal
Eigenschaft des Betriebssystems, die Fähigkeit, simultane Datenströme
von/auf Festplatte und von/richtung Netzwerk handeln zu können. Was
nutzt es, wenn z.B. der Webserver theoretisch 1000 simultane Anfragen
beantworten könnte, jedoch das Betriebsystem immer nur 1 File
gleichzeitig liefern kann, gilt auch für RAW DEVICES bei Datenbanken.
Resultat - die Datenströme brechen ab, die Latenzzeiten erhöhen sich.
Dann kommt Async I/O über die Netzwerkkarte hinzu. Hierdurch erst wird
das Betriebssystem richtig performant, weil es gleichzeitige viele
Netzwerkverbindungen nicht nur gleichzeitig offenhalten (siehe netstat),
sondern auch mit Datenströmen bedienen kann. Man spricht hier von
blocking, non blocking und async I/O. Die Betriebssysteme in der
Vergangenheit, die das locker beherrschten, waren z.B. HP - UX, AIX,
Solaris, Digital UNIX / True64 /  VMS, Free/NetBSD ... Linux erst seit
2.6.9+ . Die Zahl der Network - und Filehandels, die das BS gleichzeitig
verwalten kann, stellt ebenfalls eine Grenze dar. Könnte die Applikation
1000 veschiedene Files ausliefern, so wird sie oft daran gehindert, weil
z.B. nur 256 gleichzeitige Files bzw. 256 Netzwerkverbindungen offen
gehalten werden können. TCP/IP Verbindungen brechen oft dann ab. So
unterscheiden sich z.B. die verschiedenen Versionen von Windows NT
Server und Vista stark von den Windows Vista Home / Professional
/Ultimate Editionen. Die Zahl der Network - und Filehandels wurde bewußt
kastriert. Wer z.B. FreeBSD oder insbesondere NetBSD einsetzte war
hierin völlig unbegrenzt. Diese BSD - Typen sind in jeder Hinsicht
unbegrenzt, ohne Tuning. Ist das BS von diesen Verklemmungen befreit, so
kommen architekturbedingte Verklemmungen auf Applikationsseite hinzu. So
müssen z.B. einige Applikationen, um mehrere gleichzeitige Anfragen
bedienen zu können, "forken", also Kopien von sich im RAM starten, damit
eine zweite eingehende Netzwerkverbindung bedient werden kann, das CGI -
Konzept. Fortschrittlicher sind hier dann sog. Multi-Threaded Server, wo
zwar auch Kopien im RAM erzeugt werden, jedoch aufgrund des geteilten
Datenbereiches weniger RAM verbraucht. Diese Server "skalieren" über
mehrere CPU's. Noch fortschrittlicher sind hingegen wieder
Single-Threaded Server - wo ein Server für jede eingehende
Netzwerkverbindung eine neue Queue anlegt, und diese dann versucht, die
Datenströme der Reihe nach 'round robin' zu bedienen. Komischerweise
sind dies die absolut schnellsten Server (Zeus) Unter FreeBSD  und
NetBSD genügt hierbei nur eine einzige CPU, um 4 x 100 MBit mit
Datenströmen "sättigen" zu können. Skalieren tut das System damit
offiziell also nicht, es ist aber sauschnell und - sofern es ASYNC I/O
und ASYNC FILE I/O beherrscht, kann es sogar zigtausendtausende
simultane Datenströme fließend bedienen, wo die Daten kontinuierlich in
jede Richtung fließen, zwar langsamer, aber gleichmäßig, nicht abrupt
wechselnd.
Und nun kommt das Problem mit den Threads. Für jeden Kernel - Thread
(siehe auch das Konzept der PTHREADS) wird mindestens 1 MByte RAM
fällig. Bei tausend simultanen Netzwerkverbindungen wird also z.B. ein
Programm, welches Datenbankverbindung herstellt, aufbereitet und diese
dann ausliefert, tausendfach kopiert, macht 1 Gigabyte RAM Verbrauch,
nur allein, um die Netzwerkverbindungen offenhalten zu können. Da
braucht man dann plötzlich Multi-CPU Serversysteme mit LOAD Balancing,
die Folgekosten explodieren. Denial of Service Angriffe werden hierbei
recht einfach. Daher haben die Hersteller von BS die Zahl der Netzwerk -
Handels begrenzt, auch eine Art Schutz vor Überlastung.
Apache 2.x besitzt daher eine Mischung aus Single-Threaded Server, wo
jede Serverinstanz mehrere 1000 "einfache" HTML - Seiten ausliefern
kann, und einem "pre-forking"  Server, wo für jedes Skript, welches
aufgeführt wird, je eine Kopie des Apache-Servers und der zugehörige
PHP/Python/PERL Interpreter gestartet werden muß, auch wieder viele
Megabyte jeweils groß. FASTCGI bedeutet eine Art asynchrone Abarbeitung
der Skripte in einem Interpreter. Sie werden der Reihe nach FIFO
abgearbeitet, es existiert aber nur 1 Instanz des Interpreters im RAM,
ebenfalls sehr Speicheraufwändig. Nun kommt noch ein Nadelöhr.
Datenbank. So werden z.B. bei einigen Datenbanken bei 100 gleichzeitigen
Verbindungen 100 Kopien des Servers im RAM erzeugt. PostgreSQL z.B.
verfolgt ein anderes Konzept - 1 Server und je Netzwerkverbindung wird
eine Kopie eines PostgreSQL Clients erzeugt. Das ist viel sparsamer, als
eine Kopie des kompletten SQL Servers im RAM zu halten.
Und nun die pfiffigste und billigste Kombination. Betriebssystem mit
ASYNC I/O, ASYNC FILE I/O (auch für RAW DEVICES bei DATENBANKEN), 2
CPU's, mehrere Netzwerkkarten, 2 auf unterschiedlichen CPU's gestartete
Server-Threads mit Single-Threaded Technik, unlimited File - und
network-handels, und dann muß natürlich der Server auch Async I/O und
Async File I/O auch nutzen können. Wie nun handelt diese Single-Threaded
- Technik 100.000 simultante Anfragen, wo Datenbank-Inhalte ausgeliefert
werden müssen? Nun - alles muß in Single-Threaded - Technik mit Async
I/O und Async File I/O durchgängig implementiert worden sein. Wie
unterscheidet nun der Server die verschiedenen "Zustände" der
eingehenden Verbindungen? - "Green Threads" für jede Netzwerkverbindung
wird ein sog. "green thread" aufgemacht, also innerhalb des Interpreters
eine Art Multi-Tasking ausgefürt. Der Interpreter verwaltet also
eigenständig die vielen Tasks, legt selber Stapel (queues) an, arbeitet
diese in schnellem Wechsel, also scheinbar fließend, ab. Vorteil dieser
"green threads" ist, daß für jeden Thread nur ca. 700-900 Byte !!!!
(nicht Megabyte) RAM verbraucht werden. Nanu?

Das Online-Game "EVE" ist das Paradebeispiel für diese Technik. 1
Stackless PYTHON - Interpreter (arbeitet mit Continuations, einer Art
"goto" mit entsprechenden Nachteilen...dafür aber schnell!) verwaltet
selber die Threads für TCP/IP, Server und Datenbank, und zwar in einer
affenartigen Geschwindigkeit, obwohl oder gerade weil Interpreter:
30.000-100.000 simultane Datenströme aus der Datenbank, kontinuierlich
in alle Richtungen fließend, verbinden Spieler mit einer gemeinsamen,
virtuellen Welt. Servertechnik: FreeBSD 1 CPU, 4 GByte RAM, 8
Netzwerkkarten ! Dieselbe Technik in IRONGATE - einem Mailserver, welche
ebenfalls 100.000 Mail-Datenströme gleichzeitig ausliefern kann. Diese
werden für Spamming vorwiegend eingesetzt, weil die 300.000 Mails je
Stunde rausschieben können, wobei sie auch GBit Netzwerkkarten sättigen.

Welche Technik unterstützt SQUEAK nun? Nun - Squeak ist "nur"
Single-Threaded und nutzt auf bestimmten Betriebssystemen tatsächlich
ASYNC I/O. Unter HP-UX, FreeBSD/NetBSD, OS X, Linux 2.6.9+, nur nicht
unter Windows. Squeak auf Linux mit aktiviertem Async I/O haut die Daten
aus der Netzwerkarte raus, das es eine Freude ist, zuzusehen. Der Apache
- Benchmark "ab" von Zeus Technologies beweist es. Es bedarf keines
VisualWorks Smalltalk oder Multi-Threaded - Technik, um auf Performance
zu kommen, sondern nur der Beachtung dieser Kleinigkeit. David Shaffner
hat Code Snippets in seinem Beispiel beigefügt, die dann Squeak
befähigen, die Async I/O+File Eigenschaften des darunterliegenden BS
auch nutzen zu können. Die hunderttausenden TCP/IP Verbindungen mit
Green Thread - Technik kann man dann einfach nutzen ... net :=
HTTPSocket httpGET: 'http.....'. fork net. Und das in einem kleinen
Schleifchen verpackt, macht ab auch alle Ehre ...
http://www.oldenbuettel.de/squeak-doku/Network-Kernel/Socket.html Viele
der Routinen sind für ASYNC ausgelegt.
Bevor man sich mit der Performance bestehender HTML - Server in Squeak
herumschlägt, hat man schnell selber einen Webserver mit Green Threads
und Semaphoren selber geschrieben, und nutzt dann die OO-Datenbank in
Squeak selber oder auf der CPU, z.B. MAGMA. Damit laufen dann sowohl
Webserver, als auch Datenbankserver und Datenbankapplikation in einem
Interpreter - klein, flink, sparsam im RAM, und - diese Kombination erst
macht das System wahnsinnig schnell, gegenüber den Multi-CPU Servern mit
Multi-Threading Applikationen, die tierisch CPU - Zeit allein für die
Synchronisation der Tasks und die Zeitscheibenverteilung auf der CPU,
Semaphoren, Network-Events ... aufwenden müssen.

Mit einem 500 Mhz Powerbook konnte man auch damals schon (Jahr 2000) mit
Squeak eine 100 MBit - Karte sättigen! Wie?
http://www-sor.inria.fr/~piumarta/squeak/unix/j3/Squeak-2.8/src/macos/sqMacNetwork.c

Es ist wirklich kein Problem, einen Green - Thread http - Server in
Squeak zu programmieren. Wie das geht, zeigen auch RUBY und Python, da
liegen die im Quellcode herum. Nun - Smalltalk hat eine noch einfachere
Syntax, man kann aber flüssig beim Lesen von Python Code Smalltalk
programmieren .... ;-)

Und wer dann will baut eine 2. CPU ein, startet eine 2. Squeak Engine
auf der 2. CPU worin z.B. der Datenbankserver läuft, oder stellt einen
Server daneben.

Und wer dann noch mehr Performance braucht, schaltet einen invertierten
Proxy, z.B. SQUID hinzu. Dynamische Seiten, welche schon mal so
ausgeliefert wurden, werden gecacht, die Anfragen gelangen erst garnicht
mehr zum Interpreter. So kann man die Performance durchaus, trotz
dynamischer Inhalte auf 10.000 ausgelieferte kleine HTML -
Seiten/Sekunde erhöhen (selber getestet und oftmals implementiert). Und
wer dann noch mehr Performance braucht, schaltet einfach einen LINUX
LOAD - Balancer davor, diese Technik kann Linux von Hause aus:
http://www.little-idiot.de/linuxsolutionguide/lvs.htm Damit kann man
sich dann z.B. den CICSO LOCAL DIRECTOR ersparen. Damit fallen dann auch
die evtl. Unterbrechungen der Smalltalk VM bei der FULL Garbage
Collection nicht mehr auf, oder die (winzigkleinen) Unterbrechungen bei
dem Recompilieren, wenn man Updates einspielt.... (und nicht vergessen,
Background CPU Power zu aktivieren ... in der Squeak VM)
Tatsache ist auch, daß z.B. Microsoft in seinem IIS und auch in JBOSS,
J2EE heimliche "Caches" enthalten sind, genaugenommen dieselbe Technik,
wie beim invertierten SQUID Proxy (iX hat darüber berichtet). Zaubern
können die alle nicht, wollen aber bei Benchmarks immer glänzen. Und
eine alte Weisheit besagt -

                                                "Ein Entscheider kauft
immer nur die Präsentation!"

Zu IronPython:
http://www.google.de/search?hl=de&client=firefox-a&rls=org.mozilla%3Ade%3Aofficial&hs=vcZ&q=ironpython+eve+game&btnG=Suche&meta=

Übrigens - XING ist eine voll dynamische Homepage, mit RUBY (ASYNC I/O
natürlich) Interpreter dahinter. Die Performance ist mit der von Squeak
und der Smalltalk VM durchaus zu vergleichen. Auf JIT - Compiler und
"Multi-Threaded" Implementierungen bei Squeak zu warten, ist nicht
nötig, die Performance würde sich eh nur Faktor 2 (JIT) erhöhen,
maximal. Ich freue mich schon auf die neuen IBM CELL PROZESSOREN auf PS3
mit Linux und Squeak drauf.... ;-)
http://www.gamezone.de/news_detail.asp?nid=47638

Kleine Internas der Squeak VM, für die, die Spaß daran haben, Workspace
auf:

Smalltalk garbageCollect. <ALT>-P -> Full GC, returns bytes free.
Smalltalk garbageCollectMost. -> Incremental GC
Smalltalk getVMParameters.  -> Raw GC numbers.
Smalltalk extraVMMemory. -> Get/Set extra Heap Memory (veraltet)
Smalltalk bytesLeftString. -> Get bytes free + expansions
Smalltalk setGCSemaphore. -> Semi to signal on IGC
Smalltalk setGCBiasToGrow. -> setGCBiasToGrowGCLimit:
Smalltalk isRoot: /isYoung:/rootTable/rootTableAt: Which memory space is
that object in, or is it a root?

Mehr, siehe Google....

Daß die Entwicklungszeigen bei Smalltalk nur 1/3 bis 1/6 derjenigen von
C++ und 1/2-1/3 derjenigen mit JAVA (oder C# bzw. .NET) und etwa
gleichauf mit Ruby on Rails bzw. Apple WebObjects (schon seit NextStep
ungeschlagen) liegt, dürfte zu denken geben. Softwarewartung ist
ungleich billiger mit Smalltalk.

Tja, was sagen die Marketing - Leute dazu: "Esst Scheiße, millionen
Fliegen können nicht irren!" Meine Liste jedenfalls der gescheiterten
J2EE / JBOSS Großprojekte wird täglich länger, nicht nur seit dem
gescheiterten Projekt FISCUS der Bundesregierung, nein auch viele
weitere bei großen Unternehmen. Smalltalk - Projekte komischerweise
werden viel öfter Erfolge, ob es an dem Verstand der Entwickler und
Entscheider liegt, die sich nicht von dem Marketing Hype beeindrucken
lassen? Kollektive Wahrnehmungsstörungen?

Viele Grüße, Guido Stepken

On Mar 20, 2007, at 12:20 , stepken wrote:

> Hallo, Squeaker!

Hallo Guido.

Dir ist schon klar, dass du hier dem Chor predigst? Ich für meinen  
Teil find das gut und erfrischend, aber die Leute hier auf der Liste  
musst du eigentlich nicht mehr von den Vorteilen von Squeak  
überzeugen ... Mit deinem Enthusiasmus würdest du aber einen  
hervorragenden Pressesprecher des Vereins abgeben. Lust?

>  Stackless PYTHON - Interpreter (arbeitet mit Continuations, einer  
> Art "goto" mit entsprechenden Nachteilen...dafür aber schnell!)

Macht Seaside genauso. Und alle Welt staunt, was man damit hinbekommt.

> Bevor man sich mit der Performance bestehender HTML - Server in  
> Squeak herumschlägt, hat man schnell selber einen Webserver mit  
> Green Threads und Semaphoren selber geschrieben

Hat Comanche wirklich so viel Overhead?

Abgesehen davon würde dennoch ein mod_squeak für Apache entscheidend  
zur Verbreitung beitragen.

- Bert -

Bert Freudenberg schrieb: Nun, warum sollte ich nicht ein Entscheider Pamphlet verfassen, welches
dann auf die Homepage kommt?
>>  Stackless PYTHON - Interpreter (arbeitet mit Continuations, einer
>> Art "goto" mit entsprechenden Nachteilen...dafür aber schnell!)
>
> Macht Seaside genauso. Und alle Welt staunt, was man damit hinbekommt.
>
Darum schrieb ich es ;-)
>> Bevor man sich mit der Performance bestehender HTML - Server in
>> Squeak herumschlägt, hat man schnell selber einen Webserver mit Green
>> Threads und Semaphoren selber geschrieben
> Hat Comanche wirklich so viel Overhead?
Jepp. Nun, mit inzwischen fast 20 Programmiersprachen (keine Sorge, wenn
man mit 12 schon Z80 Assembler programmiert hat ...häufen sich die an
...) und einem erheblichen Background in Assembler, BS - Kernroutinen,
Threads ... kann ich sagen, daß da einige Dinge nicht sauber laufen
können. Ich vermute Versäumnisse in ASYNC I/O  und FILE sowie bei
Semaphoren (überflüssiges polling, fehlerhafte I/O event notification )
... typische Dinge eigentlich, die nur Kernel - Programmierer genau
kennen... Ich bin ja immer begeistert, wenn ich BS Routinen auch mit
Smalltalk (PERL, Python kenne ich schon sehr gut, Ruby auch) ansteuern
kann. So genau habe ich mir den aber nicht angeschaut.
>
>
> Abgesehen davon würde dennoch ein mod_squeak für Apache entscheidend
> zur Verbreitung beitragen.
Huch. Wozu denn das? Squeak als Think -Client und Plugin im Browser ist
doch schon der Hammer, kann, wenn vernünftig vermarktet, Shockwave und
Flash locker wegblasen.

Apropos: Euer Image habe ich mal installiert, läuft klasse. Es fehlen
mir nur die repeatTimes Kachel (Patch einspielen) und ich bekomme erst
in Etoys die Objekt - Flap, wenn ich zuvor auf Englisch umstelle, die
aktiviere im Klappenmanager und dann wieder auf Deutsch umstelle. Warum?

Ein Apache_mod_Squeak zu programmieren ist sicher möglich, nur - was
würdest Du ins Image packen?

Guido Stepken

On Tue, 20 Mar 2007 12:20:25 +0100, stepken wrote:
> Hallo, Squeaker!

Hallo Guido.
...
> Meine Liste jedenfalls der gescheiterten J2EE / JBOSS Großprojekte wird  
> täglich länger, nicht nur seit dem gescheiterten Projekt FISCUS der  
> Bundesregierung, nein auch viele weitere bei großen Unternehmen.  
> Smalltalk - Projekte komischerweise werden viel öfter Erfolge, ob es an  
> dem Verstand der Entwickler und Entscheider liegt, die sich nicht von  
> dem Marketing Hype beeindrucken lassen? Kollektive Wahrnehmungsstörungen?

Wie kommst Du denn darauf (auf Wahrnehmungsstörungen)? Wenn während 10  
Jahren 10 Smalltalk Projekte (incl. Squeak etc, als Sammelsorium) gemacht  
werden und in derselben Zeit die Millionen von anderen Projekten gemacht  
werden, dann muss doch klarerweise ein Fehler in der Mathematik vorliegen,  
odr :) Könnte ja mal an die FOM Liste berichtet werden ;-)

Cheers
Klaus

> Viele Grüße, Guido Stepken
>

Am Monday, 19. March 2007 22:30 schrieb Bert Freudenberg:
> On Mar 19, 2007, at 22:14 , Markus Gaelli wrote:
> > On Mar 19, 2007, at 9:59 PM, Bert Freudenberg wrote:
> >> In der aktuellen c't 07/2007 (derzeit am Kiosk zu haben) ist auf
> >> den Seiten 138 bis 145 ein großer Bericht zum OLPC-Projekt, und
> >> Etoys sind mit mehreren Screenshots und ein paar Zeilen Text präsent.
> >>
Ich schreib jetzt den Text ab:
"Die EToys sind eng mit Squeak verknüpft, einem Dialekt der objektorientierten
Programmiersprache Smalltalk. In zahlreichen Projekten in den USA, aber
beispielsweise auch in Deutschland, der Schweiz und Österreich beschäftigen
sich Lehrer, Psychologen und Didaktiker mit den Möglichkeiten, die die
quelloffene Entwicklungsumgebung im mathematisch-naturwissenschaftlichen
Unterricht bietet. Der Begriff EToys, der häufig synonym für Squeak verwendet
wird, bezeichnet eine kindgerechte Oberfläche, die jüngeren Schülern einen
Zugang zu dieser Programmiersprache bietet. Sie können darin sehr leicht
selbst gemalte Objekte animieren und deren Verhaltensweisen auf dem
Bildschirm beobachten. So setzen sie sich spielerisch etwa mit physikalischen
Konzepten von Geschwindigkeit oder Beschleunigung auseinander."

In Österreich? Gerhilde, bist Du noch da?
Psychologen? Bei uns nicht, oder?
Der Text ist  doch ganz nett, find ich.

Gruß
Esther

Hallo

> In Österreich? Gerhilde, bist Du noch da?
> Psychologen? Bei uns nicht, oder?

Ich bin mir nicht sicher, aber gabs nicht an der Humboldt-
Universitaet in Berlin einen Psychologen,
der Squeak in seinen Vorlesungen benutzt?

Aja hier
http://zope.psychologie.hu-berlin.de/prof/ingpsy/forschung/tools/ 
squeaksim

Tschuess
Enno

Guten Morgen,
Ja, das bin ich. Aber wir tun nichts für den naturwissenschaftlichen
Unterricht.
Als Vater eines Schülers in der 6. Klasse habe ich aber immerhin schon die
Squeak-DVD, Links zu Squeak / Scratch und Hinweise auf Tutorials an den
Fachbereichsleiter Informatik übergeben. Habe auch angeboten, für einen
Workshop zur Verfügung zu stehen. Mal sehen...  

Viele Grüße

Knut

*exampleWithNumber:* /x/

"A method that illustrates every part of Smalltalk method syntax

except primitives. It has unary, binary, and keyword messages,

declares arguments and temporaries, accesses a global variable

(but not and instance variable), uses literals (array, character,

symbol, string, integer, float), uses the pseudo variables

true false, nil, self, and super, and has sequence, assignment,

return and cascade. It has both zero argument and one argument blocks."

|y|

true & false not & (nil isNil) ifFalse: [self halt].

y := self size + super size.

#($a #a "a" 1 1.0)

do: [:each | Transcript show: (each class name);

show: ' '].

^ x < y