[linux-l] Ocml vs. Java

[Oliver Bandel]

On Sun, Sep 25, 2005 at 07:57:27PM +0200, Volker Grabsch wrote:
> On Sat, Sep 24, 2005 at 02:45:40AM +0200, Oliver Bandel wrote:
> > Es gibt nun mal Leute, die mögen lieber fertige Texte lesen, und andere
> > sind eher dialogisch geneigt.
> > Du scheinst derjenige der RTFM-Fraktion zu sein, ich bin eher dialogischer
> > Typ. Das kann dann manchmal nervn - beide Seiten. ;-)
> 
> Nee, da liegst du IMHO voll daneben. Ich bin definitiv ein Dialog-Typ.
> Das merkt man am Studium

Und wohl auch an unseren ausgeprägten Diskussionen. ;-)

Stimmt schon. Vermutlich treffen da zwei "Laberköppe" aufeinander. ;-)


> (gemeinschaftlich komme ich, auch wenn's um
> reines Lernen geht, wesentlich besser voran als allein),

komisch.
Lernen kann ich besser alleine. Aber irgendwie muß da (mittlerweile;
früher war das anders) ein Anreiz in Form eines Projektes ran, das
man gemainsam macht (oder eben ein bezahltes Job-Projekt, das treibt
natürlich auch an).
Wobei ich die Durchführung besser alleine mache, aber das Ergebnis
sollte für's Team/Projekt wichtg sein.


> und das merkt
> man an unserem Gespräch.

Ja, stimmt.


[...]
> > > ein ausgefeites
> > > dynamisches Typ- und Klassen-System auf der anderen Seite.
> > 
> > *räusper* (jedenfalls bzgl. Typsystems ;-))
> 
> Das typsystem in Python ist sehr weit entwickelt. Unter den dynamisch
> typisierten Sprachen ist Python IMHO wirklich ein Highlight.


Hmhhh..

...naja, bzgl. Aufgeräumtheit ist es wohl zumindest besser als Perl.
Habe zwar in python noch nichts gemacht, aber so weit ich mal kleineren
Beispielen und Erfahrungsberichten entnehmen kann, ist es doch sehr
sauber. Hatte die Muße aber dennoch nicht.

> 
> Wenn du also Ocaml mit einer dynamisch typisierten Sprache zwecks
> Sauberkeit / etc.  Vergleiche anstellen willst, vergleiche es bitte
> nicht mit Perl, sondern mit Python.

Naja, Python kenne ich zu wenig, um es heran zu holen als Vergleich.



> > > In Python
> > > kann man die verschiedenen Herangehensweisen wunderbar vergleichen
> > > und gegenüberstellen.
> > > 
> > > 
> > > Natürlich kann ich in Python sowas hier schreiben:
> > > 
> > > 	def mein_iterator(f,start):
> > > 		f(start + 1)
> > > 		f(start * 2)
> > > 		f(start / 3)
> > > 
> > > 	def innere_funktion(param):
> > > 		print param
> > > 
> > > 	mein_iterator(innere_funktion,10)
> > > 
> > > 
> > > liefert:
> > > 
> > > 	11
> > > 	20
> > > 	3
> > 
> > Sehr ungewöhnliche Syntax... aus meiner Sicht jedenfalls.
> > 
> > Ah, das ist noch nicht mal ein akkumuliertes Egbnsis?
> > Das hatte ich erst gedacht, als ichz es eben in Ocaml
> > kodieren wollte...
> 
> Nee, sorry, du hast am "falschen Ende" optimiert. Deine Vereinfachung
> ist aber korrekt, und in Python übrigens haargenauso möglich:


Am falschen Ende optimiert?

