Das fängt ja gut an

Guten Morgen,

ich darf mich kurz vorstellen - ich bin 51 Jahre alt und seit etwa 31  
Jahren in der Softwareentwicklung für die Touristik-Industrie tätig.  
Ab und an gebe ich in meinem Blog "http://
juergenbeckmerhagen.blogspot.com" ein paar allgemeine Gedanken zum  
Thema Computer und Software von mir.

Seit wenigen Tagen beschäftige ich mich mit Smalltalk. Es ist  
praktisch "Liebe auf den ersten Blick". Meine fünfjährige Tochter  
wartet nun gespannt darauf, dass ich das kleine, mit Etoys  
"gebastelte" Auto um einen explodierenden Airbag verfeinere und dass  
wir endlich gemeinsam an zwei getrennten Macs Autos gegeneinander  
fahren lassen können.

Derweil habe ich meine Kollegen in den USA und in Deutschland heiß  
gemacht und ihnen gezeigt, wie selbst Anfänger in Squeak kleine  
Anwendungen scripten können. Nichts aufregendes: ein Auto und ein  
Taschenrechner - viel mehr kam noch nicht heraus.

Ich suche also dringend nach Unterstützung, mit der ich eine kleine  
Büro-Anwendung auf die Beine stellen kann. Ungefähr so: In einer  
Schublade (flap) habe ich eine Vorlage für Aktenschränke, für Ordner  
und für Formulare. Ich ziehe einen Aktenschrank auf meine  
Arbeitsoberfläche, gebe ihm einen Namen. Als nächstes ziehe ich ein  
Formular auf meine Oberfläche, fülle es aus, lege es in einen leeren  
Ordner, der Ordner beschriftet sich automatisch, und abschließend  
stelle ich den Ordner in den Aktenschrank. Der Aktenschrank zeigt an,  
dass ein Ordner im Schrank ist. Weitere Ordner kommen hinzu und  
vorhandene werden vernichtet. Und so weiter. Eigentlich ganz simpel,  
wenn ich den Smalltalk und Squeak Wikis und Foren glauben kann.

Ach ja - und ich möchte, dass ich meinen Arbeitsplatz mit meinem  
Kollegen "share" - what I see is what you see...

Nur - wie fange ich an? Ich will nicht warten, bis mir Kinder aus  
Entwicklungsländer zeigen, wie es geht. Ich will es jetzt!

Vielen Dank für Eure Hilfe.

Jürgen Beckmerhagen.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Moin

> Seit wenigen Tagen beschäftige ich mich mit Smalltalk. Es ist  
> praktisch "Liebe auf den ersten Blick".

War es bei mir auch. Es hat schon eine ziemliche Anziehungskraft.

> Meine fünfjährige Tochter wartet nun gespannt darauf, dass ich das  
> kleine, mit Etoys "gebastelte" Auto um einen explodierenden Airbag  
> verfeinere und dass wir endlich gemeinsam an zwei getrennten Macs  
> Autos gegeneinander fahren lassen können.
> Derweil habe ich meine Kollegen in den USA und in Deutschland heiß  
> gemacht und ihnen gezeigt, wie selbst Anfänger in Squeak kleine  
> Anwendungen scripten können. Nichts aufregendes: ein Auto und ein  
> Taschenrechner - viel mehr kam noch nicht heraus.

Hmm ... mit den e-Toys kenne ich mich überhaupt nicht aus. Scripts  
habe ich bisher nicht angefasst.

Ganz so schnell und einfach geht es sicherlich nicht. :)
Und das Einarbeiten kann dir keiner abnehmen.

Mein Vorschlag wäre: Squeak + Seaside. Es ist doch unerheblich, ob  
man für die Darstellung Morphic (in Squeak) oder den Browser benutzt.
Seaside kann auch Drag and Drop. Seaside ist sehr gut dokumentiert  
(nicht zuletzt vom HPI), die Mailingliste ist voller Traffic.

Hier gibts ein Video, was mit Squeak und Seaside möglich ist.  
Dahinter dürfte aber ein grösseres Team stecken.

http://www.cmsbox.com/video.html

