Wednesday, March 6, 2013

Reasons to use F# from Brian Mc Namara and Eriawan

Hi there!

I found very precious blog entry of Brian Mc Namara, a team member of F# team at Microsoft.

His blog was originally located at Windows Live Spaces and then transferred to Wordpress.

Now the URL of his Wordpress blog is: http://lorgonblog.wordpress.com/

Brian’s blog is very inspirational, and it’s one of my source of knowledge about F#. One of my favorite entry is “Nine reasons to use F#”.

Here are his reasons:

  1. Units of measure.  If you’re working in domains that use numbers to represent physical quantities like kilograms, meters, and seconds (or pixels versus inches, or dollars versus euros, or …) you can use the F# type system to ensure that the dimensional analysis works out.  Nearly everyone who uses this feature has a “wow” experience where the compiler finds an unexpected bug (it happened for me when working on the 2008 ICFP programming contest).  In certain domains, this kind of static typechecking is a really killer feature. You can learn more about F# units here, here, or here.
  2. Functional programming with .NET.  If you need to author a component that’s especially amenable to functional programming techniques (like game AIs, statistical modeling, symbolic computing, …), and you need to interoperate with SQL, Excel, or XBox, or run in the browser with Silverlight, or run in the cloud with Azure, or do WCF, WPF, or WinForms, or easily talk to your existing C#/VB/C++/COM code, then F# is where it’s at. The .NET platform has great reach and integration with a variety of technologies, and F# extends the platform by providing a way to do first-class functional programming and get seamless integration with all these technologies.
  3. Explorative programming with the REPL.  The F# Interactive tool window makes it easy to execute small bits of code on the fly.  When working with large data sets or mathematical models, this makes it easy to explore the data, play “what-if” games, and directly interact with the data/models in a very “live” way.  When coupled with libraries for data visualization, this enables some really cool stuff.
  4. Asynchronous and parallel programming.  I’ve blogged recently about F#’s unique programming model for writing non-blocking code for asynchronous I/O.  The async programming model also extends to parallelizing CPU intensive work, and F#’s library also makes is straightforward to react to events, use lightweight agents, or run code on the GPU.  (There’s actually tons of content on the web on these topics; in the previous sentence, I just sprinkled in some links to Don’s blog.)  Multi-core is here, and F#’s language constructs and libraries are very well-suited to parallel programming (not to mention some intrinsic advantages of the functional programming style).
  5. Embedded domain-specific languages (EDSLs).  A variety of F# features (including ability to define new operators, currying and function application syntax, quotations, type inference and overall lightweight syntax) make F# a good language for creating EDSLs.  Some examples include FsUnit for unit testing, FAKE for authoring build scripts, FParsec for parsing, and WebSharper for web applications.
  6. Scripting.  Every so often, I need to write a script, but I use perl and batch files infrequently enough that I’m always forgetting the syntax of those.  Nowadays I use F# for a number of scripting tasks, both in the sense of “FSI is the new perl” and for tiny tasks (e.g. if I can’t recall the ascii value of character ‘A’, I just type “int ‘A’;;” into the F# Interactive window).  I know at least a couple folks using .fsx files where previously they would have used batch files or perl scripts.  For me, F# is the first “software engineering” language I know that’s also a good “scripting language”.
  7. A practical language for academia.  Back when I was a college undergrad, the first real programming language I learned in school was Pascal.  (Yes, this was back before C#, or even Java; I’m an old man.)  In university, it seems there’s been a tension between teaching more ‘pure’ and ‘CS-y’ languages and teaching more pragmatic languages (e.g. that you can likely use for gainful employment when you get out of school).  This is still a topic of much debate, but I think we’re in a much better state now, with languages including Java, C#, Scala, Python, and F#, then we were a decade or two ago; there are now a variety of languages that are decent both as “good introductory CS languages” and “useful real-world languages”.
  8. Expand your mind and career.  I think there are a fair number of folks that use C# or VB in their day job, who would like to learn more about functional programming, but find that diving head-first into Haskell is too difficult or time-consuming.  F# provides an avenue to go more gently into the waters of functional programming, leveraging one’s existing .NET and Visual Studio familiarity.  A lot of folks who are just trying F# as a hobby have reported that they’ve learned new strategies/algorithms that they can apply back in their day job (e.g. using C#), hurray.
  9. Fun!  I’m constantly hearing from people how much they enjoy using F#.  Who doesn’t love being able to get a job done and have fun doing it?

I also would like to have his reasons as mine. And I will add my own reasons:

  1. The most succinct programming language on .NET. Yes, anybody might argue F# is not the most succinct, but as far as I know no other programming languages on top of .NET has the succinctness of F#!
  2. Your code is less buggy thanks to the succinctness of F#.
  3. Train you to have functional mindset while not abandoning you OOP and imperative mindset. This is important, as F# is still compatible and interop well with C# and VB.

Any other reasons to add? I also welcome suggestions