naja, ich hatte erst eine aufsummierende Funktion (das Ergebnis jeder
aufgerufenen Funktion wird als "start" wieder genommen, statt immer nur
start zu nehmen.
Aber das waren beides ja nicht so schlimme Unterschiede, war also flott
korrigiert. Als ich die falschen Ergebnisse heraus bekam, viel mir dann
auf, daß das ja ganz anders gemeint war...




> 
> > ======
> > # let liste = apply [
> >    (fun x -> x + 1);
> >    (fun x -> x * 2);
> >   (fun x -> x / 3) ]
> >   10 ;;
> > ======
> 
> 
> In Python:
> 
> 	def fun1(x): return x+1
> 	def fun2(x): return x*2
> 	def fun3(x): return x/3
> 
> 	[f(10) for f in (fun1,fun2,fun3)]
> 
> bzw. auch in einer Zeile mittels "lambda".

Na gu, wenn Du die Funktionen mit Namen benennst (hatte ich auch erst), dann wird es auch 
in OCaml im Aufruf kürzer.

statt "(fun x -> x + 1)" hätte ich dann let "plus_1 x = x + 1" oder so gemacht.

Ist aber erstaunlich, daß Python solche funktionalen Sachen so ohne weiteres schluckt!

Da bin ich doch sehr erstaunt!

Dagegen wird Perl dann doch blaß.


> 
> 
> > ======
> > # let stream = Stream.of_list liste;;
> > val stream : int Stream.t = <abstr>
> > # open Stream (* damit wir statt "Stream.next" auch "next" schreiben können *);;
> > # next stream;;
> > - : int = 11
> > # next stream;;
> > - : int = 20
> > # next stream;;
> > - : int = 3
> > # next stream;;
> > Exception: Stream.Failure.
> > # 
> > ======
> > 
> > Na, das ist doch zumindest Deinem sehr ähnlich?
> > Und auch nicht " all zu funktional", so daß Du keine großen
> > Syntax-Bauchschmerzen bekommst? ;-)
> 
> Interessant. BTW, ich bekomme von funktionaler Syntax keine
> Bauchschmerzen. Ich meinte nur, dass man, gerade bei einfachen
> Ausdrücken, die funktionalen Paradigmen nicht zu weit treiben
> sollte, weil for/if - Konstrukte IMHO besser lesbar sind. Ist
> sicher auch Geschmackssache.

Naja, ich finde das mittlerweile nicht mehr.
ich fand das früher auch.
Aber die funktionalen Sachen liegen mir mehr.

Aber wichtig bei funktionalen Sprachen ist natürlich nicht
nur Ihre Syntax, sondern auch einiges Anderes...
...so eben, daß beim Anweden funktionaler programmierung keine
Seiteneffete auftreten.

Auch die Sachen mit dem Scope sind super: es ist quasi jedes Konstrukt immmer
bestens unsichtbar/gekaüselt, da es nur in einem bestimmten Environment
existiert.

======================
first:~ oliver$ ocaml
        Objective Caml version 3.08.0

# let x= 3 
    in let y = 2
     in x * y;;
- : int = 6
# let x = 112;;
val x : int = 112
# let y = 56;;
val y : int = 56
# x * y;;
- : int = 6272
# let x= 3 
    in let y = 2
     in x * y;;
    - : int = 6
# x * y;;
- : int = 6272
# 
======================

Man muß nicht irgendwas mit "private" oder so deklarieren.

Das ganze geraffel, das in imperativen/obektorientierten Sprachen
dazu dient, das sog. "information hiding" zu ermöglichen, das bekommt
man bei funktionalen Sprachenquasi als Default dazu.

Warum soll man alles sichtbar lassen und dann hinterher mit zig
Worten syntaktischem Bloat das alles verbergen, was man nicht braucht,
statt wie bei den FPL's gleich alles nur in einem bestimmten
Environment sichtbar zu haben?!

Ich finde diesen Ansatz der FPLs wesentlich besser.

