[linux-l] Ocml vs. Java

[Oliver Bandel]

Moin,

habe die Mail wohl übersehen...


On Tue, Sep 27, 2005 at 07:19:17AM +0200, olafBuddenhagen at gmx.net wrote:
> Hallo,
> 
> > Mag sein, aber dort gibt's Listcomprehensions, da sind sie von den
> > Dogmen etwas abgegangen zugunsten von "Usability".
> 
> Ich nehme diese Äußerung jetzt mal exemplarisch als Aufhänger, um etwas
> aufzuzeigen, was ich schon seit Tagen beim lesen diese Threads im Kopf
> habe: Ihr redet IMHO allesamt ziemlich am Punkt vorbei.
> 
> Ob man nun etwas schreibt als
> 
>    list=[a+b for a,b in zip(liste1,liste2)]
> 
> oder
> 
>    list=array_map(function('a,b', 'return a+b;'), list1, list2);
> 
> oder
> 
>    for(i=0; i < sizeof list/sizeof list[0]; ++i) list[i]=list1[i]+list2[i];
> 
> oder was auch immer, ist doch wirklich nur ein syntaktisches Detail, und
> mehr Geschmacksfrage als alles andere.

ACK.

[...]
> Die wesentliche Eigenschaft von funktionalen Sprachen ist, dass es
> keinerlei Side Effects gibt.

ACK.

(genauer: Eine wesentliche Eigenschaft)


> Es werden nur funktionale Abhängigkeiten
> zwischen den Eingangswerten und dem Ergebnis festgelegt; die
> Abarbeitungsreihenfolge und Repräsentation von Zwischenergebnissen ist
> dagegen allein Sache des Compilers.
> 
> Zum einen hat der Compiler damit natürlich viel mehr Raum beim
> Optimieren. Da im Gegensatz zu imperativen Programmiersprachen keinerlei
> Vorgaben gemacht werden, kann der Compiler völlig frei entscheiden,
> welche Reihenfolge der Rechenoperationen und Organization der Daten im
> Speicher am effizientesten ist.


Bezogen aber nur auf Parameter, deren Reihenfloge egal ist, also
wenn eine Funktion drei Argumente/Parameter bekommt, ist die Abarbeitungs-
reihenfolge nicht vorher bestimmt.

Bedarf jedoch ein Wert die Berechnung eines anderen, um ausgeführt zu werden,
liegt damit auch fest, wie die Abarbeitungsreihenfolge ist.
Durch entsprechende Formulierung des Codes wird dadurch die Reihenfolge
festgelegt.


[...]
> Gerade mit zunehmender
> Parallelität der Hardware, wird das immer wichtiger: So muss sich der
> Compiler beim Anordnen der Befehle nur um tatsächliche logischen
> Abhängigkeiten im Rechenweg kümmern, nicht um künstlich vom
> Programmierer geschaffene -- was sehr weitreichende Möglichkeiten bietet
> beim Umordnen von Rechenschritten, Verschachteln von Code,
> auto-Vektorisierung, und automatischem Threading. Itanium freut sich ;-)

Eben.
Man denke nur an Biorechner, wo das ganze Rechnen auf Molekülbasis abläuft...
...schön parallel das ganze.
Wenn man das alles von hand vorgeben will... da kommt man quasi nur noch
mit funktionalen Ansätzen weiter, wenn es so extremst parallel/((nicht nur) number)
cruncht wird.


> 
> Andererseits heißt das natürlich, dass der Programmierer sich das
> Festlegen der Befehlsreihenfolge und Datenorganisation spart. In dem
> Sinne ist funktionale Programmierung tatsächlich "high level",


Allerdings.

> verglichen mit imperativen Sprachen (zu denen nach meinem Verständnis
> auch die sogenannten "objektorientierten" Sprachen gehören).

korrekt.


> Allerdings
> erfordert es auch ein wesentlich abstrakteres Denken, was nicht
> Jedermanns Sache ist.

Naja, ich finde, es ermöglicht dem Programmierer,
sich auf das wesentliche (das, was getan werden soll)
zu erledigen, statt sich um Bits und Bytes und Speicherallokation
usw. zu kümmern, was man ja i.A. eigentlich garnicht zur Problemlösung
ausführen will.


> 
> Das Problem mit rein funktionalen Sprachen ist, dass das Konzept sehr
> schnell an Grenzen stößt, wenn das Problem über simples Batch-Processing
> hinausgeht.

Konkretes Beispiel?

> Vor allem fehlt dem Compiler das Verständnis über zeitliche
> Abläufe,

Die man aber erzwingen kann.

> welches einem imperativen Programm ganz automatisch mitgegeben
> wird,

Was man da leider machen muß, auch wenn es garnicht von Belang ist
für die Aufgabe.


> selbst wenn der Programmierer sich garnicht bewußt Gedanken über
> Optimierung macht.

Er kann sich gedanken über Optimierung von Algorithemn machen, statt
Gedanken über Optimierung auf Prozessor-/Speicher-/Registerebene.
Der Hardware-Cache wird einem ja auch nicht per API zur Steuerung übergeben.
Oder sollte man ds machen? Damit man die zeitlichen Abläufe kontrollieren
kann?


> Hier wird also das Fehlen von Vorgaben bei der
> Abarbeitungsreihenfolge zum Problem.

Wo genau?

Man kann die Abläuf vorgeben.


Um etwas genauer zu werden:
 Es gibt auch bei funktionalen Sprachen Unterschiede.
 Es gibt strict und lazy evaluation.
 Beides hat Vor- und Nachteile. Du meinst vermutlich Sprachen
 mit Lazy-Evaluation? Da ist es in der Tat wohl auch bzgl.
 Abarbeitungsgeschwindigkeit (Algorithmen-"Kosten"-Abschätzung schwierig)
 nicht immer optimal.
 Bei lazy-eval werden überhaupt nur Berechnungen der Argumente durchgeführt,
 wenn dies als notwendig angesehen wird. Wenn die Werte nicht neu berechnet
 werden müssen und stattdessen ge-cache-t werden und wieder verwendet werden
 können, hat dies oftmals Vorteile (aber eben nicht immer).
 
 Lazy-eval kann man auch in nicht-lazy Sprachen per Algorithmus-gestaltung
 erzeugen. Deswegen sind IMHO letztere flexibler.


Gruß,
   Oliver