[linux-l] Ocml vs. Java

[olafBuddenhagen at gmx.net]

Hallo,

> > Die wesentliche Eigenschaft von funktionalen Sprachen ist, dass es
> > keinerlei Side Effects gibt.
> 
> ACK.
> 
> (genauer: Eine wesentliche Eigenschaft)

Nein, *die* wesentliche Eigenschaft. Alles andere was Du so erwähnt hast
ist -- so weit ich das sehen kann -- entweder eine Vorraussetzung des
Obigen, oder eine Folge davon, oder nicht wesentlich, oder rein formal,
oder unabhängig vom funktionalen Konzept. Oder ist mir etwas entgangen?

> 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.

Freilich. Das sind halt die echten, funktionalen Abhängigkeiten. Daraus
ergeben sich natürlich gewisse Bedingungen beim Ordnen des Codes. Aber
an sonsten ist der Programmfluß absolut frei vom Compiler wählbar. Wenn
tausend unabhängige Berechnungen erfolgen, bevor die nächste
Abhängigkeit einsetzt, kann der Compiler die Reihenfolge und Aufteilung
auf verschiedene Register/Recheneinheiten/Prozessoren so umwürfeln wie
er lustig ist.

> 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.

So weit muss man garnicht denken. Schon auf standard-Prozessoren der
letzten Jahre wird von den meisten Programmen nur ein Bruchteil der
Prozessorleistung wirklich genutzt. (Mal abgesehen davon, dass der
größte Teil der genutzten Leistung auch noch auf Bürokratie
draufgeht...) Nur spezielle, gut optimierte (oder gut
Compiler-optimierbare) Programmtypen, wie multimedia-Zeugs und andere
rechenintensive Sachen, arbeiten meistens noch halbwegs effizient.

Und mit Multicore und EPIC wird das Problem jeweils noch vervielfacht.

> > 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.

Freilich. Ändert aber nichts daran, das bestimmte Leute (vor allem
Anfänger/schwache Programmierer), nicht so abstrakt denken
können/wollen. Imperative Programmierung erfordert in der Regel viel
mehr Aufwand, ist aber greifbarer.

> > 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?

Siehe anderen Subthread.

> > Vor allem fehlt dem Compiler das Verständnis über zeitliche Abläufe,
> > 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.

Klar -- meistens. Manchmal ist es das aber eben doch, sobald I/O ins
Spiel kommt.

> > 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.

Um programminterne Optimierung geht es hier garnicht. Das Problem sind
äußere Vorgaben -- teilweise um das Gesamtsystem zu optimieren,
teilweise weil es sonst garnicht das gewünschte ergibt.

> 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?

In gewissem Maße geht das sogar mit SSE. (Wird durch das erste S, das
"Streaming", ausgesagt.)

Zum Zwecke des Resource-Managments wäre es eigentlich sogar
wünschenswert, die Cache-Nutzung allgemein kontrollieren zu können. Ist
wohl aber technisch leider nicht realistisch. Und vor allem total OT :-)

>  Lazy-eval kann man auch in nicht-lazy Sprachen per
>  Algorithmus-gestaltung erzeugen. Deswegen sind IMHO letztere
>  flexibler.

Du kannst auch jede andere Optimierung funktionaler Programmiersprachen
per Programmgestaltung in imperativen Sprachen erzeugen... Wir sind uns
doch aber wohl einig, dass solche manuellen Optimierung im Allgemeinen
gerade *nicht* das sind, was wir wollen.

Ich habe von der ganzen Theorie wenig Ahnung; was Lazy Evaluation
konkret bedeutet, weiß ich nicht. So wie ich das jetzt verstanden habe,
ist es IMHO eine Vorraussetzung für wirklich funktionale Programmierung,
bei der der Compiler die technische Umsetzung (auch Caching) selbst
festlegt. An sonsten haben wir doch nur wieder imperative Programmierung
mit anderer Syntax.

Ideal wäre wohl eine Sprache, die per Default alles automatisch macht,
aber es bei Bedarf auch ermöglicht tiefer zu gehen, und mehr per Hand
festzulegen -- bis hinuter zum Level von C. (Am besten noch voll
abwärtskompatibel zu C :-) )

-Olaf-