[...]
> Nur mal des Interesses halber: Wie würdest du folgendes Problem in Ocaml
> angehen? Du willst eine Funktion "list_file". Sie bekommt als Parameter
> eine Datei (genauer: irgendeinen Stream, den man zeilenweise durchlaufen
> kann), und liefert einen Iterator zurück. Diesen Iterator soll man
> "aufheben" können, d.h. der Iterator soll zwischendurch auch wirklich
> als einzelnes Objekt (bzw. Funktion) dastehen. Wenn man ihn später
> durchläuft, iteriert er alle Zeilen der Datei, entfernt das Newline und
> "trailing spaces", und setzt ein "XXX: " davor. Einzige Bedingung: Keine
> Listen! Das heißt, die Datei wird wirklich erst dann iteriert, wenn die
> zurückgegebene Iterator aufgerufen wird.

Was spricht denn gegen Listen?
Allein die Dateiegröße?

Bei so etwas würde ich möglicherweise klassisch imperativ heran gehen.
while-loop ;-)
Kann man natürlich auch mit ner rekursiven Funktion lösen.
Bei extrem großen Datenmengen muß die aber tail-recursive sein, sonst
haut's einem mit einer exception irgendwann weg.
Aussrdem kann's evtl. arsch-langsam werden, wenn rekursiv, aber nicht tail-rec,
und der Speicherbedarf wäre auch extrem.

Was spricht in dem Falle gegen klassisch imperatives vorgehen?

Wie soll gelesen werden?
Byte-per-Byte, oder Blockweise (wegen Unix-read(2) und Blocksize usw.)?
Ist das geschwindigkeitskritisch?

Können lexer-Libs genutzt werden?
(denke da an lex/ocamllex, denn das Überlsen von Sachen wie Space
und \n kann man da ganz simpel mit erledigen.
Kann man aber auch nen eigenen lexer implementieren, ist ja auch
recht einfach.
Dann würde ich es in OCaml vermutlich mit zwei sich gegenseitig aufrufenden
rekursiven Funktionen machen. Die eine überliest space und \n und die
andere liest so lange ein, wie diese nicht auftauchen.
Die beiden rufen sich dann immer gegensitig auf und packen die Daten in eine Liste,
sofern gewollt, oder machen halt was anderes damit, wenn keine Liste aufgebaut werden soll.



> Wir können nämlich auch sehr
> große Dateien haben, die auf keinen Fall zwischendurch komplett in den
> RAM geladen werden dürfen.

Ist das bei Dir auf Arbeit wichtig?
Oder wer sind "Wir"?


> 
> Das heißt, wir nehmen eine Datei "test.txt":
> 
> Zeile1      
> Zeile2      
> Letzte Zeile
> 
> Und folgenden Python-Code:
> 
> 	f = open("test.txt")
> 	iter = list_file(f)
> 
> 	for x in iter: print x
> 
> 	close(f)
> 
> 
> Dies sollte zurückliefern:
> 
> XXX: Zeile1
> XXX: Zeile2
> XXX: Letzte Zeile
> 
> In Python würde list_file so aussehen:
> 
> 	def list_file(f):
> 	    return ("XXX: "+line.rstrip() for line in f)
> 
> 
> andere Variante:
> 
> 	def list_file(f):
> 
> 	    for line in f:
> 	        yield "XXX: "+line.rstrip()

Das ist wirklich recht wenig Code.
Wie sieht es denn da mit Abfragen von
Problemfällen aus?

Wenn ich den Code schreiben würde, wäre er sicherlich
ausgestatet mit Abfragen, die Exceptions (File nicht vorhanden
oder nicht zu lesen, etc.) auswerten würden.

Ich weiß nicht, wie das in python gehandhabt wird.
Aber auch in Beispielen dieser Art würde ich das zumindest
irgendwie erwähnen, ober am besten auch handeln.
Insofern wäre der OCaml-Code etwas aufwändiger.

Aber ist doch erstaunlich wenig Code da oben...


Wenn Du wirklich ein Beispiel haben willst, sach noch mal bescheid.
heute ist's schon wieder zu spät geworden. :(
Mails beantworten dauert auch immer ewig. Wenn ich dann jetzt noch
das programmieren anfange... :(


Es gibt da viele Wege, die man nutzen könnte.
Byteweise lesen, oder Zweilenweise.
Byty-per-Byte => selber scannen und space und \n weg schmeissen usw.
dann braucht man hinterher keine regexps oder sowas.
Zeilenweise einlesen, dann entweder regexüs, oder einfach den String
selbst secannen (wenn es echt nur space am anfang ist, das weg soll,
ist ja regexp schon overhead).

Naja...
...kommt immer drauf an, was da wirklich an Voraussetzungen gegeben ist...

..aber lex/ocamllex macht sich auch ganz locker mit sowas. :)




[...]
> > Oder sind Iteratoren zwingend festgelegt auf Integers?
> 
> Nein, keineswegs! In Python können Iteratoren selbstverständlich alles
> mögliche durchlaufen. Auch Objekte von unterschiedlichem Typ.

Aha, feine Sache. :)


