4 ms·

F# 3.0 Developer Preview Now Available

76 points by icey 15y ago

lmkg 15y ago
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#).
- cageface 15y ago
  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.
  - politician 15y ago
    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...
    - jtolle 15y ago
      Relevant link: http://www.johndcook.com/blog/2009/03/23/functional-in-the-small-oo-in-the-large/ http://www.johndcook.com/blog/2009/03/23/functional-in-the-s...
- hamidpalo 15y ago
  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.
  - Fizzer 15y ago
    Out of curiosity, why would you not recommend F# for UI?
    - kia 15y ago
      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.
skeletonjelly 15y ago
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.
typicaljoe 15y ago
I find F# very tempting as a gateway into .NET. Anyone used it with MVC?
- balakk 15y ago
  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.
- nephesh 15y ago
  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.)
satoimo 15y ago
Does this mean Visual Studio is going to run discovery queries in order to provide auto complete?
- mammo 15y ago
  From the linked article: "The type provider connects to the database automatically and uses this for IntelliSense and type information".
gaius 15y ago
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/ http://www.dse.nl/~dario/projects/pgoctut/
thomasz 15y ago
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.

76 points by icey 15y ago

lmkg 15y ago

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#).

cageface 15y ago
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.
- politician 15y ago
  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...
  - jtolle 15y ago
    Relevant link: http://www.johndcook.com/blog/2009/03/23/functional-in-the-small-oo-in-the-large/ http://www.johndcook.com/blog/2009/03/23/functional-in-the-s...
hamidpalo 15y ago
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.
- Fizzer 15y ago
  Out of curiosity, why would you not recommend F# for UI?
  - kia 15y ago
    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.

skeletonjelly 15y ago

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.

typicaljoe 15y ago

I find F# very tempting as a gateway into .NET. Anyone used it with MVC?

balakk 15y ago
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.
nephesh 15y ago
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.)

satoimo 15y ago

Does this mean Visual Studio is going to run discovery queries in order to provide auto complete?

mammo 15y ago
From the linked article: "The type provider connects to the database automatically and uses this for IntelliSense and type information".

gaius 15y ago

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/ http://www.dse.nl/~dario/projects/pgoctut/

thomasz 15y ago

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.