Hoffe es hilft
Enno
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFHQVOSRar8+mLBvIcRAl7aAJ4pICOTRDMdlufCADH/FxvMF5uHdQCdHR0R
79NFznQzDNaztkk36VG99so=
=rHPR
-----END PGP SIGNATURE-----

Hallo Enno,

vielen Dank für die prompte Antwort und den Verweis auf CMSBOX.  
Beeindruckend ...

Im Moment interessiert mich besonders, ob ich bei Squeak mit meinen  
Büro-Anwendungs-Ambitionen richtig aufgehoben bin, oder ob ich mich  
eher in Richtung VisualWorks oder ähnlichem orientieren soll, weil es  
dort vielleicht bessere GUI-Designer gibt - keine Ahnung.

Seaside ist mir auch schon untergekommen - die OneClick-Version läuft  
bereits auf meinem Rechner. Und ich kann mir vorstellen, einige  
wenige Anwendungen auch mit Seaside zu implementieren, sofern die  
Objekte mit in Squeak auf dem Desktop geshared werden können.

Nur träume ich davon, ein weitestgehend von Servern unabhängiges  
System zu bauen - quasi ein Croquet für das Büro. Schließlich haben  
die meisten von uns ein kleines Rechenzentrum auf ihrem Schreibtisch  
stehen, und warum sollte ich dann einen Flaschenhals mit Servern  
produzieren. Genau aus dieser Ecke möchte ich ja heraus.

Jürgen.


Am 19.11.2007 um 10:12 schrieb Enno Schwass:

Moin

> vielen Dank für die prompte Antwort und den Verweis auf CMSBOX.  
> Beeindruckend ...
> Im Moment interessiert mich besonders, ob ich bei Squeak mit meinen  
> Büro-Anwendungs-Ambitionen richtig aufgehoben bin, oder ob ich mich  
> eher in Richtung VisualWorks oder ähnlichem orientieren soll, weil  
> es dort vielleicht bessere GUI-Designer gibt - keine Ahnung.

Seaside läuft auf auf beiden Smalltalks. Ich würde eher zu Squeak  
raten, da du sowieso mit deiner Tochter rumprobierst.
Musst du nicht zwei Klassenbibliotheken lernen für das Drumherum.

Und GUI-Designer habe ich bisher höchstens für Prototypen eingesetzt.  
Natürlich kann man sich bei einfachen Anwendungen sein GUI auch direkt
in Squeak zusammenklicken. Das geht durchaus. Ich selbst muss mich  
allerdings erst an "live objects" gewöhnen :)

> Seaside ist mir auch schon untergekommen - die OneClick-Version  
> läuft bereits auf meinem Rechner. Und ich kann mir vorstellen,  
> einige wenige Anwendungen auch mit Seaside zu implementieren,  
> sofern die Objekte mit in Squeak auf dem Desktop geshared werden  
> können.

Mit Desktop meinst du jetzt den Squeak-Desktop, den Windows-Desktop  
oder gar den Desktop-PC? Gib mal ein Beispiel fürs Sharing. Ich kann  
grad nicht ganz folgen.

> Nur träume ich davon, ein weitestgehend von Servern unabhängiges  
> System zu bauen - quasi ein Croquet für das Büro. Schließlich haben  
> die meisten von uns ein kleines Rechenzentrum auf ihrem  
> Schreibtisch stehen, und warum sollte ich dann einen Flaschenhals  
> mit Servern produzieren. Genau aus dieser Ecke möchte ich ja heraus.

Hmm ... ob man Croquets Teatime ins normale Squeak bekommt, weiss ich  
nicht. Möglich, dass da sogar die VM angepasst werden muss. Da ist  
Andreas Raab sicherlich die kompetente Auskunftsperson hier.

Ich träume von einem verse-Client (www.uni-verse.org) in Croquet.  
Nächstes Jahr habe ich mehr Freizeit. Dann geh ich das an. Ist aber  
ne andere Geschichte.

Fürs erste würde ich dir empfehlen mit dem OneClick-Image  
rumzuspielen. Arbeite mal das Tutorial

http://www.swa.hpi.uni-potsdam.de/seaside/tutorial

durch. Zum Einstieg ist das ideal.

Bis dann
Enno