> 
> > > Beim funktionalen Ansatz hingegen muss man mit den Iteratoren wie mit
> > > verschachtelten Funktionen umgehen, und sie ständig auf diese Weise
> > > im Hirn halten.
> > 
> > Wie findets Du den Ansatz da oben?
> 
> Wiegesagt, du hast das falsche optimiert. Dein Ansatz geht in Python
> genauso. War einfach ein blödes Beispiel von mir.

Falsch optimiert?
Das beispiel, das ich gebracht habe, hatte doch genau gepasst.
Den Code, der das Ergebnis akkumuliert und jeweils als neues
"start" rein wirft, den habe ich dochhier garnicht eingebracht.



> 
> 
> > Btw: Die Sache mit den Verschachtelungen sehe ich noch ein bischen
> > anders. Man kann sich auch Funktionen als composites erstellen.
> > In Haskell gibt es dafür sogar einen eigenen Operator (".").
> > Den gibt's in OCaml leider nicht. Aber dann baut man sich eben eine
> > entsprechende Kompositions-Funktion zusammen.
> > Muß man nur einmal machen und hat dann seine Ruhe. ;-)
> 
> Das erinnert mich an etwas: In Python gibt es sehr viele Sprache-Features,
> die gar nicht im Compiler gelöst werden, sondern direkt in Python, dank
> einiger mächtiger Meta-Features. 

Wieso unterscheidest Du Python und den Compiler?

verstehe ich da etwas grundlegendes von python noch nicht?


> Zum Beispiel kann man mit "Metaclasses"
> in Python ne Menge anstellen.

Hmhhh, nun schaute ich eben mal in der OCaml-Doku zum OO-zeugs nach,
um zu schauen, was es da in OCaml dazu viell. gibt.

Naja, dann stolpere ich über Polymorphic Methods und daß man die
nutzen kan, um Iteratoren zu definieren...

...hmhhhh... wat'n Zufall. ;-)

...aber danach hatte ich ja garnicht gesucht. ;-)




> Sie sind für Anfänger schwer zu verstehen,
> dennoch vom Konzept her so einfach wie nur denkbar, wenn man sich
> ansieht, was man damit realisieren kann. Einzelheiten würden jetzt aber
> wirklich zu weit führen.

OK, mußt ja nicht das ganze Zeugs hier ablassen, aber mal gefragt:
Wozu sinde die gut, was kann man damit machen?
Welchen Effekt haben die?



> 
> 
> > Naja...  OCaml ist eben keine purely functional language.
> > Sie bietet eben mehrer Möglichkeiten an; und genau deswegen
> > hat sie bei mir bessere Karten als Haskell.
> > 
> > Haskell ist zwar edler, aber eben auch dogmatisch.
> 
> Mag sein, aber dort gibt's Listcomprehensions, da sind sie von den
> Dogmen etwas abgegangen zugunsten von "Usability". Finde ich gut, sowas.


