[linux-l] Ocml vs. Java

[Oliver Bandel]

On Mon, Oct 03, 2005 at 12:54:05AM +0200, olafBuddenhagen at gmx.net wrote:
> 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?

Hmhh.
Was der Ursprung ist und was draus folgt, ist vermutlich eine
Frage nach Henne und Ei oder so... ;-)


Aber es gibt weitere Merkmale von FPLs.


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


Und das ist gut so. :)   ;-)



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

Und dennoch optimieren die meisten Programmierer auf lokale
Laufzteitoptimierung... (bei OpenGL und Co. verständlich,
aber nicht bei allg. Anwendungen).


> (Mal abgesehen davon, dass der
> größte Teil der genutzten Leistung auch noch auf Bürokratie
> draufgeht...)

Bürokratie? ;-)
Thread-Verwaltung (usw.) meinst Du?


> Nur spezielle, gut optimierte (oder gut
> Compiler-optimierbare) Programmtypen, wie multimedia-Zeugs und andere
> rechenintensive Sachen, arbeiten meistens noch halbwegs effizient.

Und an der Ineffizienz der anderen SW sind keine FPLs beteiligt. ;-)


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

Naja, hängt viell. auch vom Typus der Leute ab.
Ich bin auch immer sehr erfreut, wenn ich schnell
Ergebnisse bekomme und nicht erst lange herum studieren muß.
Andererseits bringt es aber auch was, mal ein bischen um sich
zu schauen. ;-)


> Imperative Programmierung erfordert in der Regel viel
> mehr Aufwand, ist aber greifbarer.


Vielleicht ist das aber nur deshalb so, weil funktionale Programmierung zu selten
gelehrt wird und man mit imperativer Programmierung zugepflastert wird.

Ich denke mal, wenn man sich zurück erinnert, wie man C oder ähnliche Sprachen gelernt hat,
hat man das wohl auch für seltsam gehalten. Man hat sich im Laufe vieler Jahre dran gewöhnt
und "plötzlich" sind die FPLs etwas gaaanz seltsames und unanschaulices?


Hmhhh.... naja, vielleicht ist da schon was dran.
Man macht eine Schachtel auf, legt etwas rein und kann das da wieder
raus holen; und dann legt man was anderes rein und kann das ebenfalls
dort wieder raus holen (wenn nicht jemand anderes (Seiteneffekt)
es schon vorher raus genommen hat oder was anderes rein gelegt hat...).

Das ist schon was anderes, als wenn alle Schachteln, die man hat, immer
das selbe enthalten und man bloß immer eine neue Schachtel vor die alten stellt
und man nur die aktuellen sieht... aber alle enthalten immer das, was sie zu Beginn
drinne hatten...


Auch die Objektkonstanz ist eine anerlernte. ;-)


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

Nun gut.

Sollte man aber mal ausprobieren, ob es ind er Praxis dennoch klappt.

Mal den Praxistest machen.



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

Was meinst Du denn jetzt?

Ich dachte, es geht Dir gerade um programmoptimierung bzgl. I/O.


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

SSE?


> 
> 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 :-)


Naja, OCaml bietet in gewissem Rahmen die Möglichkeit, das Verhalten
des GarbageCollectors zu beeinflussen.



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


Lazy evaluation ist keine Programmoptimierung.
Es ist das, was anscheinend Volker suchte: Das programm ist so ausgelegt,
daß es unendliche Werte verarbeiten kann, es gibt aber immer nur einen
Wert zurück... und ggf. wird auch gecachet usw.

Das kann man mit strict FPLs (also die, die sofort die Parameter berechnen)
aber nachbilden.

Anders herum geht es aber nicht: Wenn die Sprache (der Compiler, aber abgesegnet
durch den Sprachstandard, also wer es letztlich ist (Compiler? Sprache?)
kann man lange ausphilosophieren) lazy ist, kann man sie nicht durch
"optimierungen" strict machen.

Es geht nicht um Optimierung, sondern um grundsätzlich anderes Verhalten!


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

Nö, also ob man die Grenzlinie so ziehen kann, das wage ich mal zu bezweifeln.
Aber diese Annahme zu ziehen liegt nahe, wenn man sich durch das zu Lesende kämpft.
Aber es ist vermutlich nicht 100%ig zutreffend.

(fuzzy borders?!)


> 
> Ideal wäre wohl eine Sprache, die per Default alles automatisch macht,

Ja, auch die Benutzung des Computers, so daß man den ganzen
Rechner-Krams mit sich selbst beschäftigen lassen kann und wir
brauchen dise und andere Diskussionslisten nicht mehr benutzen. ;-)


> aber es bei Bedarf auch ermöglicht tiefer zu gehen, und mehr per Hand
> festzulegen

wozu?
Wenn man in der Sonne liegen kann und irgendwelche Drinks schlürfen kann? ;-)


> -- bis hinuter zum Level von C. (Am besten noch voll
> abwärtskompatibel zu C :-) )

C?


Das war doch "vor Kurzem" noch eine High-Level-Language...


...also wenn schon, dann abwärts bis Assembler.


Aber was C angeht: naja, OCaml hat ein ganz gutes C-Interface.

Ciao,
   Oliver

P.S.: Oh, mal bald schlafen gehen... ;-)