On Mon, 2007-11-19 at 10:52 +0100, Jürgen Beckmerhagen wrote:
> Hallo Enno,
>
> vielen Dank für die prompte Antwort und den Verweis auf CMSBOX.  
> Beeindruckend ...
>
> Im Moment interessiert mich besonders, ob ich bei Squeak mit meinen  
> Büro-Anwendungs-Ambitionen richtig aufgehoben bin, oder ob ich mich  
> eher in Richtung VisualWorks oder ähnlichem orientieren soll, weil es  
> dort vielleicht bessere GUI-Designer gibt - keine Ahnung.
Ich würde das Wort "Server" hier nicht zu ernst nehmen. Wenn du dir
vorstellst, dass jeder auf seinem Rechner ein squeak startet und mit
einem Webbrowser darauf zugreift, dann fühlt sich nicht an wie ein
Server. Oder stell dir vor, du klickst auf ein Icon und es wird ein
squeak image ohne Oberfläche gestartet und zusätzlich ein
Internet-Browser, der die Startseite deiner Applikation anzeigt.
Viel Unterschied gibt es dann nicht mehr zu einer "normalen" Anwendung,
oder?

Ich habe nicht besonders viel Ahnung von GUI-Designern, aber ich habe
noch nie was gesehen, was ich gut fand. Mit HTML bekommt man ja doch
immer etwas hin, was sich benutzen lässt. Mit neueren Technologien wie
Ajax kann man Funktionalitäten bauen, mitteld denen sich ein Webseite
eher anfühlt wie eine "richtige" Anwendung. Seaside hat sehr guten
Ajax Support.

Wenn du es mit seaside lösen würdest, dann wäre die Servervariante nicht
ausgeschlossen. Andere Benutzer könnten z.B. die Anwendung
auf deinem Rechner von ihrem Rechner aus benutzen. Das wäre schon ein
erster Schritt in Richtung "Croquet für Büroanwendungen". Du bräuchtest
dann nur noch einen Dienst, mittels dem sich die squeak/seaside
Anwendungen untereinander finden können. Es bleibt insgesamt etwas
flexibler. Der Nachteil ist sicher, dass komplexeres Verhalten auf
Webseiten schwieriger herzustellen ist. Aber eine richtige Expertise
hierfür habe ich nicht.

Soviel zu meiner Meinung. Ich hoffe es hilft.

Norbert

Am Monday, 19. November 2007 09:37 schrieb Jürgen Beckmerhagen: Gute Idee! Hast Du es schon fertig? Du könntest z.B. ein zweites Auto mit
explodiertem Airbag malen und dann mit den Kacheln "überlappt" und "trägt
Kostüm von" arbeiten.
... Das ist dann nicht so trivial....

Gruß
Esther

Esther, Norbert, Enno - vielen Dank für die zahlreichen und  
hilfreichen Anregungen.

Am liebsten würde ich mich sofort noch tiefer in Smalltalk und Squeak  
stürzen und in der dann noch verbleibenden Freizeit den Airbag in das  
Auto bauen.

Es ist ein Jammer, dass ich erst heute damit beginne, mich mit  
Smalltalk vertraut zu machen, die sich mir wesentlich leichter  
erschließt, als Java oder C++. Während ich in diesen Tagen den  
Klassiker aus 1988 von Bertrand Meyer "Objektorientierte Software-
Entwicklung" von Ende der 80er Jahre lese, frage ich mich, woran es  
wohl gelegen hat, dass ich vor 10 Jahren, als alle Welt auf Java und C
++ setzte, das aktive Programmieren aufgegeben hatte. Lag es an den  
Sprachen oder daran, wie sie angewandt wurden und werden?

Heute merke ich immer wieder, wie schwer es Entwicklern fällt, objekt-
orientiert zu denken und zu handeln. Funktionales und imperatives  
Denken entspricht wohl eher der Gedankenwelt eines Programmierers:  
"Tu dies. Mach jenes." Projektleiter erwarten von ihren Business-
Analysten "funktionale Dekomposition". Kaum einer fragt, mit welchen  
Objekten Benutzer umgehen. Der Gedanke, dass Anwender mit Skripten  
Objekte selber zu Anwendungen zusammenfügen, scheint den meisten  
Entwicklern unvorstellbar, mit der katastrophalen Folge, dass selbst  
bei kleinsten Änderungen ein Neuentwurf ihrer gerade erst vom Stapel  
gelassenen Systeme erforderlich wird.

