

F# Basics An Introduction to Functional Programming for .NET Developers - gspyrou
http://msdn.microsoft.com/en-us/magazine/ee336127.aspx

======
giu
If you want to dig deeper into F#, have a look at _The F# Survival Guide_ ,
which is a free online guide that was posted here on HN some time ago:
<http://www.ctocorner.com/fsharp/book/default.aspx>

Edit: Here's the link to the original post:
<http://news.ycombinator.com/item?id=1109754>

~~~
Stasyan
Or if you don't mind spending money, then buy Expert F#:
<http://apress.com/book/view/1590598504>

~~~
gtani
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

------
bmason
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.

------
icco
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.

------
jpatte
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#.

~~~
MichaelGG
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#:

    
    
      int target;
      int someValue;
      if (dict.TryGetValue("key", out someValue)) {
          target = someValue * 100;
      } else {
          target = 42; // default
      }
    

F#:

    
    
      let target = match dict.TryGetValue "key" with
                   | true, x -> x * 100
                   | _	   -> 42 // default
    

Not only is the code more concise in F#, we get another benefit too. The
temporary value x, needed because of the use of out params in C#, no longer
exists in the F# version. In C#, this temp val escapes its needed scope - it
should only be needed in the branch where it's used, but instead it's now a
normal local.

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.

~~~
runT1ME
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.

~~~
omellet
How exactly is the CLR crippled?

~~~
bmason
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.

~~~
omellet
You're right, I misread it.

