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.
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!
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
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:
-----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.
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!
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-----
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.
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.
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:
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.
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. ...
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.
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:
Am Monday, 19. November 2007 09:37 schrieb Jürgen Beckmerhagen:
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.
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. ...
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.
Das ist dann nicht so trivial....
Gruß Esther
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:
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 -
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
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:
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
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
squeak-ev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
Enno Schwass -
Esther Mietzsch -
Jürgen Beckmerhagen -
Norbert Hartl -
stepken