[Squeak-ev] Etoys/Squeak vs. Scratch (Diskussionsbeitrag von Ralf Romeike)

[Enrico Schwass]

Guido Stepken <gstepken at googlemail.com> writes:

Hallo Guido,

Einige Anmerkungen zu deinen Kopfschmerzen

> 1. Einmal Smalltalk - die wollen nie wieder andere Programmiersprachen
> erlernen!

Das stimmt so nicht. Nur müssen die anderen Sprachen auch
überzeugen. Ich lerne gerade SBCL und auf Scala habe ich auch ein Auge
geworfen. Ganz so ist es also nicht. :)


> 2. Smalltalk ist Hacken, kein modernes Software Engineering, wie man
> z.B. mit JAVA und BlueJ lernen kann.

Pauschalurteil ohne Belege

Auf dieser Seite findet google Alan Kay, Pharo, Smalltalk, etc.

http://softwareengineering.vazexqi.com/


> 3. Multiprozessorunterstützung fehlt bislang (RoarVM kommt wohl bald)

Schön wäre das schon, aber nur ein Bruchteil aller Anwendungen braucht
das überhaupt. Und Videoschnitt macht man nicht mit Smalltalk :)

> 4. Erziehung zur Frusttrationstoleranz. Sich mal auch "durchbeissen
> müssen" durch Bits und Bytes

Slang, Plugins, FFI

> 5. Sinnlos erworbenes Wissen, da kein Entscheider Squeak einsetzen wird.

Was braucht man Entscheider, wenn man sich selbstständig macht?  Der
Kunde/Entscheider muss nicht mal wissen, dass er eine Smalltalklösung
geliefert bekommt. Und Banken und Versicherungen sehen es mitunter ganz
gern, dass man Smalltalk einsetzt.

> In Kürze werden alle Computer Mehrprozessorsysteme sein, ARM, INTEL,
> GPGPU's sogar massiv. Ein Parallelrechner mit 512 Prozesoren ist für
> unter 1000€ zu haben!

Ja, und der 387 wurde 1987 vorgestellt. Die zusätzliche Rechenkraft hat
kaum einer genutzt. Ist dann auch wieder vom Markt verschwunden. Die PS3
hat zwar 5 oder 6 Cores und die werden auch genutzt. Der Aufwand ist
aber erheblich und die Zielgruppe sehr klein.

Die heutige Rechenleistung wird im Bereich Codecs, Forschung, Spiele
gefordert. Alles keine typischen Smalltalkfelder.

> Smalltalk besitzt z.B. im Gegensatz zu Haskell keinerlei eingebauten
> Parallelismus. In Haskell sind alle verwendeten Algorithmen
> *GRUNDSÄTZLICH* parallelisierbar. Keine Library, die nicht
> vollautomatisch alle verfügbaren Prozessoren ausnutzt. C++0x wird da
> kaum hinterher stehen, GO ebenso. Smalltalk ist zwar theoretisch auf
> der RoarVM lauffähig, aber *ALLE* verwendeten Algorithmen in den
> Libraries sind Single - Prozessor Algorithmen. Smalltalk müsste, um
> eine Zukunft zu haben, angesichts der MP - Welle, *komplett*
> eingestampft und mit Parallelalgorithmen völlig neu implementiert
> werden.

Es wird sich zeigen, was der eingebaute Parallelismus in der Praxis
bringt.

> Es ist für einen Schüler einfach vertane Zeit, Smalltalk zu lernen,
> wenn er nach Schulschluß einen Nebenjob in einer Programmierfirma mit
> C++0x oder Java haben könnte.

http://c2.com/cgi-bin/wiki?MakeItWorkMakeItRightMakeItFast

Ich glaube kaum, dass ein Lehrer im Informatikunterricht C++ in der
gleichen Zeit in dem Umfang unterrichten könnte, wie er Smalltalk
vermitteln kann. Aber wir haben ja eine ausreichende Lehrerdichte hier
auf der Liste. Kann sich ja mal jemand dazu äußern.

Dazu kommt "Lines of code not written"

MakeItWork - MakeItRight. Scheitert da eher der C++ oder der
Smalltalk-Programmierer?

Enno