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/
F# 3.0 Developer Preview Now Available
11–16 of 16 posts
Re: F# 3.0 Developer Preview Now Available
#12Does this mean Visual Studio is going to run discovery queries in order to provide auto complete?
From the linked article: "The type provider connects to the database automatically and uses this for IntelliSense and type information".
Re: F# 3.0 Developer Preview Now Available
#13Hm 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.
Re: F# 3.0 Developer Preview Now Available
#14Looking 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 y…
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.
Re: F# 3.0 Developer Preview Now Available
#15Looking 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 y…
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.
Out of curiosity, why would you not recommend F# for UI?
Re: F# 3.0 Developer Preview Now Available
#16Earlier quoted context omitted.
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.
Out of curiosity, why would you not recommend F# for 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.