[linux-l] Re: Adaptor-Pattern mit Ocaml's Module System

[Volker Grabsch]

On Sat, Sep 24, 2005 at 10:48:58AM +0200, Oliver Bandel wrote:
> On Fri, Sep 23, 2005 at 03:52:14PM +0200, Volker Grabsch wrote:
> > On Fri, Sep 23, 2005 at 08:26:01AM +0200, Oliver Bandel wrote:
> [...]
> > Du findest diese Muster überall, und deshalb verstehe ich nicht, wieso
> > du sie als antiquiert bezeichnest. Du hast doch genau dieses Muster
> > auch bei Ocaml angewendet.
> 
> 
> Dieses Muster war ja auch Vorgabe!
> 
> Vorgabe: "Implementiren sie dieses Muster M nicht mit X sondern mit Y."
> 
> Vorher:  M mit X implementiert
> Nachher: M mit Y implementiert.

Nee, Vorgabe: "Problem A". Im Buch über "Muster X" gelöst, meistens in
den Varianten "Muster X-A" (für C++) und "Muster X-B" (für Smalltalk).

Wenn du behauptest, ein Muster wird von der Sprache erschlagen, dann
gehe ich nicht nur davon aus, dass du "Muster X" auch in dieser Sprache
bauen kannst. Wenn du "Muster X" in diese Sprache leichter bauen kannst
als es im Buch steht, dann ist es damit noch nicht erschlagen, sondern
du hast einfach ne schönere Sprache. (Deine Sachen waren auch nicht
einfacher, als es in Python oder Ruby gewesen wäre)

> Das sagt aber nichts darüber aus, ob die GESAMT-Herangewensweise auch in dieser
> Weise sinnvoll ist.

Wenn du sagst, das Muster wird "erschlagen", dann erwarte ich, dass das
Problem irgendwie "direkter" oder "besser" gelöst wird, als über Muster X.
Und das war bei keinem der Beispiele der Fall, und ist allgemein auch
nicht zu erwarten.

Wenn ich deine schwäre Version von "erschlagen" nehme, dann kann ich
genauso sagen, dass die Design-Patterns von Python und Ruby ebenfalls
komplett erschlagen werden.

> Der Untertitel des Buches "Design Patterns" heisst:
> "Elements of Reusable Object-Oriented Software".
> 
> Da steht also: Wir haben ein Problem, ads während der OO-Implementierung
> auftauchte und dieses Problem soll gelöst werden.
> 
> Da steht nicht: Wir haben ein problem und schauen mal, ob wir es mit OO
> oder anders lösen.

Die Probleme dort sind aber solcher Natur, dass für sie ohnehin der
OO-Ansatz erstmal der beste ist. Na gut, die meisten.

Ein Buch, das sich auf Probleme konzentriert, die sich funktional besser
lösen lassen, wäre natürlich auch wünschenswert.

> Die Notwendigkeit für bestimmte Patterns tauchen abhängig davon auf, ob
> das Problem via OO, imperativ oder funktional gelöst wird.

Achso? Bei deinen bisherigen Beispielen war das aber nicht der Fall.
Du hast mir bisher kein Beispiel aus dem Buch genannt, bei dem du einen
völlig anderen Ansatz genommen hast, um das Problem zu lösen, der
einfacher und überhaupt besser ist als der Lösungsvorschlag im Buch.

Bei "Interpreter", "Besucher" und "Vermittler" könnte man meiner Meinung
nach was derartiges finden. Die anderen Probleme sind sehr an sich schon
ziemlich objekt-gebunden. Aber ich will dich nicht entmutigen. Es würde
mich sehr interessieren, wenn du mir da was nennen könntest. Vorallem
würde es mir mehr bringen, als ein weiteres OO-Muster von dir in OCaml
implementiert zu sehen. ;-)

> Wenn man dann eine Problemlösung heraus greift und diese dann mit
> Moduln statt OO löst (was zumindest schon mal Laufzeitoverhead
> weg nimmt), dann ist aber dieses Pattern schon die Vorgabe.

Die Moduln in OCaml sind den Klassen von OO-Sprachen konzeptuell
verdammt ähnlich. Ich würde sie eher den OO-Konzepten als den
funktionalen Konzepten zuordnen. Das diskutieren wir aber schon an
anderer Stelle.

> Was ich eigentlich kritisiere ist ja, daß im Allgemeinen, wenn man sich mal
> umschaut, immer auf OO fixiert geschaut wird, daß man die Probleme
> löst.

Konkret bei dem Buch sehe ich darin keinen Kritikpunkt, weil die
Probleme auch ziemlich OO-typisch sind, lasse mich aber gern eines
besseren belehren.

> DAS ist es, was ich eigentlich als antiquiert ansehe: Die funktionalen Sprachen
> sind in den letzten Jahren aus ihrer verschlafenen Zeit heraus und langsamen
> Code produzieren sie auch nicht mehr. (Oder anders gesagt: einige sind recht flott.)

Das ist korrekt. 

> Daß man immernoch mit irgendwelchen OO-problemen und Patterns um sich wirft, die bei einem
> anderen Ansatz viell. garnich in dieser Weise aufgetaucht wären, DAS ist es, was ich
> beknackt finde.

Full ACK.

Bei mir habe ich konkret das Problem nicht bei OO allgemein, sondern bei J2EE.
Vorallem die J2EE-Patterns sind meines erachtens nach genau das, was du
am GoF-Buch beschimpft hast: Man löst Probleme, die man mit einem
anderen Ansatz erst gar nicht hätte. Es sind überwiegend Workarounds für
Designfehler in den EJB-Sachen.

