F# Basics An Introduction to Functional Programming for .NET Developers(msdn.microsoft.com)
msdn.microsoft.com
F# Basics An Introduction to Functional Programming for .NET Developers
http://msdn.microsoft.com/en-us/magazine/ee336127.aspx
4 comments
Or if you don't mind spending money, then buy Expert F#: http://apress.com/book/view/1590598504
The intro books by Smith ("programming F#", Oreilly) and Pickering (Beginning F#", Apress) are excellent, too. They were published last October and December, and cover what will be in VS 2010
There's also the Wikibook: http://en.wikibooks.org/wiki/F_Sharp_Programming
This seems like a bastardization of FP. I've been studying Clojure for the last few months and I'm amazed at the elegance of Lisp syntax. Maybe the perens have corrupted my brain, but F# just looks really ugly to me. It looks like Microsoft is trying to spoon feed it to C# developers, which is ok I suppose, but I don't think that people are really going to grasp the underlying concepts of FP without letting go of a lot of what they've learned in the imperative world. A familiar syntax can actually be an impediment in this effort, as it creates the impression that two expressions are equivalent when they really aren't.
I've been coding in F# for the last few weeks at school, and I gotta say, F# takes everything good about SML/NJ, and rips it out. I mean it even makes the error messages more cryptic. The CLR is cool, but not worth destroying a language for it.
Could anyone give some examples of instructions which are easily implemented in F# and would be really hard to implement in C#? From what I see here, F# seems nice and clean, but does not add a lot of value compared to LINQ-powered C#.
There are plenty of things. From real-world experience, F# code ends up taking a bit less than half the amount of lines as C# does. More interestingly, the number of type annotations can be as little as 1/20th as in C#.
The benefit comes from that many "small" things you do in C# become much nicer in F#:
C#:
A more large scale win is any async code. In F#, you can use the async workflow (monad), and with 1 character (!), you make the compiler emit code that'd take at least 10 extra lines in C#. Inside an async workflow, a let! (example: let! foo = bar.AsyncGetResponse()) is like calling bar.BeginGetResponse, bar.EndGetResponse, while preserving the current exception handlers and all locals. It makes heavily async code trivial to write, where in C#, it's near impossible.
The benefit comes from that many "small" things you do in C# become much nicer in F#:
C#:
int target;
int someValue;
if (dict.TryGetValue("key", out someValue)) {
target = someValue * 100;
} else {
target = 42; // default
}
let target = match dict.TryGetValue "key" with
| true, x -> x * 100
| _ -> 42 // default
A more large scale win is any async code. In F#, you can use the async workflow (monad), and with 1 character (!), you make the compiler emit code that'd take at least 10 extra lines in C#. Inside an async workflow, a let! (example: let! foo = bar.AsyncGetResponse()) is like calling bar.BeginGetResponse, bar.EndGetResponse, while preserving the current exception handlers and all locals. It makes heavily async code trivial to write, where in C#, it's near impossible.
Thanks for this! Looks like a great language. Its a shame it targets the CLR and Mono is so crippled.
If it was on the JVM, looks like a serious competitor to Scala with some distinct advantages (! operator for sure) along with a little simpler syntax.
If it was on the JVM, looks like a serious competitor to Scala with some distinct advantages (! operator for sure) along with a little simpler syntax.
Keep in mind that F# is very similar to OCaml. OCaml compiles to native executables, so while it's not for the JVM, you should be able to use it on most platforms.
How exactly is the CLR crippled?
The statement was that Mono is crippled. Last I checked, Mono was lagging at least one major release behind Microsoft's CLR. So if you're using fancy new features, you'll probably have to refactor to gain cross platform support, and even then you may encounter bugs and memory leaks.
You're right, I misread it.
A few things:
* Inbuilt support for sequence head and tail - very important for recursive functions.
* Due to the heavily object-oriented nature of C#, type inference is really limited. This makes writing anything non-trivial in functional style rather tedious as your type declarations will become several lines long really quickly. For example, try writing a Y Combinator in C# and F# to see the difference.
* Parallel processing is a lot easier in F#.
* Matching in F# is a lot more powerful than switch-case in C#, which makes functional programming easier.
My point is: functional programming support in C# is good enough for simple things but serious functional programming is a lot easier in F#. On the other hand, OO is a bit cumbersome in F#. I wouldn't use F# for typical web or enterprise create-update-delete database stuff but it is really great for things where functional programming is usually strong at, especially if you need it to work together with C# code.
* Inbuilt support for sequence head and tail - very important for recursive functions.
* Due to the heavily object-oriented nature of C#, type inference is really limited. This makes writing anything non-trivial in functional style rather tedious as your type declarations will become several lines long really quickly. For example, try writing a Y Combinator in C# and F# to see the difference.
* Parallel processing is a lot easier in F#.
* Matching in F# is a lot more powerful than switch-case in C#, which makes functional programming easier.
My point is: functional programming support in C# is good enough for simple things but serious functional programming is a lot easier in F#. On the other hand, OO is a bit cumbersome in F#. I wouldn't use F# for typical web or enterprise create-update-delete database stuff but it is really great for things where functional programming is usually strong at, especially if you need it to work together with C# code.
What is your reason for not using F# in a "typical web" app? Just developer experience and tools, or something with the actual language?
Well, mostly tools. Also as I said, OO in F# is a a bit tedious to do in my opinion and the ASP.NET and ASP.NET MVC are very object oriented and were designed with imperative languages (primarily C#) in mind.
There's nothing in functional programming that prevents it from using in "typical web" apps though, as demonstrated by the engine that runs HN, news.arc, for example.
There's nothing in functional programming that prevents it from using in "typical web" apps though, as demonstrated by the engine that runs HN, news.arc, for example.
Out of true curiosity, what do you find tedious about F#'s OO support? Lack of protected?
Well nothing major really, it's just small bits here and there that are telling signs that it's a functional programming language with OO support and not the other way around. Like that you have to put two types that depend on each other in the same file.
No showstoppers, just minor annoyances that add up over time so when I write F# code I try to limit OO code to interfacing with other libraries (and the framework). Maybe it's just me, perhaps other programmers don't find OO in F# tedious at all.
No showstoppers, just minor annoyances that add up over time so when I write F# code I try to limit OO code to interfacing with other libraries (and the framework). Maybe it's just me, perhaps other programmers don't find OO in F# tedious at all.
Pattern matching and discriminated unions make code for structuring and destructuring complicated data really clean and pleasant to work with. Compiler implementation is the obvious application, but in a "businessy" setting, I sure wish that some of the EDI code I work with periodically was in F# instead of C#.
Edit: Here's the link to the original post: http://news.ycombinator.com/item?id=1109754