[linux-l] Ocml vs. Java

Oliver Bandel oliver at first.in-berlin.de
Sa Sep 24 02:55:04 CEST 2005


On Fri, Sep 23, 2005 at 07:03:58PM +0200, Volker Grabsch wrote:
> On Fri, Sep 23, 2005 at 08:09:48AM +0200, Oliver Bandel wrote:
> > > > List.iter2 (fun a b -> print_endline (string_of_int(a + b))) liste1 liste2
> > 
> >                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > 
> > statt:             print_endline (string_of_int(a + b))
> > ginge es auch so:  Printf.printf "%d\n" (a + b)
> 
> Es geht darum, dass inline eine Funktion definiert wird, nämlich:
> 	(fun a b -> ...)
> 
> In Python brauchst du diese Ecke nicht zu denken, und hast stattdessen
> eine Schleife mit Inhalt, was IMHO schneller und leichter erfasst werden
> kann. Wenn das als Schleife dastehen würde, stünden Lister.iter2, liste1
> und liste2  zusammen, statt vom Inhalt unterbrochen zu werden. Wird der
> Schleifen-Inhalt sogar explzit in eine extra Funktion verpackt, ist das
> nur dann übersichtlicher, wenn der Schleifeninhalt nicht so kurz ist.
> 
> Ich geb mal ein Analogon in der deutschen Sprache: Wenn man den Code
> liest, ist es, als würde man einen Satz lesen. Die "Schleife" wird
> in Python zuerst genannt, und danach der inhalt. In Ocaml wird die
> Schleife wie durch einen Nebensatz unterbrochen:
> 
> 	Es werden nun zwei Listen durchlaufen, deren Elemente paarweise
> 	addiert und ausgegeben werden, bezogen auf die Listen "liste1"
> 	und "liste2".
> 
> In Python sieht das eher so aus:
> 
> 	Es werden die Listen "liste1" und "liste2" durchlaufen. Ihre
> 	Elemente werden paarweise addiert und ausgegeben.
> 
> Letzteres finde ich besser lesbar. Das spricht übrigens nicht
> grundsätzlich gegen funktionale Sprachen. In Ocaml z.B. würde man sehr
> viel Lesbarkeit gewinnen, wenn die Argumente einfach nur eine andere
> Reihenfolge hätten:
> 
> List.iter2 liste1 liste2 (fun a b -> print_endline (string_of_int(a + b)))
> 
> Mmmmhh ... schon viel besser. :-)


Und was, wenn die Funktion nicht an der Stgelle definiert wird?

Dann ist das Problm schon erschlagen.
Bei zu großen Funktiuonen soll man die sowieso besser extra definieren.


Aber die Reihenfolge der Argumente ist kein Argument gegen funktionale Sprachen,
sondern gegen eine gewählte Reihenfolge on Argumenten.

Du bist nicht der erste/einzige, der das bei OCaml kritisiert.

Aber eine perfekte Sprache gibt es eben nicht, und die Geschmäcker sind
obendrein auch noch verschieden.


 
[...]
> > > Man fängt nämlich an, Funktionen zu verweden an Stellen, wo eigentlich
> > > gar keine nötig sind. Egal, ob man sie nun inline definiert oder nicht,
> > > ist das unnötig schwer lesbar, IMHO.  In Python:
> > > 
> > > for a,b in zip(liste1,liste2):  print a+b
> >                                   ^^^^^^^^^^\
> >                                              \
> >                                  eine Funktion, wo garkeine nötig ist?
> 
> Da wird eine aufgerufen, nicht definiert. Hab ich ja oben nochmal
> erklärt.

Naja, man MUß doch nicht an der Stelle im OCaml-Code-Äquivalent eine
#Funktion definieren. Man ruft da üblicherweise eine Funktion auf.
Nur, wenn die Funktion einigermassen übersichtlich ist, sollte man das
überhaupt dort definieren.
Naja, manchmal wird die auch schon mal größer und größer... ;-)

 
[...]
> Meine erste funktionale Sprache war übrigens Common Lisp, damit habe

nicht schlecht.

Wollte ich mir auch mal noch rein ziehen, bin dann aber bei OCaml hängen geblieben.
Und wegen der Typprüfungs-Sachen finde ich es auch bei OCaml ganz angenehm. :)


Ciao,
   Oliver



Mehr Informationen über die Mailingliste linux-l