Wieso Dogmen?
Funktionale Programmierung heisst nicht, daß man eine bestimmte Syntax
nimmt.
Bei der funktionalen programmierung geht es doch darum, daß

- Funktionen wie normale Values behandelt werden
- keine Nebeneffekte genutzt werden
- und weiteres

Aber die Syntax alleine macht eine Sprache noch nicht zu einer funktionalen
Sprache.

Also macht eine Syntax mit Listcomprehensions aus einer funkt. Sprache nicht eine
nicht-funktionale nur wegen der Syntax.

Also ist da auch kein Dogma gebraochen, wenn eine FPL Listcomprehensions hat.
Welches Dogma meinst Du denn?



> 
> > [...]
> > > Nun die funktionale Variante mit map/filter:
> > > 
> > > 	map(ausgabe,filter(kleiner10,map(durch2,filter(gerade,liste))))
> > Naja, ob man das so wirklich machenwollen würde?
> > 
> > Zumindest in Haskell kann man aber Funktionskomposition
> > mit dem "."-Oprator machen.
> > Dann notiert man das wie eine Pipe(line).
> > Von rückwärts allerdings, aber immerhin ohne Klamerungs-Arien.
> 
> Cool. Nette Sache.

Eben.

Aber: Ich dachte Du hast mit Haskell schon mal herum gewerkelt...
Den Operator kanntest Du nicht?!





> 
> > > Und das sage ich nicht, weil ich keine
> > > funktionalen Konzepte kenne oder nicht intensiv damit gearbeitet hätte,
> > > sondern einfach als pragmatischer Python-Programmierer, der beide
> > > Varianten zur Auswahl hat und schaut, was besser lesbar ist.
> > 
> > haskell kennt auch List-Comprehensions. Und?
> > Das ist deswegen nicht nicht-funktional.
> 
> Nein, aber es weicht IMHO vom funktionalen Dogma ab.

Wieos denn das?

Finde ich überhaupt nicht.

Im Gegenteil: Hakell ist pourely functional, und daher eher sehr dogmatisch.


> Eigentlich könnte
> man ja alles über zwei Funktionen "map" und "filter" machen, wozu also
> Listcomprehensions? Weil sie sehr gut lesbar sind. :-)

Klar.

Und?

Du unterstellst da ein Dogma, das so nicht existiert.

Oder wenn es doch existiert, dann nur bei Dir! ;-)



[...]
> > > Funktionale Elemente werden damit nicht komplett aus Python verbannt.
> > 
> > Du redest nur über die Syntax der Sprachen, aber was hat das mit
> > funktional/nicht-funktional zu tun?
> > doch erst mal nixhts ausser, daß Spracheigenschaften und Syntax vielleicht
> > oftmals zusammen auftreten.
> 
> Ich wollte damit nur sagen, dass Python von diesem Dogma abgewichen ist.
> "Funktionale Elemente" war als Bezeichnung wohl ziemlich schlecht.

Nur ist mir nicht klar, welches Dogma Du meinst!


> 
> 
> > > Ich finde sie besser lesbar.
> > 
> > Naja, in manchen Fällen sind die auch sinnvoller, weil sie
> > das problem besser darzustellen vermögen.
> > Aber in den meisten Fällen habe ich gemerkt, daß die
> > funktionale Programmierung am besten passt.
> > Nicht für alles, aber sehr vieles.
> 
> In meinen Applikationen bin ich mit OO Programmiererung gut gefahren.

glaube ich gerne.


> Aber wird haben offenbar auch recht unterschiedliche Typen von
> Programmen, die wir schreiben.

möglicherweise ... bisher. ;-)


> Wenn ich z.B. für's Wikidok-Projekt etwas
> schreibe, werden wohl viel weniger Klassen drin vorkommen.  :-)

Wikidok-Projekt klingt für mich irgdnwie nach FPLs... ;-)


