Ask HN: What do you think of F#?
17 comments
I love it. The classic problem of the niche languages, in this case the ML family, has always been the lack of commercially relevant libraries. Which is understandable, the strongholds of OCaml, Haskell, ML etc have traditionally been academia. The other problem is that organizations have been reluctant to start projects in languages for which it has been, rightly or wrongly, perceived that there is poor liquidity in the job market, regardless of the inherent advantages of those languages.
Both those problems have been solved in one fell swoop. Not only is the entire .NET ecosystem available, but it's a shipping, fully supported part of Visual Studio 2010. There is no reason not to use it, from the organization's perspective. Finally, all the FP programmers who've been hiding in the closet, hacking in Haskell on their personal projects, can come out! These are great days!
Both those problems have been solved in one fell swoop. Not only is the entire .NET ecosystem available, but it's a shipping, fully supported part of Visual Studio 2010. There is no reason not to use it, from the organization's perspective. Finally, all the FP programmers who've been hiding in the closet, hacking in Haskell on their personal projects, can come out! These are great days!
Follow-up question: which libraries do you find most useful?
For my work the things "missing" from other ML-family languages are a) rock-solid bindings to commercial RDBMSs and b) an easy way to make simple GUIs. The .NET platform gives me those "for free" and F# is sufficiently close to OCaml that it's an easy transition.
Learning my way around the .NET libraries (having never been a C# programmer) is the biggest hurdle. Last time I did this sort of thing on Windows, MFC and ATL were all the rage...
Learning my way around the .NET libraries (having never been a C# programmer) is the biggest hurdle. Last time I did this sort of thing on Windows, MFC and ATL were all the rage...
I recently completed a project using FParsec (http://bitbucket.org/fparsec/main), which is a parser combinator (http://en.wikipedia.org/wiki/Parser_combinator) library based on Haskell's Parsec (http://www.haskell.org/haskellwiki/Parsec).
"WebSharper"
http://www.intellifactory.com/products/wsp/Home.aspx
---- example:
"This sample builds upon the formlet sample illustrating how formlets may be converted into flowlets for expressing sequences of web forms."
http://www.intellifactory.com/products/wsp/samples/Flowlet.a...
http://www.intellifactory.com/products/wsp/Home.aspx
---- example:
"This sample builds upon the formlet sample illustrating how formlets may be converted into flowlets for expressing sequences of web forms."
http://www.intellifactory.com/products/wsp/samples/Flowlet.a...
I hadn't heard of this, but it looks really interesting. Do you have any experiences with it you can share?
The lib I really like is the F# powerpack.
I used it in a computational finance class about a year ago. I develop solely on Linux, and although it was painful to get working, it definitely wasn't the worst thing I have had to do on Linux...
The actual language was weird. Apparently it was inspired by OCaml, but I felt it was far more verbose 90% of the time, and then randomly succinct. F#'s error messages were straight up useless.
If you are looking for a good functional language, I would probably look elsewhere, but it does have the advantage that it is currently still being worked on, and it has all of the benefits that the CLR brings.
At the very least, I agree with the other comment that it will probably bring more people into functional programming, which is always a good thing.
The actual language was weird. Apparently it was inspired by OCaml, but I felt it was far more verbose 90% of the time, and then randomly succinct. F#'s error messages were straight up useless.
If you are looking for a good functional language, I would probably look elsewhere, but it does have the advantage that it is currently still being worked on, and it has all of the benefits that the CLR brings.
At the very least, I agree with the other comment that it will probably bring more people into functional programming, which is always a good thing.
A genuinely curious question with the subtext that I do not agree with you but wish to find out where you form your basis. The core languages of both are nearly identical (ignore active patterns, computation expressions, .net libs f# functors, polymorphic variants ocaml etc). You can port basic ocaml and F# code and only have to change letters here and there.
What are your parameters for a Good functional language?
What are your parameters for a Good functional language?
Well, I would specify a good functional language as one I enjoy coding in. So far that has been SML/NJ and Racket (PLT Scheme). For some reason I did not enjoy F#, and I blame that more on the strangeness of the .Net libraries than the syntax of the language. Also it has been a year, so maybe the language has changed / I don't entirely remember all of the problems I had.
I've used it for some pet projects, mostly to get my head around a functional language with an easy entry (and exit) route for me: I'm a C# guy by day.
I started doing the Euler things etc. and did a quick dive into lexing/parsing (one strong point that your list is missing, imo). I got hooked. While I still cannot use F# for most of my things (technically it would even be possible, but try to convince your higher-ups that it is a good idea to switch to a language that they've never heard about, "because it is fun"), I use it for small things on a regular basis. You can mix functional and structural/iterative style (which is a plus in my book, the latter just _is_ faster if your program really wants to lend itself to mutable loops in places). You have a huge and well-tested library - the interaction with everything .Net is trivial.
Deployment isn't a big issue anymore: In the past you needed to either compile it statically or ship the F# stuff as well, with its status as a "first class citizen" in .Net 4 there's really no reason to back away from it anymore. It's here to stay.
I didn't have any trouble running it on mono/linux - but I've to admit that I last tried it quite a while ago.
Full Disclosure: I'm a kind of a fanboy here, I guess. The wall in my back is painted with a very nice/succinct 13 line prime number generator in F#, roughly 4cm line height, done as a decoration by my so.. ;)
I started doing the Euler things etc. and did a quick dive into lexing/parsing (one strong point that your list is missing, imo). I got hooked. While I still cannot use F# for most of my things (technically it would even be possible, but try to convince your higher-ups that it is a good idea to switch to a language that they've never heard about, "because it is fun"), I use it for small things on a regular basis. You can mix functional and structural/iterative style (which is a plus in my book, the latter just _is_ faster if your program really wants to lend itself to mutable loops in places). You have a huge and well-tested library - the interaction with everything .Net is trivial.
Deployment isn't a big issue anymore: In the past you needed to either compile it statically or ship the F# stuff as well, with its status as a "first class citizen" in .Net 4 there's really no reason to back away from it anymore. It's here to stay.
I didn't have any trouble running it on mono/linux - but I've to admit that I last tried it quite a while ago.
Full Disclosure: I'm a kind of a fanboy here, I guess. The wall in my back is painted with a very nice/succinct 13 line prime number generator in F#, roughly 4cm line height, done as a decoration by my so.. ;)
> I didn't have any trouble running it on mono/linux - but I've to admit that I last tried it quite a while ago.
It still runs great on mono. I tried it to do some examples while reading "Programming F#". It definitely brings some interesting ideas(not necessarily original but that doesn't make them any less good). I don't have any projects planned for F# but would surely love to use it sometime.
It still runs great on mono. I tried it to do some examples while reading "Programming F#". It definitely brings some interesting ideas(not necessarily original but that doesn't make them any less good). I don't have any projects planned for F# but would surely love to use it sometime.
--but try to convince your higher-ups that it is a good idea to switch to a language that they've never heard about, "because it is fun")
I've never had issues convincing management the biggest issue I have is convincing coworkers who don't see value in learning new languages.
I've never had issues convincing management the biggest issue I have is convincing coworkers who don't see value in learning new languages.
That's the beauty of it - F# is now a peer of C# and VB.NET. There's no reason whatsoever for organizations to shy away from it - it's mainstream now. Whereas even tho' it's a very similar language, I can understand why a PHB would balk at OCaml.
I've been using it regularly for over a year, and I love it. I could start out imperative and then code more and more in a functional style as I got to be a better functional programmer.
Having said that, I did find the transition painful. But that's going to be true of transitioning to FP no matter how you do it.
I'm still in a Windows environment, but I look forward to transitioning to Mono once I get FP down. At that point I'll be on an open, free stack, programming in a powerful language with tons of libraries and thousands of people to help if I have problems. What's there not to like?
Having said that, I did find the transition painful. But that's going to be true of transitioning to FP no matter how you do it.
I'm still in a Windows environment, but I look forward to transitioning to Mono once I get FP down. At that point I'll be on an open, free stack, programming in a powerful language with tons of libraries and thousands of people to help if I have problems. What's there not to like?
I have to point out that F# is licensed under the Microsoft Research Shared Source License Agreement, which isn't an approved OSI license.
http://research.microsoft.com/en-us/um/people/antr/vrr/vrr/l...
They had plans to change to a MS-PL (OSI approved) license but still hasn't happened after 2 years.
On a more practical side, the current license isn't bad, just obscure.
http://research.microsoft.com/en-us/um/people/antr/vrr/vrr/l...
They had plans to change to a MS-PL (OSI approved) license but still hasn't happened after 2 years.
On a more practical side, the current license isn't bad, just obscure.
F# was just released under to OSI-approved Apache open source license.
"tons of libraries" - weren't you the one saying that stupid people don't use libraries? :-)
Gosh no, but happy you read the blog!
My point in the blog was that functional code allows you to "collect" bits of things here are there and then create your own toolset of useful stuff to do. This decreases the working set of symbols a programmer must maintain to a much more manageable level, while maximizing productivity.
It's the difference between the phonebook and having a few important people's numbers written on a piece of paper. The phone book is probably more "powerful" but the process of collecting and managing useful data from the phonebook is the important thing, not the phonebook itself.
Instead we study libraries as if they were ends to themselves. This is like trying to memorize the phone book in order to be able to call people. Yet we continue to do it.
My point in the blog was that functional code allows you to "collect" bits of things here are there and then create your own toolset of useful stuff to do. This decreases the working set of symbols a programmer must maintain to a much more manageable level, while maximizing productivity.
It's the difference between the phonebook and having a few important people's numbers written on a piece of paper. The phone book is probably more "powerful" but the process of collecting and managing useful data from the phonebook is the important thing, not the phonebook itself.
Instead we study libraries as if they were ends to themselves. This is like trying to memorize the phone book in order to be able to call people. Yet we continue to do it.
This is a bit of an off-topic rant, so feel free to skip it if you would prefer a direct answer to the question.
For many years I've made it a point to studiously ignore languages that come out of Microsoft, having been burned too many times by their constantly shifting and sometimes suddenly-expensive tools. Before anyone mentions price, sometimes the expense is hidden in places like what system I would have to run, with what total cost of ownership, in order to use their stuff. There may have been some unknown opportunity costs to me, but I am blissfully unaware of these and have had plenty of other fun languages to use.
For many years I've made it a point to studiously ignore languages that come out of Microsoft, having been burned too many times by their constantly shifting and sometimes suddenly-expensive tools. Before anyone mentions price, sometimes the expense is hidden in places like what system I would have to run, with what total cost of ownership, in order to use their stuff. There may have been some unknown opportunity costs to me, but I am blissfully unaware of these and have had plenty of other fun languages to use.
Hear hear.
I think it's fine to use MS stuffs for fun, hobby, side project, or even some consulting jobs (if money is good and the task is not that hard).
For me personally, I'm trying to move away from languages that requires heavy-weight tooling because I'm seeing a pattern where most people whom I consider to "know their stuff very well and can do great things" seem to come from Open Source background. They do stuff with C, *NIX, Python, Ruby, Perl, JavaScript, and various other small tools that do great things.
Just a personal observation nonetheless.
I think it's fine to use MS stuffs for fun, hobby, side project, or even some consulting jobs (if money is good and the task is not that hard).
For me personally, I'm trying to move away from languages that requires heavy-weight tooling because I'm seeing a pattern where most people whom I consider to "know their stuff very well and can do great things" seem to come from Open Source background. They do stuff with C, *NIX, Python, Ruby, Perl, JavaScript, and various other small tools that do great things.
Just a personal observation nonetheless.
You have got to be the first person I've ever heard say that MS products are ok for side projects, but that free stuff is better for business. In general, I would associate MS with "businessy" and open source with "fun".
That depends on what kind of business (or ways to make money) we're talking about here.
For example, there are many web startups and web consulting companies that use typical LAMP stack or "light-weight" Java stack (Spring -IoC,AOP,MVC-, Hibernate/iBatis, Ant/Mavent, Hudson, MySQL/PostgreSQL).
There are also other types of work that would require heavy help from the open source tools. One such example is embedded development. My friend works at Broadcom and he uses gcc, vim, ctags on day to day base. I'm sure companies that operate in hardware, system, and, network fields are also using open source tools heavily.
The Russian developer, who used to work at Goldman Sach and got caught sending his work to some server, used a mix of Erlang, C++, and various other tools as well so I'm guessing those big guns at Wall Streets are using open source tools for their HF trading systems.
Then there are your typical insurance companies, your typical hospitals, your typical small businesses, your typical banks, your typical grocery stores that would swear by Microsoft technology for their internal apps.
I'm not trying to say that Microsoft is not suitable for "serious businesses". I'm looking at the trend around me and it seems that Microsoft technology appears in places where people need something quick to be done and would never add major features, instead just bug fixes and small polish here and there.
For example, there are many web startups and web consulting companies that use typical LAMP stack or "light-weight" Java stack (Spring -IoC,AOP,MVC-, Hibernate/iBatis, Ant/Mavent, Hudson, MySQL/PostgreSQL).
There are also other types of work that would require heavy help from the open source tools. One such example is embedded development. My friend works at Broadcom and he uses gcc, vim, ctags on day to day base. I'm sure companies that operate in hardware, system, and, network fields are also using open source tools heavily.
The Russian developer, who used to work at Goldman Sach and got caught sending his work to some server, used a mix of Erlang, C++, and various other tools as well so I'm guessing those big guns at Wall Streets are using open source tools for their HF trading systems.
Then there are your typical insurance companies, your typical hospitals, your typical small businesses, your typical banks, your typical grocery stores that would swear by Microsoft technology for their internal apps.
I'm not trying to say that Microsoft is not suitable for "serious businesses". I'm looking at the trend around me and it seems that Microsoft technology appears in places where people need something quick to be done and would never add major features, instead just bug fixes and small polish here and there.
I can appreciate some of these concerns - though the ability to run under mono ameliorates them for me. If you want a language aiming for a similar functional + oop position but don't want to touch Microsoft stuff then Scala might be worth taking a look. Thats assuming you don't extend your fears to Java Virtual Machines as well.
How does Clojure compare with these? It's time I learnt a functional language...
You can break functional languages down into two basic categories: Typed and Untyped. The typed ones derive from ML, and the untyped ones derive from Lisp.
Many of the 'killer features' of untyped functional languages have migrated their way into today's 'dynamic' languages like ruby, python, etc. You can use a REPL, you don't need to spend 15 minutes compiling, no static typing, etc. So in terms of 'new' things you'll learn from Clojure, you have s-exps and macros. This allows you to manipulate code as data, because the code is data.
The typed functional languages have an advanced type system, as the name indicates. In 'normal' languages, you have what I casually refer to as 'primitive types' Integers, Floats, Doubles, etc, and after that you're on your own. Typed functional languages have ADT's that allow you to model complicated systems via the types. Probably the standard example of a real-life use of this is that you can write code that will throw an error at compile time if you try to inadvertently try to add Feet and Meters. They also have pattern matching, which is pretty handy. Imagine a big if-elsif statement that will throw a compile time error if you handle bank transfers up to a million dollars, and transfers over two million dollars, but not ones that are between one and two-million dollars. You can think of both of these features as typedefs and case/if-elsif statements on crack. That's the kind of stuff you'll get from F#.
I personally think the typed functional languages have much more compelling features in this day and age. Like I said above, the features that I really dug in Lisps have made their way into most dynamic languages, and don't seem as mind-blowing as they once did. But if you really want to go crazy, it's probably worth learning at least one language from each functional sub-family at some point in time.
Many of the 'killer features' of untyped functional languages have migrated their way into today's 'dynamic' languages like ruby, python, etc. You can use a REPL, you don't need to spend 15 minutes compiling, no static typing, etc. So in terms of 'new' things you'll learn from Clojure, you have s-exps and macros. This allows you to manipulate code as data, because the code is data.
The typed functional languages have an advanced type system, as the name indicates. In 'normal' languages, you have what I casually refer to as 'primitive types' Integers, Floats, Doubles, etc, and after that you're on your own. Typed functional languages have ADT's that allow you to model complicated systems via the types. Probably the standard example of a real-life use of this is that you can write code that will throw an error at compile time if you try to inadvertently try to add Feet and Meters. They also have pattern matching, which is pretty handy. Imagine a big if-elsif statement that will throw a compile time error if you handle bank transfers up to a million dollars, and transfers over two million dollars, but not ones that are between one and two-million dollars. You can think of both of these features as typedefs and case/if-elsif statements on crack. That's the kind of stuff you'll get from F#.
I personally think the typed functional languages have much more compelling features in this day and age. Like I said above, the features that I really dug in Lisps have made their way into most dynamic languages, and don't seem as mind-blowing as they once did. But if you really want to go crazy, it's probably worth learning at least one language from each functional sub-family at some point in time.
Ah, that's very interesting, thank you. I assume Scala is typed, then?
Scala's...
weird...
Scala would fall under the typed functional family. It has it's own version of ADT's and it has pattern matching. But in a lot of ways it's a hybrid OO/Functional language. A lot of the decisions in the language's design were made so that it'd play nice with Java-proper.
My initial superficial feelings about it was that it combined the worst of both worlds. It had all the popularity of a functional language, and all the nice syntax of Java.
Since then I've started writing a Droid app to get a real feel for the language, and all my superficial feelings were wrong. I like the language a lot. But it's still a little weird compared to all the other typed functional languages. You can't see as much ML in Scala as you can in F# or even Haskell.
Still, if you're stuck (or prefer) the JVM, then that's probably the typed functional language you'd want to try. That's the reason I'm using it for Droid development.
weird...
Scala would fall under the typed functional family. It has it's own version of ADT's and it has pattern matching. But in a lot of ways it's a hybrid OO/Functional language. A lot of the decisions in the language's design were made so that it'd play nice with Java-proper.
My initial superficial feelings about it was that it combined the worst of both worlds. It had all the popularity of a functional language, and all the nice syntax of Java.
Since then I've started writing a Droid app to get a real feel for the language, and all my superficial feelings were wrong. I like the language a lot. But it's still a little weird compared to all the other typed functional languages. You can't see as much ML in Scala as you can in F# or even Haskell.
Still, if you're stuck (or prefer) the JVM, then that's probably the typed functional language you'd want to try. That's the reason I'm using it for Droid development.
Thanks for that. The apps run on Android? I thought Dalvik only supported Java... Or is there a Scala -> Java compiler (or Java bytecode -> Dalvik bytecode, for that matter)?
dex is an executable that comes with the SDK and converts files from .class (Java bytecode) to .dex (Dalvik bytecode)
For a while there was a bug in the Dalvik VM that wouldn't let you run some Scala methods but I made a patch to fix that problem. I think it's in all releases after Android 1.6.
For a while there was a bug in the Dalvik VM that wouldn't let you run some Scala methods but I made a patch to fix that problem. I think it's in all releases after Android 1.6.
Ah, I see, fantastic. I thought it compiled the code into .dex. I imagine it might run Jython as well, then?
EDIT: Apparently Jython uses on-the-fly bytecode generation on account of being dynamic, so it can't run.
EDIT: Apparently Jython uses on-the-fly bytecode generation on account of being dynamic, so it can't run.
The Android Scripting project adds support for Python, Perl, JRuby, Lua, BeanShell, JavaScript and Tcl:
http://code.google.com/p/android-scripting/
http://code.google.com/p/android-scripting/
http://www.mirah.org/ (formerly Duby) is another compelling candidate for Android development for those that like Ruby. Compiles to Java byte-code :)
That's very handy, thank you!
If by typed I assume you mean "statically typed", then yes.
F# is free. http://www.microsoft.com/downloads/en/details.aspx?FamilyID=... . You only pay if you need the fancy "enterprise" features.
For SaaS, using MS technologies requires careful cost analysis. Putting MS server software on your hardware will raise the price per system by many hundreds of dollars, double that if you are also using MS SQL Server. Even if F# is free, building a platform that relies on F# could potentially be very expensive.
I didn't see a Visual F# Express there - does Visual C# Express include IntelliSense for F#?
Download the VS 2010 redistributable shell and then the F# MSI.
See also http://fsxplat.codeplex.com, which is a project with the aim to make F# a better tool for cross-platform development. I'm currently working on an (open source) MonoDevelop integration for F# (sources are already there), but an announcement is yet to come...
Intellisense and debugging on one of the nicest IDEs around FOR FREE. Say what you want but Microsoft looks after developers.
> For many years I've made it a point to studiously ignore languages that come out of Microsoft, having been burned too many times by their constantly shifting and sometimes suddenly-expensive tools.
Examples?
Examples?
At Atalasoft, we decided to make F# an allowed language for development (in addition to C/C++, C++/CLI, and C#). We make imaging toolkits for .NET. There aren't many downsides compared to C# -- it's totally interoperable with our code, can be used to implement OO interfaces quite well, and it has some nice advantages (terser syntax, inlining, asynch blocks, etc). The main downside is in dealing with anything that uses Visual Studio Design support.
We don't use it for everything, but it has its place.
We don't use it for everything, but it has its place.
I just don't see a big enough advantage compared to its parent, Ocaml. Partly because I wouldn't count Visual Studio and .net on the "pro" side. Ocaml is basically the same language, you don't have a big methodology mismatch when using libraries, it produces smaller executables that are quite fast, its runtime has some advantages if I remember correctly. (And there's the evangelist problem, but let's not get into that again.)
I doubt they're hoping to get people to convert from Ocaml to F#. But .Net has a huge dev base, and this is a great opportunity for functional programming to go (more) mainstream.
F# is a somewhat simpler language than OCaml. Plus, it has decent concurrency support (which is a bit of an issue for OCaml if I recall correctly).
Does F# have functor support by now? Because if that's what's meant by simpler, I'd rather have a bit of complexity. If I program in a functional, symbolic manner, I also don't want to kowtow to the runtime that just wasn't made for such an use (If I recall correctly, Yaron Minsky of Jane Street complained somewhat about F#'s allocation rate in this respect).
Concurrency is an issue that I hope the Ocaml developers will address a bit more, though.
Concurrency is an issue that I hope the Ocaml developers will address a bit more, though.
No functor support. Questionable if it would fit idiomatically with .net framework culture but not something you miss.
In order of wish list to F#:
In order of wish list to F#:
- ability to create a structure isomorphic to GADTS
- further enhancements to metaprogramming and how it does quasi quotation stuff
- Support for Higher Kinds
I don't know that .net is necessarily not tuned for that use-case. Generally, a generational garbage collector like .net's handles short-lived immutable objects better than it does longer-lived mutable objects. It can allocate and deallocate objects very quickly as long as they're collected in the first generation. I'm speaking mostly in generalities though. I'd be curious to know if this isn't the case on .net.
Multicore is one obvious huge advantage over OCaml. Associating basic functions (like comparison) with types is a major advantage. Equality types are a huge advantage. Overloading and associated benefits like support for the full range of primitive types is another important advantage.
Also, F# executables tend to be orders of magnitude smaller than OCaml executables but, of course, the F# ones need a CLR installed to run them.
Also, F# executables tend to be orders of magnitude smaller than OCaml executables but, of course, the F# ones need a CLR installed to run them.
"its runtime has some advantages"
Could someone shed some light on this?
Could someone shed some light on this?
I've used F# at work.
It does have a sort-of REPL, you don't have to put one line functions inside a dummy class, and the async monad and queues are pretty handy.
It doesn't benefit from adding yet another set of collection types to the .NET API (which already has two semi-competing sets) but that is unfortunately beneficial, partly due to the next point.
The balkanisation between the .NET typesystem (class at a time, overloading ok) and the ML typesystem (sequential and no overloading) is a constant source of irritation. How to make a short name alias to the System.Console.WriteLine variadic function?
It's REPL unfortunately doesn't tie into the otherwise impressive VS intellisense and is a pain to attach the debugger to.
It hasn't proper closures (you cannot mutate variables you close over).
It's not a coherent platform, but a mishmash.
It does have a sort-of REPL, you don't have to put one line functions inside a dummy class, and the async monad and queues are pretty handy.
It doesn't benefit from adding yet another set of collection types to the .NET API (which already has two semi-competing sets) but that is unfortunately beneficial, partly due to the next point.
The balkanisation between the .NET typesystem (class at a time, overloading ok) and the ML typesystem (sequential and no overloading) is a constant source of irritation. How to make a short name alias to the System.Console.WriteLine variadic function?
It's REPL unfortunately doesn't tie into the otherwise impressive VS intellisense and is a pain to attach the debugger to.
It hasn't proper closures (you cannot mutate variables you close over).
It's not a coherent platform, but a mishmash.
Check this Ocaml talk by Yaron Minsky from Jane Street Capital:
http://news.ycombinator.com/item?id=1533275
He said, that unlike Ocaml, in F# you still can get Null-pointer exceptions, since it's based on .NET
He said, that unlike Ocaml, in F# you still can get Null-pointer exceptions, since it's based on .NET
That's partly correct. The danger comes not because F# is "based on" .NET but because it can call into other .NET libraries. F# code by itself, including the F# libraries, won't create null references except in two very specific cases (see http://msdn.microsoft.com/en-us/library/dd233197.aspx). And F# types are non-nullable unless you ask for them to be nullable.
But if you call into non-F# libraries, including .NET framework libraries, then they can return null references. And if your F# code tries to use a null reference obtained in this way OO-style (e.g. making an instance method call through the reference), then that will indeed cause a NullReferenceException.
Obviously, it's easy to wrap 'dangerous' calls to return option values (F#'s equivalent of Haskell Maybe) instead of nulls -- it's a judgment call as to whether it's worth it for any given API.
But if you call into non-F# libraries, including .NET framework libraries, then they can return null references. And if your F# code tries to use a null reference obtained in this way OO-style (e.g. making an instance method call through the reference), then that will indeed cause a NullReferenceException.
Obviously, it's easy to wrap 'dangerous' calls to return option values (F#'s equivalent of Haskell Maybe) instead of nulls -- it's a judgment call as to whether it's worth it for any given API.
(Disclaimer: f# neophyte, reading Chris Smith's excellent Oreilly book). I think the Option type is used similarly in F# to the Option/Maybe's in scala and haskell:
http://msdn.microsoft.com/en-us/library/dd233245.aspx
http://msdn.microsoft.com/en-us/library/dd233245.aspx
I used it for a while a few years ago. Like O'Caml or Haskel , F# is a language that forces you think through your problem up front. For example you must get your types exactly right before the program compiles. In return, you get fewer runtime errors, e.g. fewer null pointer exceptions.
I stopped using it when I changed jobs and left the Windows platform.
I don't really miss F#. It was fun to learn and use, but wasn't helping me write better programs quicker than C# or Python.
I stopped using it when I changed jobs and left the Windows platform.
I don't really miss F#. It was fun to learn and use, but wasn't helping me write better programs quicker than C# or Python.
I've been enjoying using it for both some personal and commercial projects. Points I've noted myself that aren't really discussed so much in the usual analysis, or maybe they're the 'small print':
1. Active Patterns are incredibly useful. Active Patterns are the f# equivalent of 'View Patterns' in Haskell. In other words they allow you write a function that converts something into a pattern matchable form. The first example I saw of this in Haskell was the ability to write a function of the form:
dec (n + 1) = n
which performs the same function as:
dec n = n - 1
Whilst that 'cool' I didn't really see the applicability. Now you're in the f# world and trying to interact with .net libraries its suddenly amazingly powerful! Suppose you have a DOM api or something like that, that the idiomatic functional approach would involve heavy pattern matching. Hey presto - one simple function and you've wrapped up an imperative .net library and you can think of it like a discriminated union.
2. Multiple collections libraries are annoying. There's some functionally oriented stuff in the f# libraries, but sometimes its a pain to get it to interact with existing c# code - you might need to do some conversions. The Seq module works over sequences - which are instances of IEnumerable - but you find yourself looking at the LINQ extension methods, and the legacy c# functions and then the f# ones and thinking 'its one platform - why are there 4 ways of doing something?'
3. The f# compiler takes a while to generate code under Mono. I've not tried mono 2.8 yet, but as of 2.6 it takes a significant amount of time to compile projects. If you're compiling code in order to try and get a few errors, a common thing to do if you're used to using your compiler to find bugs in your code, then this becomes a bit of a productivity drag.
4. Intellisense is still useful for functional programmers. I've noted a propensity among advocates of self-described expressive languages to claim that an IDE is a crutch for weaker programmers, or perhaps produce some other ill conceived but dismissive response towards IDEs. In the past I've considered the notion that the support something like Eclipse or IDEA gives to Java programmers or Visual Studio gives to C# is something unnecessary in the functional world. My mind on this matter has been changed by two things - one being the Visual Studio support for f#. Its not as good as c#, but its at a pretty young stage and is already highly useful. I feel a lot more productive in visual studio than vim for example. The other aspect was my efforts in teaching beginners to program haskell about a year ago. I was expecting a lot of people to get stuck on Monads and combinators etc. What I didn't expect was them to become confused on basic programming issues - things an IDE would help them find solutions to more easily in a language like Java. So I'm inclined to think from these experiences that IDEs are useful, even in a succint language like f# and more importantly both to beginners and experts alike. (Assuming I can consider myself an expert.) There's already a tool that provides the intellisense support in an out-of-ide environment, and I hope that it will mature soon enough that I'll be able to use it within vim.
I have a few more minor points - but I think thats all of interest for now.
1. Active Patterns are incredibly useful. Active Patterns are the f# equivalent of 'View Patterns' in Haskell. In other words they allow you write a function that converts something into a pattern matchable form. The first example I saw of this in Haskell was the ability to write a function of the form:
dec (n + 1) = n
which performs the same function as:
dec n = n - 1
Whilst that 'cool' I didn't really see the applicability. Now you're in the f# world and trying to interact with .net libraries its suddenly amazingly powerful! Suppose you have a DOM api or something like that, that the idiomatic functional approach would involve heavy pattern matching. Hey presto - one simple function and you've wrapped up an imperative .net library and you can think of it like a discriminated union.
2. Multiple collections libraries are annoying. There's some functionally oriented stuff in the f# libraries, but sometimes its a pain to get it to interact with existing c# code - you might need to do some conversions. The Seq module works over sequences - which are instances of IEnumerable - but you find yourself looking at the LINQ extension methods, and the legacy c# functions and then the f# ones and thinking 'its one platform - why are there 4 ways of doing something?'
3. The f# compiler takes a while to generate code under Mono. I've not tried mono 2.8 yet, but as of 2.6 it takes a significant amount of time to compile projects. If you're compiling code in order to try and get a few errors, a common thing to do if you're used to using your compiler to find bugs in your code, then this becomes a bit of a productivity drag.
4. Intellisense is still useful for functional programmers. I've noted a propensity among advocates of self-described expressive languages to claim that an IDE is a crutch for weaker programmers, or perhaps produce some other ill conceived but dismissive response towards IDEs. In the past I've considered the notion that the support something like Eclipse or IDEA gives to Java programmers or Visual Studio gives to C# is something unnecessary in the functional world. My mind on this matter has been changed by two things - one being the Visual Studio support for f#. Its not as good as c#, but its at a pretty young stage and is already highly useful. I feel a lot more productive in visual studio than vim for example. The other aspect was my efforts in teaching beginners to program haskell about a year ago. I was expecting a lot of people to get stuck on Monads and combinators etc. What I didn't expect was them to become confused on basic programming issues - things an IDE would help them find solutions to more easily in a language like Java. So I'm inclined to think from these experiences that IDEs are useful, even in a succint language like f# and more importantly both to beginners and experts alike. (Assuming I can consider myself an expert.) There's already a tool that provides the intellisense support in an out-of-ide environment, and I hope that it will mature soon enough that I'll be able to use it within vim.
I have a few more minor points - but I think thats all of interest for now.
Slight bit of pedantry (not to detract from the overall content of your post): dec (n + 1) is not a view pattern, it's an n+k pattern, and Haskellers have mostly decided that they were a bad idea. However, you've gotten the point of real view patterns (foo (someFunc -> x)) spot on: they encourage better data abstraction, which is helpful if you've got an imperative .net library that you want to interface with.
Thanks for the correction. I admit I've not fiddled with Haskell's equivalents to Active Patterns to any great extent - as since I mention in the original comment I didn't hugely see the motivation in that context. I really only mentioned them since I assumed more people would be familiar with haskell.
Haskell doesn't have active patterns. Although they were originally proposed for Haskell by Wadler, they don't make so much sense with non-strict evaluation because you can just write code to compute the result and match over it safe in the knowledge that it will be computed on-demand only as far as required.
From what I have seen, it seems that MS is pushing this as a way to parallelize a section of your application. Meaning that you would use c# for most of the app and write a performance critical/parallel section in F# to avoid using locks/ critical sections.
Maybe I'm seeing things wrong, but it seems that MS is not looking to make F# as mainstream as c#.
Maybe I'm seeing things wrong, but it seems that MS is not looking to make F# as mainstream as c#.
F# is a bit weird to folks who are used to C# or VB, which is what PG was referring to with the "Blub" paradox. F# is different enough that the majority of .NET programmers I meet, or work with, have no frame of reference to understand F# with. The only ones I know who code outside the office are trying to get rich with iPhone or Android apps.
I'm a "Blub" programmer, and yes, I really don't have any frame of reference to understand F#.
And I'll probably try my hand at Ruby or Python before F# or Lisp... I've read many posts and articles about how at least trying Lisp will make me a better programmer but I still don't want to take the plunge.
I'm not a hardcore programmer (heck I'm starting an MBA next year (1) ), and pretty pragmatic - if my tools help me build what I want, great. I don't object to learning new tools but there's a significant time cost to that, so I have to prioritize
(1) I've also read a lot of advice about why I don't want or need an MBA but I'm trying to look at it like an entry point into the business world and a networking and career advancement opportunity. I like solving problems outside of programming (making better processes and such). I'm not a salesman or marketer, but I am interested in business.
And I'll probably try my hand at Ruby or Python before F# or Lisp... I've read many posts and articles about how at least trying Lisp will make me a better programmer but I still don't want to take the plunge.
I'm not a hardcore programmer (heck I'm starting an MBA next year (1) ), and pretty pragmatic - if my tools help me build what I want, great. I don't object to learning new tools but there's a significant time cost to that, so I have to prioritize
(1) I've also read a lot of advice about why I don't want or need an MBA but I'm trying to look at it like an entry point into the business world and a networking and career advancement opportunity. I like solving problems outside of programming (making better processes and such). I'm not a salesman or marketer, but I am interested in business.
I had no idea what it was. For those similarly unaware: http://research.microsoft.com/en-us/um/cambridge/projects/fs...
The big thing is that F# has graduated from MS Research and is now available as Visual F#. This is important as it could make functional programming more mainstream (or at least into the hands of more people).
http://fsharp.net is the new official site post-graduation from MS Research, I believe. For a nice introduction to the language, the Wikibook at http://en.wikibooks.org/wiki/F_Sharp_Programming is quite good.
As someone else commented: The MS research link is kind of misleading (that's the origin, but not the place you go to for F# now).
I'd suggest to go directly to the site http://www.fsharp.net/ - which, granted, is linked on the MS research site as well. I highly suggest looking at http://cs.hubfs.net/ as well.
I'd suggest to go directly to the site http://www.fsharp.net/ - which, granted, is linked on the MS research site as well. I highly suggest looking at http://cs.hubfs.net/ as well.
I'm curious as to what libraries are available for linear algebra and numerical computation (free / open source ones) and how they compare to e.g. Numpy, mpj or colt on java, etc?
I love it. Pair it with a few C# projects to get all the LINQ-TO-SQL goodness and ASP.NET MVC + nhaml and you've got yourself a beautiful way to develop for the .NET platform.
Here's F# on OSX: http://blog.mbharrington.org/2010/10/27/fsharp-on-osx/
I love it!
So what do you think?