Entwickler-Ecke
Off Topic - Microsoft F# Programmiersprache
Kha - Sa 14.11.09 00:15
 ssb-blume hat folgendes geschrieben  : |
| Hat schon mal jemand damit programmiert und Erfahrungen? |
*nach links schielt* :D
Nach etwas Eingewöhnung, die wohl jeder benötigt, wenn er zum ersten Mal mit funktionaler Programmierung zu tun hat, habe ich F# zu meiner Hauptsprache auserkoren - es sei denn, gewisse Technologien/... zwingen mich zu C#. Um es gleich klar zu machen: F# besitzt weder Winforms-Designer noch wirkliche ASP.NET-Unterstützung, was sich so schnell auch nicht ändern wird.
Ich sage es einfach, wie es ist: Die schönste Sprache, die ich bisher kennen gelernt habe, ist Haskell. Leider programmiert man eben nicht
nur Algorithmen, weshalb ich glaube, dass eine pure funktionale Sprache zu einschränkend und OOP für große Projekte unabdinglich ist, und ich für keine Sprache der Welt auf ein Framework und Ökosystem wie .NET verzichten will. Die Lösung lautet F# ;) .
Noch ein wichtiger Punkt: Ebenso wie Delphi Prism
bemüht sich F# im Gegensatz zu C# erst gar nicht darum, für wirklich jeden verständlich zu sein. Würde mich interessieren, ob das die Prism-Leute auch so sehen ;) .
| thD hat folgendes geschrieben : |
| Habe dazu 2 Videos gefunden. Vl habt ihr auch noch irgendwelche? |
Eine schöne Aufstellung von einem Mitglied des F#-Teams:
Brian's favorite online content for learning F# [
http://lorgonblog.spaces.live.com/blog/cns!701679AD17B6D310!1325.entry].
PS: Ein definitives Kriterium, dass man sich schleunigst F# anschauen sollte: Man hat schon schmerzlich mehrere Funktionen in der Enumerable-Klasse vermisst und sie selbst nachgerüstet...
Chryzler - Di 17.11.09 17:04
Ich verfolge die Sprache schon seit längerer Zeit und hab bisher die Erfahrung gemacht, dass in manchen Bereichen F# die Nase vorn hat, während ein anderes Mal C# als die bessere Wahl erscheint.
Als klare Vorteile von F# sehe ich z.B. die kompaktere, einfach "leichtere" Syntax. C# wirkt dagegen doch recht aufgebläht und "verbose" (wenn man C# gewöhnt ist fällt einem das gar nicht so auf, ging mir zumindest so ;)). Auch die Ideen der funktionalen Programmierung und deren in F# üblichen Sprachkonstrukte (Pipelining, die vielen Enumerable-Funktionen, ..) haben schon einen gewissen Reiz und können richtig Spaß machen. :)
Auf der anderen Seite sehe ich als eine der größten Schwächen von F# die eher dürftige Performance, C# ist hier doch meist ein bisschen bis viel schneller. Gerade da F# als Sprache für komplizierte Algorithmen angespriesen wird sehe ich hier noch viel Verbesserungspotenzial.
Prinzipiell hat man zwei Möglichkeiten: lesbarer, sauberer, langsamer, funktionaler Code oder unschöner, schneller, imperativer Code. Aber für den zweiten Fall braucht man eigentlich kein F#.
Ich denke man muss gut überlegen, ob sich die Sprache für das, was man machen möchte, eignet. Sprachen wie C# oder VB.NET haben einfach den Vorteil, dass sie sehr vielseitig sind, während F# eine doch eher speziellere Sprache ist. Für Algorithmen oder Programme, die z.B. viel mit internen Listen arbeiten und bei denen die Geschwindigkeit nicht ganz so wichtig ist, ist F# aber mit Sicherheit eine gute Wahl.
Kha - Sa 21.11.09 14:19
| Chryzler hat folgendes geschrieben : |
| Als klare Vorteile von F# sehe ich z.B. die kompaktere, einfach "leichtere" Syntax. C# wirkt dagegen doch recht aufgebläht und "verbose" (wenn man C# gewöhnt ist fällt einem das gar nicht so auf, ging mir zumindest so ;)). |
Jupp, die Syntax tut einfach gut :D . Unverständlich, wie manche Leute noch mit solch weitschweifigen Sprachen wie Java arbeiten können ;) .
| Chryzler hat folgendes geschrieben : |
| Prinzipiell hat man zwei Möglichkeiten: lesbarer, sauberer, langsamer, funktionaler Code oder unschöner, schneller, imperativer Code. Aber für den zweiten Fall braucht man eigentlich kein F#. |
Naja, ist das in der Praxis wirklich ein klar getrenntes "oder" :gruebel: ? Für mich stellt es sich eher so dar: Bei den
wenigen Programme, bei denen sich Micro Optimisations überhaupt lohnen, existiert ein Hot Path von vielleicht 5% des gesamten Codes, der wirklich performancekritisch ist. Bei den restlichen 95% kommt es immer noch in allererster Linie auf Wartbarkeit an, und dazu ist "so deklarativ wie möglich" nie falsch. Da ich für 5% nicht die Sprache wechseln will (oder dann gleich C++ statt C# nehme), scheint mir eine Hybridsprache wie F# die beste Lösung zu sein :D .
Martok - Sa 21.11.09 17:01
Irgendwie kann ich mir grad nicht vorstellen wie ein komplettes (sinnvolles) Programm damit aussieht. Aus den Codeschnipseln werd ich irgendwie nicht schlau...
Khann ( ;-) ) da mal wer eine kleine Beispielanwendung posten?
Kha - Sa 21.11.09 19:06
Ich nehme an, es geht dir um den Eintrittspunkt...?
Code in der letzten Datei wird automatisch ausgeführt. ein UPN-Parser, frech von
Wikipedia [
http://en.wikipedia.org/wiki/Haskell_(programming_language)#More_complex_examples] geklaut:
C#-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
| let parse(s: string) =
let eval stack token = match stack,token with
| x::y::zs, "+" -> x+y :: zs
| x::y::zs, "-" -> x-y :: zs
| x::y::zs, "*" -> x*y :: zs
| x::y::zs, "/" -> x/y :: zs
| xs, literal -> int literal :: xs
match s.Split null |> Seq.fold eval [] with
| [x] -> Some x
| _ -> None
parse "2 1 +"
|> printfn "%A" |
Über EntryPointAttribute bekommt man dagegen eine Main-Methode wie in C#/Java/...:
C#-Quelltext
1:
2:
3:
4:
5:
6:
7:
| [<EntryPoint>]
let main args =
String.concat " " args
|> parse
|> printfn "%A"
0 |
Quelltext
1:
2:
3:
4:
| > UPN.exe 2 1 +
Some 3
> UPN.exe 2 1 + *
<null> |
Ähm, ja, null :mrgreen: . Eine kleine Optimierung von Option<T> zu Ungunsten von print ;) .
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2026 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!