Systeme zu bauen, die die Zusammenarbeit - Collaboration - fördern,  
halte ich für Wirtschaftsunternehmen gerade angesichts der  
fortschreitenden Globalisierung für unumgänglich. Ich möchte gerne  
meinen Anwendern in den USA und in Europa ermöglichen, sich gemeinsam  
mit dem CallCenter oder Fulfillment Center Agenten in Montevideo oder  
Delhi den Kundenstamm oder den Bestellvorgang anzuschauen - oder gar  
mit einem Direktkunden, der mein Internet-Portal besucht, gemeinsam  
den Warenkorb und die Angebote durchgehen.

Verteilte, sich selbst beschreibende Objekte, werden in diesem  
Zusammenhang von grundlegender Bedeutung sein. Ich kann nicht mehr  
erwarten, dass sich ein Anwender am anderen Ende der Welt mit meinem  
Anwendungsserver verbindet, um dann einen Vorgang oder eine  
Kundenakte von mir zu bearbeiten. Vielmehr sollte ich ihm das  
Vorgangs-Objekt oder das Kundenakte-Objekt zur Verfügung stellen,  
damit er diese Objekte auf seinem Endgerät (Desktop, ...) editieren  
oder dessen Funktionen direkt oder in eigenen Anwendungen / Skripten  
ausführten kann.

Kürzlich hatte ich mich bei einem Freund für den flüchtigen Hinweis  
auf Alan Kay bedankt: er ist tatsächlich der Schlüssel zu einem  
schier unendlichen Universum revolutionärer Ideen - genauso wie  
Kinder, sofern man sie genau beobachtet und Ihnen zuhört.

Jürgen.



Am 19.11.2007 um 21:39 schrieb Esther Mietzsch:

Jürgen Beckmerhagen schrieb:
...

Vielleicht eine Ergänzung noch über "mentale Modelle" und Paradigmenwechsel:

