Wie ist F#

krümelkacker

visuaklstudio schrieb:

Wie ist eigentlich F# im Vergleich zu C++ und Lisp, verglichen bezüglich Performance und Mächtigkeit?

Ich habe F# nie programmiert. So, wie ich das verstehe, ist das eine funktional-angehauchte Sprache für das .NET Framework. Und das Stichwort ".NET" beantwortet meiner Meinung nach auch schon die Punkte Performance und Mächtigkeit. Ich verstehe unter Mächtigkeit das, was mir C++ bietet, nämlich ein großes Abstraktionsspektrum einschließlich Low-Level-Frickelei. Und weil Du nur in C++ sog. "zero cost abstraction" hast, sollte sich der Performance-Punkt auch erledigt haben.

Wenn Du eine Anwendung schreiben willst, bei der es nicht auf Performance ankommt und Du es geil findest, dass man in F# ein Programm recht kompakt aufschreiben kann (das glaube ich jetzt einfach mal so), dann probiere es doch mal mit F#.

GPC

krümelkacker schrieb:

visuaklstudio schrieb:

Wie ist eigentlich F# im Vergleich zu C++ und Lisp, verglichen bezüglich Performance und Mächtigkeit?

Ich habe F# nie programmiert.

Dann bist du natürlich prädestiniert für kompetente Antworten im Thread hier

So, wie ich das verstehe, ist das eine funktional-angehauchte Sprache für das .NET Framework.

C# ist seit Version 3.5 "funktional angehaucht". F# ist richtig funktional.
Wer im Umgang mit F# ungeübt ist, der fängt sich leicht eine deutlich schlechtere Laufzeit als mit C# ein. Auf Stackoverflow gibt es eine ganze Reihe von Fragen à la "Why is this code so much slower in F# than in C#"? Es ist eben eine funktionale Sprache und verlangt nach einer anderen Herangehensweise als C# etc.
Ungeachtet dessen ist imo das größte Plus für F#: Man kann die umfangreiche .NET Bibliothek nutzen und trotzdem funktional programmieren.

knivil

Wie ist eigentlich F#

Sehr aehnlich SML oder OCAML.

Was die Perfomance angeht läuft das letztlich auf einen Vergleich zwischen Interpreter (Lisp,Perl,Python,...), Vitual-Machine VM (F#,C#, Java, ...) und Maschinencode-Erzeugung also Assembler oder Hochsprache via Compiler (C,C++,Pascal,Delphi,Fortran, ...) hinaus.

Pauschal gilt da garnichts. Man kann immer (un-)effizient programmieren.

Praktisch sieht es aber meistens so aus. Von langsam -> schnell. Interpreter -> VM -> Compiler -> Handgeschriebener Assembler.

Letzlich diktieren bestimmte Randbedingungen (Problemstellung, mit/ohne GUI, Hardware (PC,Smartphone,...) , Betriebsystem, Programmierer-Know-How...) welche Sprache/Programmierframework das Günstigste ist.

In C++ kann man z.B. ohne Betriebsystem, direkt auf der Hardware, eine Echzeitanwendung entwickeln.

maximAL

m_mm schrieb:

Was die Perfomance angeht läuft das letztlich auf einen Vergleich zwischen Interpreter (Lisp,Perl,Python,...)

Gibt auch Lisp-Implementierungen, die recht effizienten C-Code erzeugen.

maximAL schrieb:

m_mm schrieb:

Was die Perfomance angeht läuft das letztlich auf einen Vergleich zwischen Interpreter (Lisp,Perl,Python,...)

Gibt auch Lisp-Implementierungen, die recht effizienten C-Code erzeugen.

Das ist sicherlich richtig. Meine Erfahrung ist halt die, je weiter man Richtung Assembler absteigt, desto performanter wird es. D.h. generierter C-Code erreicht meistens nicht die Perfomance von Handmade-C-Code, kann aber mit einer VM durchaus mithalten. Wenn es sehr rechenintensiv wird, sind CPU-optimierte Assemblerroutinen das Non plus ultra. Von durchdachter Auslagerung auf die GPU ganz zu schweigen.

Wie funktional ist C++11?

Bashar

Mal abgesehen davon, dass Lisp im engeren Sinne Common Lisp bedeutet und die führenden Common Lisp Implementationen zu Maschinencode compilieren: Wenn man für ein gegebenes Problem ernsthaft frei im Spektrum zwischen Lisp und handgeschriebenem Assembler wählen kann, dann ist es kein Problem, für das man normalerweise Lisp verwenden würde.

knivil

maximAL schrieb:

Gibt auch Lisp-Implementierungen, die recht effizienten C-Code erzeugen.

Gibt auch Lisp/Scheme/Haskell/SML/...-Implementierungen, die effizienten Maschinencode generieren.

dann ist es kein Problem, für das man normalerweise Lisp verwenden würde

Aber auch nur, weil viele nicht versiert genug in dieser Sprache sind.

maximAL

Bashar schrieb:

Mal abgesehen davon, dass Lisp im engeren Sinne Common Lisp bedeutet

Sagt wer?