[Squeak-ev] Das fängt ja gut an

[Andreas Raab]

Jürgen Beckmerhagen wrote:
> Andreas - Guido's Antwort auf meinen Forum-Eintrag erreichte mich 
> während ich mich wieder einmal - diesmal freiwillig - mit der Geschichte 
> Europa's nach der Französischen Revolution beschäftigte. Revolutionen 
> finden ja bekanntlich nur in den Köpfen statt.
> 
> Vielleicht sollte ich den Unterschied zwischen imperativen / 
> objekt-orientierten Sprachen und funktionalen Sprachen wie Scheme, LISP 
> o. ä. anhand von Lego-Bausteinen erklären. Passt doch zu Etoys und 
> Scratch. Lego kennt jeder: Damals gab es Lego nur in der rechteckigen 
> Form als 2er, 4er und 8er Steine. Und mit diesen sehr, sehr einfachen 
> Steinen konnte man unglaublich kreativ werden. Als es dann von Lego auch 
> abgeschrägte Dachziegel gab, sahen die Häuser zwar schöner aus, doch die 
> Kombinierbarkeit dieser Steine mit anderen Steinen war sehr 
> eingeschränkt. Und heute? Der Zeitgeist gebietet "vollständige 
> Bausätze": UFOs, Ritterburgen, Flugzeuge, Tankstellen ... Kreativität 
> gleich Null. Kombinierbarkeit kaum wahrnehmbar.
> 
> Ich hoffe, dass ich nicht zu sehr abschweife. Meine Erfahrung ist nur, 
> dass die Programmiersprachen stetig komplexer werden - genauso wie die 
> Lego-Bausätze. Das Konzept von LISP findet auf 1,5 Seiten Platz - 
> Pascal, Modula, C++, Java benötigen hunderte von Seiten. Funktionale 
> Sprachen sind wunderbar einfach (wenn man mal von den vielen Klammern 
> absieht). Und gerade diese Einfachheit verleihen ihnen Mächtigkeit und 
> Flexibilität. Ursprüngliches Lego eben.

Damit stimme ich durchaus ueberein. Womit ich nicht uebereinstimme ist 
die Behauptung das *nur* funktionale Sprachen eine entsprechende 
Einfachheit und Flexibilitaet haben koennen und das *alle* funktionalen 
Sprachen dies auch in Zukunft haben werden. Warte mal bis Microsoft 
Visual H++ auf den Markt wirft ;-)

Interessant in diesem Zusammenhang ist auch Ian's Pseudo-Lisp, was 
definitiv nicht funktional ist (wg. seiner dualen Daten- und 
Programmstruktur) aber so ziemlich die simpelste imperative Sprache die 
ich je gesehen habe (ich habe leider keine Referenz zur Hand aber schau 
mal bei VPRI.org vorbe).

Ciao,
   - Andreas

> Mein Anliegen ist, diese Einfachheit und Mächtigkeit zugleich dem 
> "normalen" Anwender zugänglich zu machen. Wenn ich Kreativität fördern 
> will, kann ich dem Anwender keine vollständigen Bausätze vorsetzen - und 
> wenn, dann bitte nur Bausätze, die aus sehr wenigen Grundbausteinen 
> bestehen.
> 
> End-user development (mir fällt kein deutsches Wort ein) und highly 
> collaborative Systems - darum geht es mir. Dieses Anliegen motiviert 
> mich, mich mit Sprachen wie Smalltalk und Systemen wie Squeak und 
> Anwendungen wie Etoys und Scratch zu beschäftigen. Ich vermute (!), dass 
> sich in diesem Kontext Konzepte der funktionalen und der 
> objekt-orientierten Programmierung hervorragend ergänzen (sofern man 
> denn die Objekte nur einfach genug hält).
> 
> Jürgen Beckmerhagen
> 
> 
> 
> Am 06.12.2007 um 18:54 schrieb Andreas Raab:
> 
>> Jürgen Beckmerhagen wrote:
>>> Im Moment erscheint mir Guido's Gedankengang in Bezug auf funktionale
>>> Programmiersprachen und die aufgezeigte Parallele zu Alan Kay's These
>>> "Die Revolution hat noch nicht begonnen" durchaus nachvollziehbar.
>>> Gerade die Assoziation "Revolution <-> Funktionale Programmierung" finde
>>> ich aeusserst spannend.
>>
>> Das ist nicht die Assoziation die Alan damit im Sinn hat. Die 
>> "Revolution" is die Simulation und der sich daraus ergebende 
>> Erkenntnisgewinn, nicht irgendein Programmierparadigma. Wenn z.B. 
>> jedermann in der Lage ist die (ziemlich willkuerlichen) Behauptungen 
>> von Politikern zum Thema Global Warming trivial mal eben zu 
>> ueberpruefen, *dann* beginnt die Computer-Revolution. Und ob das mit 
>> Java, Haskell, Excel, oder Scratch passiert ist, mit Verlaub, 
>> sch****egal ;-)
>>
>>> Funktionale Programmierung muendet in dynamischen und flexiblen Systemen
>>> - also genau dem Gegenteil von Systemen mit Objekt-orientiertem Entwurf
>>> und starker Typisierung. Letztlich ist Objekt-orientierte Programmierung
>>> i. d. R. imperative Programmierung, nur dass sich die Prozeduren auf
>>> eine genau definierte Datenstruktur beziehen. Dies erleichtert die
>>> Arbeit des Programmierers ungemein, loest aber auch nicht das Problem
>>> der aeusserst statischen Systeme.
>>
>> Ich bin verwirrt: Was genau heisst "aeusserst statisch"? Und wie 
>> vermeiden funktionale Systeme das?
>>
>>> Hinzu kommt, dass dem Anwender i. d. R. der Einblick in die Objekte, die
>>> er in seinem Computer benutzt, verwehrt bleibt. Der Anwender ist dumm
>>> und wird dumm gehalten. Imperative Vorgehensweise halt.
>>
>> Und das ist anders bei funktionalen Systemen? Erlaeuter' das doch mal 
>> naeher.
>>
>>> Was passiert, wenn "das Volk" lesen und schreiben lernt und Zugang zu
>>> den Erkenntnissen der Geistes- und Naturwissenschaften erhaelt, erfahren
>>> wir als Nach-1793er-Generation taeglich. Das Internet ist nur ein
>>> Beweis.
>>> Wir Software-Architekten muessen langsam zugeben, dass wir das sichere
>>> und stabile System mit Objekt-orientierten Konzepten allein niemals
>>> bauen koennen.
>>> In sofern ist das "One Laptop Per Child"-Projekt aeusserst spannend:
>>> Kinder werden auf Basis eines objekt-orientierten Systems in die
>>> funktionale Denkweise eingefuehrt: sie stecken sehr kleine Teile zu
>>> aeussert maechtigen System zusammen - genau das Prinzip der Funktionalen
>>> Programmierung!
>>
>> Nein, das ist *modular* nicht funktional. Und gerade objektorientierte 
>> Systeme sind erstklassig in der Lage ein modulares Design umzusetzen.
>>
>> Ciao,
>>   - Andreas
>