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