[...]
> > Map und Filter sind wunderbare Funktionen.
> > 
> > Wenn diese im Kontext der Sprache Python nur auf so seltsame Weise eingesetzt
> > werden, oder wenn Du sie nur auf so seltsame Weise einsetzt, dann ist das
> > schon seltsam.
> 
> Ich setze sie ja nicht so ein.  :-)

ach so, ja. ;-)



[...]
> Selbst wenn die Funktion also solche schon vorhanden ist
> ("filter_func"), würde das vielleicht anders aussehen. Da wäre da
> hier eher schlechter lesbar
> 
> 	(x for x in liste if filter_func(x))
> 
> ... als das hier:
> 
> 	filter(liste,filter_func)
> 
> Dennoch liefert ersteres einen Iterator zurück, während zweiteres
> Speicher verschwendet und eine Liste aufbaut. Aber egal, in Python
> gibt's sicher auch einen "filter", der einen Iterator und keine Liste
> erzeugt.

Was hast Du eigentlich für ein problem, eine Liste aufzubauen?
Ich mache das ganz gerne, daß ich mir immer erst mal alles in den RAM
lese, Datenstrukturen aufbaue und dann damit arbeite.
Das hat nämlich den Vorteil, daß man die Datenstrukturen auch mehrfach nutzen
kann und nicht immer wieder die Datei neu einlesen.

Und bei Programmänderunegn ist man auch flexibler.
Und wenn man die Daten übers netz liest, dann kann man cuh nicht
noch mal neu einlesen, so wie bei einer Datei.

Grundsätzlich ist es IMHO das sinnvollste, immer erst Datenstrukturen
aufzubauen und dann damit zu arbeiten.

Natürlich gibt es Ausnahmen, aber das muß man sich dann gesondert anschauen.



> 
> > Wenn ich aber mit map/filter ALLES, was ich irgendwie programmieren kann,
> > darstellen will, dann wird das natürlich nicht funktionieren.
> 
> Doch, das schon. Aber es ist unlesbar. :-)

;-)


> Ein herrliches Beispiel dafür, was bei zu viel Dogmatismus passieren
> kann.

Naja.



> 
> 
> > > Wenn OO mir dir Arbeit erleichtert und meinen Code besser lesbar macht,
> > > dann nehme ich das. Dabei greife ich gelegentlich auf funktionale
> > > Elemente zurück, wenn ich z.B. einfach nur ne Funktion und nicht ein
> > > ganzes Objekt übergeben will.
> > 
> > Wenn es auch mit Modulen geht: keine Speicher-/Laufzeit-Ressourcen,
> > die man verballert. Alles wird schön brav kompiliert und zur Laufzeit
> > muß nix extra generiert werden.
> 
> Das ist natürlich ein genereller Vorteil von statisch typisierten
> Sprachen: 
> 
> Wenn du Objekte hast, also Daten-Anteile, auf die du verschiedene
> Operationen anwenden willst, dann haben Funktionen, die diese Daten als
> Parameter bekommen, natürlich erstmal mehr Performance als Klassen.

Jau.

> Aber sobald du Polymorphie brauchst, hast du sowieso einen gewissen
> Overhead,

Nö, bei FPLs nicht.
Da ist die Polymorphie schon gleich mit als Bonus dabei.
Ist halt ne andere Art von Polymorphie; da geht es um Typen,
nicht um Methoden-Aufrufe.


> den du in diesem Fall aber gerne in Kauf nimmst, weil er
> mikrig ist im Vergleich zur Alternative. Ein kleines dummes Beispiel:


Naja, das beispiel ist immer so ein typisches.
Ob man in dem Falle OO anwenden sollte... hmhhh.
Kann man schon machen, bzw. wird oft gemacht.
Aber FP-Ansatz mag ggf. auch passen.

Könnte man sich echt mal nen Kopp zu machen... ;-)