Smalltalk ist als OO Sprache erstaunlicherweise immer noch sehr modern.
Alan Kays OO - Idee, dahinter steckt ein mentales Modell, welches aus
der Not geboren wurde. Das kann man z.B. bemerken, wenn man z.B. Flash
2/3 programmiert (imperativ). Für jedes Objekt, welches sich in Flash
bewegen soll, muss man eine eigene Schleife vorsehen, welche die x oder
y - Koordinate verschiebt, damit sich das bewegt. Bei N Objekten muss
ich N Schleifen ineinander schachteln. Der Code muss sich also für den
Fall, dass sich die Zahl meiner Objekte verändert, dauernd mit
verändern, bzw. mit weiteren Fallunterscheidungen zwischen mehreren
Codes, die mit 2,3,4,5,6,7,.... gleichzeitig bewegten Objekten umgehen
können, umschalten. Alan Kay führte daher ein neues, mentales Modell
ein, indem er die Objekte miteinander kommunizieren lies und ein
Steuerobjekt an die vielen anderen Objekte nur noch
"Bewegungskommando's" absetzt, und jedes Objekt weiss dann selber, wie
es sich bewegen kann/soll/muss und CPU Zeitscheiben zugeordnet bekommt.
Shockwave z.B. folgt dann diesem Modell schon. Polymorphie, Vererbung
und Kapselung sind dann nur noch logische Konsequenzen aus diesem
Paradigmenwechsel.
Heutzutage liegen die Anforderungen noch einmal sehr viel höher. User
fügt nach eigenem Belieben weitere Objekte einem zentralen Serversystem
hinzu und dieses muss dann alles Aktionen des Users nochmals genau
mitverfolgen und ggf. Wechselwirkungen zwischen verschiedenen
User-Objekten beachten. Da hatte dann SUN die tolle Idee, Daten und Code
in Container zu verpacken, welche auf der Suche nach freier CPU-Zeit und
RAM durch das Netzwerk flitzen. Sie nannten es J2EE. Hat nur einen Haken
gehabt, wie die FISCUS GmbH nach verbrannten 1 Mrd.€ auch feststellte:
Für grosse Datenmengen eignet es sich nicht. Die GmbH mit Anspruch, ein
Steuersystem für alle Bundesländer zu programmieren, wurde eingestampft.
Problem war, dass die Informatiker die mentalen Modelle hinter den
einzelnen Framework - Konzepten eigentlich nicht verstanden hatten. Mein
Problem: Ihnen Ihren Unsinn vor Augen zu halten. Dafür wurde ich bezahlt.
Und nun kommt ein neues, mentales Modell. Organisationen sind
Entscheidungssysteme, worin viele Entscheidungen weitestgehend
automatisiert sind, also Wissensdatenbanken hinterlegt sind, aber
tatsächlich noch manueller Eingriff erforderlich ist. Wenn User XY seine
Dateneingabe/Bearbeitungsmaske offen hat, und einen Vorgang, Prozess
nicht weiter entscheiden kann, so muss er nach dem Subsidiaritätsprinzip
des Harzburger Modells seinen Kollegen oder Vorgesetzten, sich also die
Hierarchie hoch fragen. Heutzutage muss er dann das Büro verlassen,
seinen Vorgesetzten vor den Bildschirm holen, der dann Kraft seiner
Erfahrung, vor dem Hintergrund seines Wissens dann, entscheidet. Leider
können Teilprozesse immer noch nicht delegiert werden, sodass z.B. der
Vorgesetzte eine Queue hat, worin Vorgänge liegen, die von seinen
"Untergebenen" mangels Wissen nicht abgearbeitet/entschieden werden
konnten, sodass er kurz die Maske herübergereicht bekommt, ein paar
Felder weiter diese bearbeitet und wieder diesen Zustand (stateful)
zurückreicht. Das wird bisher über Mail dann alles geregelt. Mensch
kommt nicht weiter, schliesst die Maske, schickt seinem Vorgesetzten
eine Mail, erklärt, wo wie was warum er nicht weiterkam, nennt
Vorgangsnummer und das kostet rieeeesig viel Zeit. Warum? Weil
Informatiker sich zu wenig mit mentalen Modellen auskennen, sich zu
wenig mit Philosophie beschäftigt haben. Chief Architects haben zumeist
nicht nur Informatik, sondern auch viele Sprachen (auch dahinter stecken
mentale Modelle, insbesondere den fernöstlichen) und vor allem
Philosophie studiert. Mit Informatik, OO - Wissen kommt man heutzutage
nicht mehr weiter.
Neuer, alter Trend und damaliger Paradigmenwechsel: Funktionales
Programmieren mit Haskell, Erlang: Alles Prozesse werden so zersplittet,
dass sie sich weitestgehend unabhängig voneinander parallel ausführen
lassen, wobei funktionales Programmieren eine Besonderheit hat: Die
Reihenfolge der abgearbeiteten Teilaufgaben muss Kommuntativ sein,
sodass alle Teilprozesse, egal wann sie fertig werden in der
Queue/Tasks/Threads/Prozessen, zusammengefügt wieder dasselbe Ergebnis
liefern. Da kommt funktionales Programmieren eigentlich dem Wunsch nach
hochgradiger Skalierbarkeit, unabhängigen Prozessen und der Möglichkeit
alles Prozesse in Teilprozesse in einem Entscheidungssystem aufzuteilen,
und am Ende wieder zusammenzufügen, am allernächsten.
Daher sind diejenigen Programmiersprachen, welche "funktionales
Programmieren" (Lambda - Kalkül) erlauben, und Multiprocessing erlauben,
sehr in Mode. Ruby, Python ... können so etwas auch:
http://www.freenetpages.co.uk/hp/alan.gauld/german/tutfctnl.htm
Und dann gibt es noch weitere "Techniken", wie z.B. Hibernation, womit
aller lästige Code des hin - und her kopieren zwischen Datenbank und RAM
Puffer entfallen kann. Leider nur wollen viele Emotionslogiker nicht von
SQL ablassen, z.B. Caché von Intersystems oder Gemstone (auch der
PostgreSQL Kern ist OO) verwenden, weil sie einfach ein wenig aus
emotionalen Gründen am Gewohnten festhalten wollen. Ein wenig heisst
hier ewig. Und dann muss man als Softwarearchitekt mal ein Machtwort
sprechen, weil - ansonsten explodiert die Komplexität und Projekte
kosten locker das 10-fache des Etats.
Und dann gibt es noch Programmiersprachen mit Datenbanken, die sind rein
funktional, und mit denen kann man dann z.B. folgendes machen: Da
strömen jede Sekunde 1000 Daten in die Datenbank, irgendwelche
Transaktionen und die Programmiersprache ist in der Lage, quasi SQL -
Queries auf Datenströme anzuwenden, wobei dann das System locker 100.000
Queries/Sekunde packt, während weiter Daten einströmen und das noch 24/7
mit Hotbackup nebenher!
Die Software ist sogar kostenlos, Freeware. Sie wird bei allen Börsen
der Welt eingesetzt (Nein, nicht OCaml!)
"Prozessuales Denken" ist ein Denken in Verben ("Prozesstätigkeiten"),
nicht mehr Objekten. Das ist das neue Paradigma, was Programmierer in
den Kopf kriegen müssen, und was immer mehr gefordert ist.
ETOYS kommt dem von der Idee schon recht nahe, es ist ein "Prozessuales
Programmieren", wo man die OO-Hintergründe nur noch erahnen kann. Das
ist es, was Alan Kay mit seinem Ausspruch, dass die Software-Revolution
noch nicht begonnen hat, gemeint hat!

