Tuesday, October 30, 2007

F# is so Passé

Lately I've been trying to juggle learning a mix of technology. WPF, .net 3.5 (linq), maths, F#... Sometimes I feel like I have Internet Multitasking Syndrome.

Although Internet Multitasking Syndrome is not a known medical disorder (I just made it up five minutes ago), it is not uncommon for people to become so immersed in their online activities that their cognitive abilities wane.

After hours starring at a screen, flipping between web pages and information outlets, people can develop a feeling of anxiety, stress and a decrease in mental performance, said John Suler, author of The Psychology of Cyberspace.

"There are limits to how much information one person can process," he continued.


I started learning about a little known language called F# a couple of months ago, where I read most of the Foundations of F# book over a rather intense week.

Since then I've dropped the ball... there's just too much to learn within our software field.

I'm keen to get back into it, as F#'s functional principles are very appealing to me. There's a sense of power and elitism playing with such a language. It's close to it's mathematical roots, and has the potential to create highly concurrent systems.

These things are addictive for software engineers. Power and elitism - it's why C/C++ are so popular and why VB programmers get no respect.


Now that F# is an official MS language, it's becoming quite popular. While this is fantastic for the language - a small selfish part of me wants to keep it for myself. I don't want it to become 'common' and spoilt by countless bad programmers writing spaghetti code.

Unfortunately this also includes me - so to avoid becoming an Italian Chef, I'm planning to read Structure and Interpretation of Computer Programs during my holidays. I've heard this is a classic book covering functional programming (in scheme).

Wish me luck!

4 comments:

Nick said...

Funny coincidence - last night I bought "The Little Schemer"... :)

I'm going to learn Scheme purely as a mental exercise so that my brain can parse the Haskell compiler's error messages!

I've heard a lot of assertions about F# encouraging concurrency - is there any method by which the F# compiler can verify that a function is side-effect free, the way that the Haskell compiler can?

Without that kind of guarantee for the compiler/runtime, as far as I know it is very hard to improve performance on multiple cores without explicit concurrency in the program. Any info? I am wondering whether there is a subset of MSIL that can guarantee the absence of side-effects....???

Anonymous said...

Reading SICP is absolutely enlightening! Seriously, the best book ever.

Luke Marshall said...

Excellent! I'm really looking forward to reading it.

Nick:

Very funny! Maybe we can get together some time and do some scheme'ing. :)

The compiler enforces immutable code in F#. Side-effects are explict. Not sure about a guarantee though - but would be useful for library development in F#.

I know just recently they've been playing with erlang style monads for async concurrency. Very exciting to see that on the .net framework.

Erlang is famous for it's concurrency, but infamous for it's IO - so if F# can get the balance right, it will be a very powerful language.

Slightly off topic: I found it neat that the guy who worked on Linq also worked on Haskell 98.

Nick said...

Thanks for the insights. Guess I should start to consider F# as more than just OCaml.NET :) - keen to keep up with your experiences!