I love how the article is called "Why F#" but then just extols the virtues of functional programming. I suppose more articles on FP are always a plus... However, here is a bit that should be in the article but is missing:
"Why not F# for Functional Programming?"
- It's created by Microsoft, who will drop a technology like a wet stone when it's no longer profitable and abandon developers relying on the platform.
- If you find a bug in F#, you have to pray Microsoft deems it worthy to be fixed.
- You can't learn about how F# works by studying the source code of the language.
- You have to spend lots of $$ to be able to program in F#.
- Haskell is more elegant and has a more robust community.
- You can run your code only on a Windows machine (reliably.)
There are arguments you could make defending F# as a choice (libraries, etc) but this article doesn't address those issues.
UPDATE: Ok Ok... I admit F# has decent support on other platforms at this point.
I like both Haskell and F# so perhaps i can give some reasonable counter-arguments.
1) F# will be integrated in Visual Studio 2010. Large commercial companies like banks use F#. It is very unlikely that Microsoft will drop it.
2) Actually the F# team responds very quickly to bug reports. Just send your report to fsbugs@microsoft.com
3) F# is not yet open source, but the source code is available. They have promised to eventually open source it like Microsoft has done with IronPython and IronRuby.
4) Visual Studio Express editions are free. It would be nice if MonoDevelop had a good add-on for F#.
5) No arguing with that. Haskell can be very elegant and has a very good community.
6) I could argue that F# is more cross-platform than Haskell. Despite Simon Marlow's amazing work Haskell's Windows support is lacking compared to Linux. There are no current plans for GHC to support 64-bit on Windows and several Haskell packages use low-level C libraries which can be less reliable on Windows or difficult to compile whereas the .NET framework and Mono function as a common abstraction layer between Windows and Unix.
I won't deny F# is probably the wrong choice for people who don't use Microsoft technology already. But still, many of your points are wrong or misleading:
- F# is still considered an unreleased research product so you don't know what they'll do with it until it's released. It's within the realm of reason that they would submit it to a standards body like they did C# at which point your criticism is moot.
- Your point about Open Source is a decent point. But people who choose closed source projects tend to do so for their own set of reasons (mostly support and the fact that they don't have the time and/or skill to look through a languages source code to figure out a bug themselves)
- Again, it's unreleased and you don't know what Microsoft will do with it. At least for web development Microsoft makes free software available for using C# and VB.NET (called Visual Web Developer). They could very well integrate F# into that.
- This is just opinion mixed in with conjecture (since again you're talking about an unreleased project with no real community yet)
- I've used Mono and found it very reliable so this is just misleading
Finally, you're quoting an article written by a guy trying to make the case to Microsoft developers. He's talking about his upcoming talk at a Microsoft conference after all.
" But people who choose closed source projects tend to do so for their own set of reasons (mostly support and the fact that they don't have the time and/or skill to look through a languages source code to figure out a bug themselves)"
A bit of background: I'm a bit of an odd duck. I'm a vim using rubyist on ubuntu (with awesome wm) OSS during the day and at night I program in C# on a mac using mono and monodevelop. To me, C# is a much better designed Java (the good parts.) I've found the Mono project to be very reliable as well, and they are doing really cool stuff like aot compilation and running on ARM. Anyway...
To me, F# is interesting because I already program in C# in the same way that clojure is interesting to java developers.
F# is being released with Visual Studio 2010 so its not just a research product anymore right? Also the rest of the .NET framework source is available so I assume F# might be at some point as well.
It's created by Microsoft, who will drop a technology like a wet stone when it's no longer profitable and abandon developers relying on the platform
I'm sorry, but I call bullshit. You can run Windows 3.1 apps on Windows 7 if you must. Say what you like about them, Microsoft's support for their own legacy code is among the best around. The one notable time when MS "abandoned" developers was VB6 -> VB.NET and there was plenty of time to migrate over.
And yes Haskell is more elegant and has a more robust community but F# has all of .NET already, whereas Haskell (and OCaml, and Erlang) all suffer from a lack of commercially relevant libraries.
True, but the thing F# has that other MLs don't is the .NET libraries. There's not much you can do with Mono F# that you couldn't do with OCaml, Mythryl, SML/NJ, MLton...
Those of us that use F# don't really care if it doesn't run on non-windows machines. That said, it runs fine on my iMac in a windows vm :)
Really though, it's a great language for writing business software to run on windows and lots of people will find this useful. Its a pragmatic language, not an idealistic one and it only makes the .NET programmer more powerful. Join the dark side
Out of curiosity, are Y-Combinator folks (start-up founders, etc.) programming for .NET to begin with? It seems the focus here is usually on web apps and the iPhone.
I wrote a program last month to download a CSV file from the web, parse it, check for dupes, and load it into a database.
It took about 20 lines of F# code.
With C# I couldn't even start on the project with that few lines of code.
It's a lot like SQL and stored procs. If you don't know what you're doing (like me) you thrash around using cursors (for-next-loops) and such making a mess the first time you try to solve a problem.
But then, as you get the hang of it, it all "collapses" into this beautiful, small, piping one-line-type syntax, like one of those origami models that goes suddenly from being folded paper to a bird or something.
If you've ever done this with stored procs and cursors, starting with a lot of cursors and eventually using a regular SQL statement to do something that used to take many lines of code, you know what I'm talking about. It's a thing of beauty. I'm not convinced it reads any clearer (although FP folks say it does) and I'm not convinced large code bases are easier to maintain -- but then again I'm not convinced you'll really have the kind of large code bases you see in C#/Java/etc
Ironically, this means that data structures are the critical thing in functional programming. Even more so than in imperative languages. (In my opinion)
Here is another data point. I tried F# for a GUI application some time ago. F# OOP is confusing, with a lot of syntactic variations and limitations on what kind of expressions you can put where. Subtyping doesn't work well because you have to upcast everywhere. I started again in C# and it was much better. Not only is the OOP better but also the IDE.
F# is okay for data processing like you describe, but Ruby is better.
I've anecdotally heard of F# kicking C#s butt when it comes to throughput, but you'll have to poke around on the web to find out more. Sorry I can't provide more details.
Seems like I remember reading a blog where there were some gamer-programmers who had these huge log files to process. Using C# it was just too much -- it took too long. But by using F# (and block operations I think?) they reduced it to some crazy time like 5 minutes or something.
Theoretically they should be the same; they all run on the CLR. But I think F# lends itself to stuff like tail-recursion and data operations such that the code has a tendency to self-optimize as you write it, which is kinda neat.
> Theoretically they should be the same; they all run on the CLR. But I think F# lends ...
I think you are misunderstanding this part. Tail call optimization can (sometimes) allow functional code be as fast as its imperative equivalent. It's not a magic bullet that makes it faster than the imperative code.
"Why not F# for Functional Programming?"
- It's created by Microsoft, who will drop a technology like a wet stone when it's no longer profitable and abandon developers relying on the platform.
- If you find a bug in F#, you have to pray Microsoft deems it worthy to be fixed.
- You can't learn about how F# works by studying the source code of the language.
- You have to spend lots of $$ to be able to program in F#.
- Haskell is more elegant and has a more robust community.
- You can run your code only on a Windows machine (reliably.)
There are arguments you could make defending F# as a choice (libraries, etc) but this article doesn't address those issues.
UPDATE: Ok Ok... I admit F# has decent support on other platforms at this point.