[...]
> 	    def draw(self):
> 	        print "Rechteck der Form", self.breite, "x", self.hoehe
> 
> 
> 	liste = [Kreis(1),Rechteck(2,3),Kreis(4)]

Das schluckt Python einfach so?
Ohne am Typ zu meckern?
Du fütterst die Liste doch mit ganz verschiedenen Sachen!


> 
> 	for obj in liste:
> 	    obj.draw()
> 
> 
> Es kommt heraus:
> 
> 	Kreis mit Radius 1
> 	Rechteck der Form 2 x 3
> 	Kreis mit Radius 4
> 
> 
> Von mir aus gib Rechteck und Kreis noch eine gemeinsame Basisklasse,
> welche die Methode "draw()" vorschreibt. In Python ist das nicht
> notwendig, hauptsache die Objekte haben die Methode. Klassenhierarchien
> und Vererbung gibt's in Python natürlich trotzdem.
> 
> Der "OO-Overhead" ist minimal im Vergleich zur Alternative, nämlich
> eine Monster-Draw-Funktion zu haben.

Warum Monster-draw-Funktion?

Man kann das bestimmt auch ohne OO hin bekommen und ohne
Monster-draw-Funktionen.
Wieso Monster?

Vermutlich lässt sich sowas auch gut via Module nutzen.

Aber viell. ist OO in dem Falle auch OK.

Weiß nicht.

Aber wo wir das Thema Bridge gerade erst hatten... ;-)

Kommt halt letztlich drauf an, was da gemacht werden soll.



[...]
> Es kommt also immer darauf an, ob du wirklich Klassen brauchst oder
> nicht.
> 
> > [...]
> > > Zum Beispiel ist das meiste, was du hier gemacht hast, in OO genauso
> > > möglich, wenn man den Begriff "Modul" gegen "Klasse" und den Begriff
> > > "Funktion" gegen "Methode" austauscht. Wieso du da so einen himmelweiten
> > > Unterschied reindichtest, weiß ich nicht. In Python stehen mir alle
> > > Möglichkeiten offen, und ich nutze die, die mir helfen.
> > 
> > OO: Laufzeit-Overhead.
> 
> Nicht unbedingt. Wenn man es missbraucht, dann schon. Aber wenn man es
> wirklich mit Klassen zu tun hat, sollte man sie in der Programmiersprache
> auch als Klassen programmieren können.

Was meinst Du damit?
Du meinst, wenn man die Sachlage, die man im Rechner abbildet auch
in der Real-World OO-like gut beschrieben wrden können?
Wenn also OO eine brauchbare Hrangehensweise darstellen?


[...]
> Hat man natürlich nur-Daten-Objekte
> oder nur-Funktionen-Objekte, sieht das etwas anders aus. Deiner
> Pauschalisierung muss ich also entschieden widersprechen.

Das war keine Pauschalisierung.
Das war  gemeint in dem Sinne, daß OO dann unnötig Overhead einbringt, wenn
es das falsche Modell ist.

(Oft wird das auch so gemacht, weil OO ja meist auch dogmatisch eingesetzt wird...)




> 
> > > Also, was mich angeht, würde ich natürlich Ocaml lernen wollen, also
> > > wenn ich z.B. dein Labanscale-Projekt unterstützen sollte, würde ich
> > > natürlich deine Wahl (Ocaml) voll und ganz akzeptieren.
> > 
> > Aha, würde Dich das Teil also interessieren? :)
> > hmhhh...
> 
> Natürlich! So sind wir doch ins Gespräch gekommen. Mich hat Ocaml
> interessiert, also habe ich ein paar Fragen gestellt. Und mich
> interessiert dein Laban-Projekt, deshalb habe ich mitgedacht, Fragen
> gestellt, und Vorschläge gebracht.

OK, das habe ich nun vernommen. :)

Kann man für sowas nicht irgendwo Forschungsgelder benatragen? ;-)



Gruß,
   Oliver