Looking at the new features, I get the distinct impression that the F# team has a clear vision of what work their language is suited for. It's meant to process data. These changes let more of your data pipeline happen within F#, extending up to, or even into, the data providers.
I really think F# benefits from being part of .NET instead of a stand-alone language. C# is probably better for designing a system, where you have a bunch of components swimming around talking to each other and maintaining state and dealing with the outside world and whatnot. F# is better for designing a process that takes input and produces output. That F# process can then be part of a C# system. That lets the F# team not have to worry so much about the system-y stuff, and design a tighter, more-focused language. (Ditto C#--from one point of view, .NET allows F# to be a DSL for C#).
I agree. F# and Scala are on the right track. Previous attempts to build total ecosystems around functional languages were too ambitious. In a mixed environment like this they can be allowed to shine doing the things they do best and programmers can ease their way into new paradigms with working code and familiar tools and libraries.
Unfortunately I think Scala is a little too indebted to Java/JVM and tries a little too hard to match the syntactic flexibility of Ruby. A Scala-- would be an easier sell, I think.
I read somewhere about using object-oriented languages for programming-in-the-large, and functional languages for programming-in-the-small. That is, using OO techniques for overall architecture and organization, and FP techniques to push data around. I should try to find a link...
I'd argue that F# is especially well-suited for a system with tons of components talking to each other. You have things like async workflows and message-passing built-in, along with the ability to do everything C# can do. I've been using F# to write such a system and I prefer it greatly to C#.
The only .NET thing I would recommend C# over F# for is UI.
I think it's because VS UI visual designer generates only C# code and doesn't work with other languages. Anyway you can build UI in C# and the rest in any .Net language you prefer.
Very cool that F# can now get type information right from the database, this capability has been available in OCaml for a while: http://www.dse.nl/~dario/projects/pgoctut/
Hm those are really interesting features, but I really hoped that they would remove some warts and improve interop (WCF, constructors for Record types, declaration of mutually dependant modules etc.) in this release.
Yup, I even wrote a framework to convert F# to javascript which allowed me to create a new (really powerful) validation provider for MVC. Sadly I haven't had a real world project that fit it well, so it's kind of gone by the wayside.
It's fairly straight forward to use with MVC, though it's less than ideal. You basically need to have a C# MVC project that referneces your F# projects (these would contain your controllers etc.)
It can be used with MVC, but the problem is MVC is still C# centric - as in the scaffolding bits that it generates are C# (or VB).
There's also the question of Razor supporting F#, which is not yet there. I remember somebody spiking some code for that, not sure if it's usable.
You can still write all your controllers in F#; but if your front-end is C#(razor), and if your data access is in L2S or EF, then F# feels like added baggage. Still could be useful in some occasions.
This looks great. Really need to find a project to be able to do more functional programming. OData, Linq, Type Provider...all looks like a nice set of tools to use.
I really think F# benefits from being part of .NET instead of a stand-alone language. C# is probably better for designing a system, where you have a bunch of components swimming around talking to each other and maintaining state and dealing with the outside world and whatnot. F# is better for designing a process that takes input and produces output. That F# process can then be part of a C# system. That lets the F# team not have to worry so much about the system-y stuff, and design a tighter, more-focused language. (Ditto C#--from one point of view, .NET allows F# to be a DSL for C#).