Hallo allerseits,
um es vorweg zu nehmen: Ich hab weder von .net noch von funktionalen Programmiersprachen wirklich 'ne Ahnung, geschweige denn je irgenwas Größeres damit programmiert, aber mich würd trotzdem folgendes brenned interessieren:
Was ich mir an .net immer gut gefallen hat ist, dass der Bytcode-Interpreter nicht direkt auf eine bestimmte Programmiersprache angelegt ist.
Es gibt zwar für zig Programmiersprachen auch irgendwelche Compiler die Java-Bytecode erzeugen, aber irgendwie gibt’s da doch immer das Problem, dass bei Java-Bytecode insbesonder Closures o. ä. nicht direkt unterstützt werden und somit dafür jeweils eine eingene Klasse erstellt werden muss, was bei großen Programmen immer in unzählige Klassen ausarten, was für die Performance und den Speicherverbrauch nicht sonderlich toll ist.
Jetzt hab ich auf den „Microsoft Research“ Seiten mal was von „ILX“ gelesen (soll wohl 'ne Erweiterung von IL für funktionale Sprachen oder so sein): Heißt das jetzt, dass IL selber funktionale Sprachen von Haus aus gar nicht so toll unterstützt und wenn ja wird sich das in Zukunft ändern???
Es gibt ja aber schon diverse .net-Compiler für funktionale Sprachen (z. B. www.mondrian-script.org). Was ich mich da aber frag ist: Wenn ich z. B. XML-Parsing in Haskell mach oder Datenbank-Zugriffe oder das gesamte Event-Handling, da hab ich doch gänzlich andere Möglichkeiten als in C# (z. B. Funktionen als First-Class-Citizens oder nicht-strikte Listen etc.) und würde so Zeug doch signifikant anders angehen als mit DOM, SAX oder irgendwelchen expliziten DB-Cursor Objekten.
Hieße das somit, dass man prinzipiell zuerst zu allen .net-APIs 'n Haskell-Wrapper schreiben müsste, um ordentlich im Haskell-Style programmieren zu können (und solche Wrapper jeweils entsprechen für alle anderen „etwas ungewöhnlicheren“ Programmiersprachen)???
Danke im Voraus für eventuelle Antworten
Gruß Lala