Mit freundlichen Grüssen, Guido Stepken

On Nov 20, 2007, at 8:56 , stepken wrote:

> ETOYS kommt dem von der Idee schon recht nahe, es ist ein  
> "Prozessuales Programmieren", wo man die OO-Hintergründe nur noch  
> erahnen kann. Das ist es, was Alan Kay mit seinem Ausspruch, dass  
> die Software-Revolution noch nicht begonnen hat, gemeint hat!

So habe ich ihn nicht verstanden - weder in seinem gleichnamigen  
Vortrag von 1997

http://video.google.com/videoplay?docid=-2950949730059754521

noch in seinem "Pisa"-Vortrag 2007

http://www.vpri.org/pdf/Pisa_RN_2007_007_a.pdf

Ihm geht es um wesentlich Größeres als Programmierparadigmen. Alan  
Kay geht es um wissenschaftlich-skeptisches Denken (im Gegensatz zu  
wissenschaftlichem Glauben, der derzeit an Schulen gelehrt wird) als  
Allgemeingut, wofür der Rechner als jederzeit verfügbares  
Simulationswerkzeug ein Mittel zum Zweck ist. Er sieht die "Computer-
Revolution" in einer Linie mit der "Buchdruck-Revolution", die nach  
200 Jahren einen gesellschaftlichen Umbruch ausgelöst hat. Den Anfang  
dieses Umbruchs kann man vielleicht in der Blog-Szene beobachten, das  
freie Internet ist eine wesentliche Säule dieser Revolution, aber die  
eigenliche "Computer-Literacy" (ich suche seit Jahren nach einer  
treffenden Übersetzung) steckt noch in den Kinderschuhen. Das OLPC-
Projekt ist ein Versuch, diese Entwicklung zu beschleunigen.

"Though the world today is far from peaceful, there are now examples  
of much larger groups of people living peacefully and prospering for  
many more generations than ever before in history. The enlightenment  
of some has led to communities of outlook, knowledge, wealth,  
commerce, and energy that help the less enlightened behave better. It  
is not at all a coincidence that the first part of this real  
revolution in society was powered by the printing press. The next  
revolutions in thought – such as whole systems thinking and planning  
leading to major new changes in outlook – will be powered by the real  
computer revolution – and it could come just in time to win over  
catastrophe." -- Alan Kay

- Bert -

Bernd und Guido, ich nehme nochmal das Ende unserer kurzen Diskussion
auf.

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.

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.

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.

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!

Ich hoffe, dass ich die dadurch ausgeloeste Revolution bzw. die
Eroberung der IT-Domaene durch die Anwender noch miterleben darf. Go -
Alan - Go.

Juergen Beckmerhagen



On Tue, 2007-11-20 at 14:38 +0100, Bert Freudenberg wrote:

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.

Nein, das ist *modular* nicht funktional. Und gerade objektorientierte
Systeme sind erstklassig in der Lage ein modulares Design umzusetzen.

Ciao,
   - Andreas

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.

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