FP/Java vs. OCaml (Re: [linux-l] Ocml vs. Java)

[Oliver Bandel]

Moin Ivan,

kleine Fortsetzung zum Thema, das auch zum Thread passt.
Also mal Java vs. Ocaml.


On Wed, Sep 21, 2005 at 04:51:57PM +0200, Ivan Villanueva wrote:
> Hi Oliver,
> 
> On Tue, Sep 20, 2005 at 06:23:57PM +0200, Oliver Bandel wrote:
> > > >  - funktional
> > > Java auch mit Interfaces (ohne pointers) aber sehr "verbose"
> > 
> > Na, das wage ich doch sehr zu bezweifeln, daß Java funktionale Programmierung ermöglicht.
> > [Beispiel in Ocaml]
> Danke für das Beispiel. Sehr schön, wenn man ein 200 Zeile Programm schnell
> hacken will.
> Java finde ich gut für große Projekte. Funktionale Programmierung gehts auch
> wenn man mehr schreibt: Beispiel:
> 
> interface Func { int operation(int i1, int i2) ; }
> class Sum implements Func { int operation(int i1, int i2) { return i1 + i2 ; }
> class Pro implements Func { int operation(int i1, int i2) { return i1 * i2 ; }
> 
> Jetzt kannst Du mit Sums und Pros machen was Du willst.
> 
> > Kannst Du in Java Funktionen als Argumente und als Rückgabewerte haben?
> 
> Object example(Func f, int a, int b) {
>     if ((f instanceof Sum) && (a ==b)) return new Pro() ;
>     return f.operation(a,b) ;
> }
[...]


OK.

Man kann mit OO das Übergeben von Funktionalität bauen und damit FP
nachbilden.
Es ist aber nicht das selbe.
Du übergibst Objekte mit einer bestimmten Funktionalität, nicht die
Methoden/Funktionen selbst.

Und bisher ging es in den ganzen Diskussionen viel zu sehr um syntaktisches.

Eine ganz wesentliche Sache bei funktionaler Programmierung ist aber,
daß sie ohne Nebeneffekte/Seiteneffekte arbeitet.

Obwohl in imperativen Sprachen immer mit Nebeneffekten gearbeitet
wird, hört man doch immer wieder die Warnung, man solle doch
globale Variablen so selten wie möglich einsetzen.
Globale Variablen: Veränderbar von allen Teilen des Programms,
und daher sind Fehler so schwer lokalisierbar, wenn doch mal
irgendwo dieser Zugriff unkorrekt erfolgte.
Globale Variablen sind der Inbegriff der Seiteneffekte.

Aber das Problem liegt tiefer. Auch nicht-globale Variablen,
die aber von mehreren Stellen aus zugänglich sind, können probleme bereiten.
Auch Probleme bereiten Funktionsaufrufe, die nach jedem Aufruf andere
Ergebnisse liefern.

In purer funktionaler Programmierung gibt eine Funktion IMMER den selben Wert zurück.
Deshalb kann man auch voraussehen, was passieren wird.
Jede Value hat immer den selben Wert. Man kann sie nicht verändern.
Man kann nur ein neues Environment schaffen, in dem man an den selben Namen
eine neue Value bindet, aber die alte bleibt bestehen.
Das war das Beispiel, das ich gestern anbrachte mit der Multiplikation
zweier Variablen mit dem let-Konstrukt.

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

# let x = 4 and y = 20;;
val x : int = 4
val y : int = 20
# x * 4;;
- : int = 16
# let x = 55 and y = 2000
    in x * y;;
- : int = 110000
# x * y;;
- : int = 80
# 
============================================================

Ausserdem bietet pure funktionale Programmierung die Möglichkeit (aus dem eben genannten
Grunde), die Korrektheit von Programmen mithilfe mathematischer Methoden sicher zu stellen.

Dies geht in imperativer Programmierung prinzipiell nicht.

Bei funktionaler Programmierung hat eine Value IMMER den selben Wert und sie kann
NIEMALS geändert werden. Deswegen ist der Programmverlauf mit Exaktheit voraussagbar.

Dieser Aspekt war bisher leider in der Diskussion untergegangen.
Deswegen erwähne ich ihn hier nun.

Dies ist ein wesentliches Konzept, musste also noch mal genannt werden.



Gruß,
   Oliver