Genauso habe ich auch nichts gegen SOA. Die Idee ist gut, dass man auf
irgendeinem anderen Rechner "Services" hat, die man eben aufruft. Aber
dass das unbedingt über "Funktionen-Syntax" gehen muss bzw. über nach
nachbilden von "Objekten", die remote agieren, das halte ich für völlig
ungeeignet. Funktionen und Objekte sind nur bedingt sinnvoll "remote"
zu gestalten. Manchmal ist selbst simples HTTP eine bessere Idee! (so
einen Ansatz nennt man auch "REST")

Ich bin stattdessen dafür, sein gesamtes System erstmal besser
serialisierbar zu designen. Aber auch hierzu arbeite ich an Sachen, die
leider noch nicht vorzeigbar sind, und sich noch schnell ändern.
Manchmal verwerfe ich eine Idee, wenn gerade dabei bin, sie zu
implementieren. Manchmal spare ich mir auch die Zeit und verwerfe sie
vorher. ;-)

> Da brauchst Du Dich dann ja wohl NICHT angesprochen fühlen, denn Du scheinst ja,
> wenn ich das nun richtig sehe, nicht grundsätzlich gegen funktionale
> Programmierung zu sein.
> Aber wenn ich mich mal auf dem Programmiermarkt (Industrie z.B.) umschaue,
> dann habe ich da noch nichts von non-OO gelesen.
> Es gibt zwar schon die eine oder andere Firma, die einen Erstkontakt zu z.B. OCaml hatte.
> Aber das ist noch rar.

Das ist wirklich schade, und ein allgemeines Phänomen, das noch viel
weiter geht. Schau dir z.B. die vielen Rants gegen J2EE an.

Übrigens ein sehr interessanter Artikel zum Thema "Paradigmen-Hype", der
sich auch dem OO-Hype widmet.

	http://www.tundraware.com/Technology/Bullet/


> Ausserdem sollte man auch mal gut heissen, wenn Leute aus Ihrer Erfahrung
> heraus sagen, daß eine Programmierung mit funktionalen Features extrem
> leistungsfähig ist.

Ja, aber um in den Worten des obigen Artikel zu sprechen:
Mach aus "funktional" nicht bloß ein weiteres Bullet.

> aber es ist antiquiert, alles
> nur durch die OO-Brille zu sehen.

Das ist nicht nur antiquiert, sondern war auch noch nie sinnvoll.

> Wenn man nur EINE Lösungsweise nutzt, also nur ein Programmierparadigma anwendet,
> kommt man an gewissen Punkten nicht weiter. Das ist nicht nur dogmatisch, sondern
> wird auch Bloatware.

Genau den Eindruck hattest du anfangs aber auf mich gemacht, muss ich
zugeben. Nur eben nicht in Bezug auf OO, sondern auf funktionale
Programmierung.

> Deswegen sind Programmiersprachen wie OCaml so sinnvoll: man hat viele Möglichkeiten
> zur Auswahl und kann die geeignete auswählen!

Meine Rede! Dito für Ruby, Python und sicher noch viele andere Sprachen.

> Das setzt aber voraus, daß man seinen Blick aufweitet und nicht bei pur-OO
> und OO-Design-Patterns bleibt.

Nein, aber das heißt, dass man OO nur zusammen mit den OO-Patterns
wirklich bewerten kann.

> Aber IMHO sollte man dynamische Sprachen nur dann anwenden, wenn man
> genau diese Features auch braucht. Weil einem sonst unnötig die
> statischen-/compilierzeit- Checks verloren gehen, die einem
> enorm helfen, Fehler im Vorfeld auszumerzen.

Das ist wahr. Und Ocaml ist auf jeden Fall interessant für mich. Was für
Python spricht, ist, dass es sehr viel einfacher und sauberer ist als
alle anderen "dynamischen" Sprachen, die ich kenne. Unter diesen
Sprachen hilft mir Python ganz besonders auch bei der Fehlervorbeugung.

Im Vergleich zu den "statischen" Sprachen, die ich kenne, ist Python
ebenfalls besser geeignet für meine aktuellen Projekte. Sicher könnte
ich sie nachträglich z.B. in Java reimplementieren, aber wirklich
sicherer würden sie dadurch auch nicht werden, IMHO. In Java z.B.,
wo ich was relativ großes gemacht habe, habe ich sehr viel Zeit mit
Wiederholen von Typen, und umständlichem Anwenden von Muster (z.B.
Decorator) verbracht. Das provoziert Fehler nur unnötig. Weiterhin
hat mich der Compiler die meiste Zeit auf fehlende Casts oder ein
fehlendes Semikolon aufmerksam gemacht, ohne dass ich dadurch jemals
ein "tieferes" Problem entdeckt hätte. In Python brauche ich kein
Semikolon zu tippen und keine Casts.  ;-)

Was jedoch Ocaml angeht, das könnte sich dort als Ausnahme erweisen.
Statische Typisierung, viel Wert auf Stabilität und Sicherheit, und
trotzdem kein Boilerplate. Nicht übel. Dieses Abschaffen von Boilerplate
war bisher das, was ich an Ruby und Python besonders mag. Für
System-Software von Autos und Waschmaschinen, aber auch für nen Kernel
bzw. Netzwerk-Daemons ist das sicher besser geeignet als C (*g*) oder
Java, und auch besser als Python, das gebe ich zu.


Viele Grüße,

	Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR