I don't understand this -- .NET-oriented podcasts and other people discussing the language have described F# this way as well. It would be a mistake to think F# is some kind of niche language like APL or Prolog just because it supports functional programming. They also bring up Lisp (which they all seem to spell as LISP), which shows that they have a hard time separating functional programing support from Lisp which is multi-paradigm.

My limited experience with it tells me F# would be a good general-purpose replacement for C#.

Ouch. I don't think the author knows the difference between procedural and functional.

I thought my download/install/say oooh/delete was cursory, but whoo, he really does kick the tyres, doesn't he?

"One of the first things I noticed is the use of the let keyword to assign variables"

No no no! They're not variables because they don't vary!

(and the shell doesn't work without compilation, it does on-the-fly compilation - or it wouldn't work. And you don't need to wait to find out about it's efficiency, it's been benchmarked loads, it runs on the .Net VM taking advantage of all that it provides. Pattern matching lends itself to data analysis? How vague and useless is that claim? And you don't need to force it on a client, it's a .net language, hello? It runs on the .net framework! "The previous sample demonstrates output via the printfn function" hello redundant commenting that tells you exactly what the code tells you! Gah!)

;_;

As for the linked article, it raises one question which had me thinking:

I also pondered why another .NET language (from Microsoft) is necessary. Are C#, VB.NET, and the available third-party languages not enough?

I'm not complaining about getting more options, but with .NET compiler implementations for a dozen languages, functional languages like Python included, this seems like a valid question.