[linux-l] Ocml vs. Java

[Oliver Bandel]

On Mon, Oct 03, 2005 at 12:57:45AM +0200, olafBuddenhagen at gmx.net wrote:
> Hallo,
> 
> > > Was spricht denn gegen Listen? Allein die Dateiegröße?
> > 
> > Ja, aber nicht nur. Ist die Datei ne Pipe, dann will ich, dass das
> > Programm sofort nach jeder Zeile reagiert, und nicht erst, nachdem die
> > Pipe ein EOF sendet.
> > 
> > Außerdem: Schon prinzipiell packe ich nichts in eine Liste, von dem
> > ich 1. im Voraus die Größe nicht abschätzen kann und 2. nur
> > sequentiellen Zugriff brauche. Das ist für mich eine Grundregel des
> > gesunden Programmierer-Verstands.
> 
> Genau um solche Fragen sollte sich der Programmierer garnicht kümmern
> müssen.


Naja, kommt drauf an, auf welcher Ebene man seine Programmierung ansetzt.
Wenn man noch higher-level haben will, als funktionale Sprachen es anbieten,
dann schreibt man eine DSL, die das alles erledigt, was man sonst in einer
allg. Sprache selbst schreiben muß.
Viell. wird aus sowas im Laufe der Jahrzehnte auch eine neue High-Level-Language
und heutige High-Level-Languages sind dann mehr-oder-wniger Low-Level Languages.

Es gibt durchaus einige interessante Programme/Sprachen/Projekte, wo es um z.B.
verteilte Programmierung usw. geht, etc.

Wenn man eine funktionale Programmiersprache sucht, die z.B. auf verteilten
Systemen läuft, dann kann man ja auf Erlang zurück greifen. Diese Sprache
wurde extra entwickelt, um auf den Ericsson-Routern zu laufen, ist also,
obwohl eine funktionale Sprache, kommerziell in Gebrauch, und obendrein für
Geräte im Einsatz, die durchaus im Real Life harten Anforderungen ausgesetzt werden.
Erlang ist eigentlich der beste Beleg dafür, daß man mit FPLs durchaus auch
"praxisrelevante" Anwnednungen schreiben kann.




> 
> Die Listen sind bei rein funktionalen Sprachen doch nur eine
> Abstraktion.

Hmhhh.. Listen sind Datenstrukturen.
Egal, ob in funktionalen oder imperativen Sprachen.


> Der Compiler sollte selbst entscheiden, ob er tatsächlich
> eine komplette Liste aufbaut, oder das ganze rein sequentiell
> abarbeitet, oder vielleicht jeweils kleine Blöcke liest und abarbeitet.

Dazu sind die heutigen Sprachen und der heutige Stand der Informatik
noch nicht weit genug. Selbst funktionale Sprachen noch nicht.

Ich denke mal, das ist noch mindestens einen Abstarktionslevel drüber;
das sind also derzeit vielleicht Applikationen, die einem solcherlei
Entscheidungen erleichtern/abnehmen, aber als Sprachen wird man sowas
wohl erst in einigen Jahren/Jahrzehnten erwarten können.

Gegenbeispiele?



> (Soweit es der Algorithmus zulässt, wird es eigentlich immer auf
> Letzteres hinauslaufen, da das am effizientesten ist -- Parallität der
> Hardware kann ausgenutzt werden, und es wird sparsam mit Speicher/Cache
> umgegangen.)

Kommt eigentlich auf den Anwendungsfall drauf an; auch, ob die
Platten schnell sind, oder wie komplex die Datenerzeugung ist.
Kann man eigentlich so allgemein nicht sagen...


> 
> Das mit der Pipe ist allerdings ein gutes Beispiel für die Grenzen rein
> funktionaler Programmierung -- ein sehr ähnliches wollte ich für den
> anderen Teilthread benutzen:

Naja, ist nicht unbedingt gegen funktionale Programmierung sprechend.
Es gibt verschiedene Ausführungen funktionaler Programmiersprachen,
auch was das zeitliche Verhalten angeht.

Ist doch genauso wie die Frage, ob man Linux für Realtime-Anwednugen einsetzen
kann... naja, eigentlich kann man damit keine Audio-Daten und Videodaten
abspielen, es ist nur Soft-Realtime möglich. Aber anderersseits, mit genügend
Rechenlesitung hat man kaum Probleme.
(naja, für harte Echtzeitbedingungen reicht das dann halt doch nicht,
 aber das war ja auch nicht Dein Anwednungsgebiet.)


> 
> Zur Zeit bastle ich an einigen Progrämmchen, die bestimmte Testtöne
> erzeugen. Nun gibt es diverse Möglichkeiten, das zu Implementieren: Man
> kann in einer Schleife jedes Sample jeweils komplett für sich berechnen
> und gleich ausgeben. Oder man könnte den gesammten Ton im Speicher
> aufbauen und dann ausgeben. Oder halt Blockweise. Auch kann man
> bestimmte Werte, die immer wieder benutzt werden, schon vor dem Eintritt
> in die Hauptschleife berechnen. Und so weiter.

Naja, was schickt man denn an die Audiokarten-Treiber?
Kann man da nicht einfach irgendwelche "high-level"-commands
absetzen und den Rest die Karte machen lassen?
Oder muß man da nach wie vor noch die einzelnen Abtastwerte an
die Karten transfrieren? (Aber bei heutigen Rechnergeschwindigkeiten
sollte selbst das kein Problem mehr sein...).


> 
> All diese Entscheidungen würde mir bei einer rein funktionalen Sprache
> der Compiler abnehmen.

Ich denke, das kommt drauf an...
...bei OCaml z.B. braucht man sich nicht um Speicherfreigabe kümmern
bzw. sollte man nicht brauchen, denn es gibt da einen garbage Collector.
Andererseits  gibt es da auch das Gc-Modul für den Garbage Collector,
sowohl wegen Abfragung statistischer Parameter, als auch zur Setzung
von Randbedingungen unter denen der GC arbeitet.

Funktionale Sprachen haben bestimmte Eigenschaften (z.B. Funktionen
als first-class values usw.), aber das lässt sie deswegen noch nicht
die Design-Entscheidungen treffen.


[...]
> gespeichert, sondern direkt (per sox) an die Soundkarte gepipet -- und
> die möchte die Daten nun mal recht kontinuierlich. Wenn der Compiler
> meint, es wäre optimal in sehr großen Blöcken zu rechnen, gibt es ein
> Problem.


Bzgl. Echtzeit ist bei funktionalen Sprachen nicht der Compiler das Problem,
sondern einerseits, wie die Funktionen ausgeführt werden (strict odr lazy)
und wie der Garbage Collector agiert (damit der einem nicht die Ressourcen klaut,
wenn er gerade aufräumt).


Gruß,
   Oliver