3 ms·

Real World F#

59 points by rlmw 16y ago

primodemus 16y ago
F#'s type system supports units of measure. It looks really nice: http://blogs.msdn.com/b/andrewkennedy/archive/2008/08/29/units-of-measure-in-f-part-one-introducing-units.aspx http://blogs.msdn.com/b/andrewkennedy/archive/2008/08/29/uni...
DanielBMarkham 16y ago
Nice mention of unit testing, lack of bugs, and units of measure. Can't put down the exploratory nature, either. The only nit I have is the way MS keeps wanting to pitch F#. I know the spin is to use F# for math-y type things, but I really don't know why you just wouldn't use it for everything. I mean, underlying it is the CLR and the OS. It's not like somehow if you know F# somehow you need to also switch to C# to make a window. In fact, if you keep it functional, many times your functions can work their way into what you previously thought of as framework code, simplifying the entire kit and caboodle. I find that every time I switch languages, start declaring mutable values, or framing up reusable classes -- I end up severely limiting my options for refactoring later on. And functional code is nothing if not hugely refactorable. Simply because you can switch languages doesn't mean you have to, or even that it's a good idea to do so.
- flatline 16y ago
  Yep, CodeDom and a little better VS integration and I would ditch C# for most purposes in favor of F#. I really like the language and wrote a couple small projects in it before the 2010 release, but since then I haven't found myself making an F# library in an existing C# project. On what criteria should I base such a decision, given that I'm not doing scientific computing, and have to inter-operate with existing mutable data structures, etc.? I wouldn't put an arbitrary VB library into a C# project either for that matter.
- jules 16y ago
  It seems that the F# team is always careful not to step on C#'s toes in interviews & marketing.
- Aaronontheweb 16y ago
  I know that the Azure team is playing up F#'s role in developing worker roles for HPC and that F# is designed to work in concert with Dryad, which is the .NET MapReduce engine developed by MSR, see http://weblogs.asp.net/podwysocki/archive/2009/03/03/exploring-mapreduce-with-f.aspx http://weblogs.asp.net/podwysocki/archive/2009/03/03/explori... I'd argue that F# is marketed the way it is because it doesn't have a business group with a marketing budget yet or a real evangelism team - it's really the guys at Microsoft Research who are driving its adoption, and they happen to be scientists and mathematicians. There's a lot of room for trailblazers who want to show off how to use it more everyday scenarios and not just math / science scenarios.
blacksmythe 16y ago
When you solve Project Euler problems you can see previous solutions. The F# solutions are astoundingly concise. I regret I have not yet learned F#, but studying the Project Euler solutions would be a good approach.
- rlmw 16y ago
  ML derivative functional programming languages are frequently ideal for project Euler in general - Haskell, f#, ocaml etc.

59 points by rlmw 16y ago

F#'s type system supports units of measure. It looks really nice: http://blogs.msdn.com/b/andrewkennedy/archive/2008/08/29/units-of-measure-in-f-part-one-introducing-units.aspx http://blogs.msdn.com/b/andrewkennedy/archive/2008/08/29/uni...

DanielBMarkham 16y ago

Nice mention of unit testing, lack of bugs, and units of measure. Can't put down the exploratory nature, either. The only nit I have is the way MS keeps wanting to pitch F#. I know the spin is to use F# for math-y type things, but I really don't know why you just wouldn't use it for everything. I mean, underlying it is the CLR and the OS. It's not like somehow if you know F# somehow you need to also switch to C# to make a window. In fact, if you keep it functional, many times your functions can work their way into what you previously thought of as framework code, simplifying the entire kit and caboodle. I find that every time I switch languages, start declaring mutable values, or framing up reusable classes -- I end up severely limiting my options for refactoring later on. And functional code is nothing if not hugely refactorable. Simply because you can switch languages doesn't mean you have to, or even that it's a good idea to do so.

flatline 16y ago
Yep, CodeDom and a little better VS integration and I would ditch C# for most purposes in favor of F#. I really like the language and wrote a couple small projects in it before the 2010 release, but since then I haven't found myself making an F# library in an existing C# project. On what criteria should I base such a decision, given that I'm not doing scientific computing, and have to inter-operate with existing mutable data structures, etc.? I wouldn't put an arbitrary VB library into a C# project either for that matter.
jules 16y ago
It seems that the F# team is always careful not to step on C#'s toes in interviews & marketing.
Aaronontheweb 16y ago
I know that the Azure team is playing up F#'s role in developing worker roles for HPC and that F# is designed to work in concert with Dryad, which is the .NET MapReduce engine developed by MSR, see http://weblogs.asp.net/podwysocki/archive/2009/03/03/exploring-mapreduce-with-f.aspx http://weblogs.asp.net/podwysocki/archive/2009/03/03/explori... I'd argue that F# is marketed the way it is because it doesn't have a business group with a marketing budget yet or a real evangelism team - it's really the guys at Microsoft Research who are driving its adoption, and they happen to be scientists and mathematicians. There's a lot of room for trailblazers who want to show off how to use it more everyday scenarios and not just math / science scenarios.

blacksmythe 16y ago

When you solve Project Euler problems you can see previous solutions. The F# solutions are astoundingly concise. I regret I have not yet learned F#, but studying the Project Euler solutions would be a good approach.

rlmw 16y ago
ML derivative functional programming languages are frequently ideal for project Euler in general - Haskell, f#, ocaml etc.