6 ms·

11. F# F# is a mixture of C#, OCaml and Haskell. F# will be included in the next version of Visual Studio so it's no longer just a research language. Performan

11. F# F# is a mixture of C#, OCaml and Haskell. F# will be included in the next version of Visual Studio so it's no longer just a research language. Performance is similar to C# but coding in it is faster in my experience and above all a lot nicer if you like functional programming. Because it runs on the .NET VM or Mono VM it has good multicore support unlike OCaml. Haskell is more powerful as a language, but also has it's weak aspects. The main thing F# is missing imo in comparison to Haskell is type classes. And of course the Haskell community.

davidw 18y ago
Sounds interesting. How much is the community tied to Microsoft? "Runs on Mono" is ok, but if no one actually does, that's perhaps problematic for those who don't do MS.
- felixmar 18y ago
  Good cross-platform support is indeed very important for a programming language. The F# community is still small so there probably aren't many users on Linux and OS X. Don Syme (the creator of F#) has said that Microsoft will release the F# compiler under an open source license. I think that the future of the language will depend on it. If the F# compiler cannot be included in Linux distributions then the uptake from Linux and OS X users will be low. That would seriously hinder the (open source) community aspect of the language. I don't think that a young advanced language can survive without it.
  - gaius 18y ago
    You can on OSX right now do: $ sudo port install fsharp And get it, but the power of F# comes in part from its integration with .NET; OCaml has been around on OSX for years.
gaius 18y ago
If Microsoft can work out a sane licensing arrangement for compute farms/clusters/clouds (whatever we're calling them this week) of Win 2008 Server, then F# is a game-changer of a similar scale to Google's MapReduce. That's a big if tho'. Having said that, Windows is cheaper than RHEL already...
- iamelgringo 18y ago
  Have you looked at Microsoft's BizSpark program? Free enrollment for startups and all the licenses you can eat for 3 years.
- kragen 18y ago
  I think I can see how MapReduce could be argued to be a "game-changer" (although I'm not sure it's true), but why F#? If I understand correctly, it's basically OCaml on the CLR. So you get a Python-like brevity of code (and ease of programming? maybe it has better error messages than OCaml?} with C# performance and access to the CLR libraries. That sure sounds useful, but why is it a "game-changer"?
  - gaius 18y ago
    Because functional languages are a good choice for extracting as much parallelism as you can get from your algorithms.
    - kragen 18y ago
      No. CUDA yes. Cg yes. HLSL yes. Verilog yes. VHDL yes. C++ or Java with MapReduce yes. PHP and MySQL with memcached yes. Erlang yes — and it really is functional, inside each process, anyway — that is, the level where you aren't getting any parallelism. Octave or R, potentially, but not today, as far as I know. Mathematica yes, and it, too, is mostly functional. In theory, side effects are what make parallelism hard, and so languages whose semantics are side-effect-free (unlike F# or Mathematica or Erlang) should make it easy. So we all thought in 1980. Since then we spent 20 years or so trying to make that happen, and it basically didn't work. There are basically four kinds of parallelism within easy reach today. There's SIMD, like MMX, SSE, 3DNow, AltiVec, and the like; you'd think that data-parallel languages and libraries like Numpy and Octave would be all over this, but except for Mathematica, that doesn't seem to be happening. There's running imperative code on a bunch of tiny independent processors that share no data; AFAIK that's what the shader languages are doing. There's instruction-level parallelism on a superscalar processor, which largely benefits from things like contiguous arrays in memory, or maybe what Sun is doing with Niagara, where the processor pretends to be a bunch of tiny independent slow processors. And then there's splitting up your data across a shared-nothing cluster, which is how every high-traffic web site works, and that's what MapReduce makes simpler. Uh, and then there's designing your own hardware or programming FPGAs, which is what Verilog and VHDL are for. Languages like OCaml (I don't know anything about F# except that it's like OCaml, but for the CLR) have no special advantage for any of these scenarios. They don't even have the theoretical advantage that they have no side effects and therefore you can speculatively multithread them without breaking the language semantics. They do have the massive practical disadvantage, in most of the scenarios I described, of needing unpredictable amounts of memory, having massive libraries, and using pointers all over the place. Using pointers all over the place kills your locality of reference and your ILP. Having massive libraries and using unpredictable amounts of memory makes it impossible to run them inside your GPU and means they can't run on an FPGA (except by using external memory, like the awesome Reduceron). And nothing about the language semantics helps with SIMD either. So, sheesh, go read Alan Bawden's dissertation or whatever, but don't go around claiming that ML (or even Haskell) is going to magically make your algorithms parallel. We tried that. It didn't work. We're trying something else now.
snprbob86 18y ago
I'm learning F# now because it will be another weapon in my arsenal that I would be allowed to use here. My impression of it, so far, is: "Heh, kinda cool". It is basically the total compromise functional language, but in a good way. Immutability is optional, you can write imperative code whenever it makes sense, and there is a reasonably syntax for defining .NET object oriented constructs. It is very much a functional language that peacefully co-exists with the rest of the .NET ecosystem and that is a strength if you need it. Sure, all of that interop comes at a power and complexity cost, but it is surprisingly small.

davidw 18y ago

Sounds interesting. How much is the community tied to Microsoft? "Runs on Mono" is ok, but if no one actually does, that's perhaps problematic for those who don't do MS.

felixmar 18y ago
Good cross-platform support is indeed very important for a programming language. The F# community is still small so there probably aren't many users on Linux and OS X. Don Syme (the creator of F#) has said that Microsoft will release the F# compiler under an open source license. I think that the future of the language will depend on it. If the F# compiler cannot be included in Linux distributions then the uptake from Linux and OS X users will be low. That would seriously hinder the (open source) community aspect of the language. I don't think that a young advanced language can survive without it.
- gaius 18y ago
  You can on OSX right now do: $ sudo port install fsharp And get it, but the power of F# comes in part from its integration with .NET; OCaml has been around on OSX for years.

gaius 18y ago

If Microsoft can work out a sane licensing arrangement for compute farms/clusters/clouds (whatever we're calling them this week) of Win 2008 Server, then F# is a game-changer of a similar scale to Google's MapReduce. That's a big if tho'. Having said that, Windows is cheaper than RHEL already...

iamelgringo 18y ago
Have you looked at Microsoft's BizSpark program? Free enrollment for startups and all the licenses you can eat for 3 years.
kragen 18y ago
I think I can see how MapReduce could be argued to be a "game-changer" (although I'm not sure it's true), but why F#? If I understand correctly, it's basically OCaml on the CLR. So you get a Python-like brevity of code (and ease of programming? maybe it has better error messages than OCaml?} with C# performance and access to the CLR libraries. That sure sounds useful, but why is it a "game-changer"?
- gaius 18y ago
  Because functional languages are a good choice for extracting as much parallelism as you can get from your algorithms.
  - kragen 18y ago
    No. CUDA yes. Cg yes. HLSL yes. Verilog yes. VHDL yes. C++ or Java with MapReduce yes. PHP and MySQL with memcached yes. Erlang yes — and it really is functional, inside each process, anyway — that is, the level where you aren't getting any parallelism. Octave or R, potentially, but not today, as far as I know. Mathematica yes, and it, too, is mostly functional. In theory, side effects are what make parallelism hard, and so languages whose semantics are side-effect-free (unlike F# or Mathematica or Erlang) should make it easy. So we all thought in 1980. Since then we spent 20 years or so trying to make that happen, and it basically didn't work. There are basically four kinds of parallelism within easy reach today. There's SIMD, like MMX, SSE, 3DNow, AltiVec, and the like; you'd think that data-parallel languages and libraries like Numpy and Octave would be all over this, but except for Mathematica, that doesn't seem to be happening. There's running imperative code on a bunch of tiny independent processors that share no data; AFAIK that's what the shader languages are doing. There's instruction-level parallelism on a superscalar processor, which largely benefits from things like contiguous arrays in memory, or maybe what Sun is doing with Niagara, where the processor pretends to be a bunch of tiny independent slow processors. And then there's splitting up your data across a shared-nothing cluster, which is how every high-traffic web site works, and that's what MapReduce makes simpler. Uh, and then there's designing your own hardware or programming FPGAs, which is what Verilog and VHDL are for. Languages like OCaml (I don't know anything about F# except that it's like OCaml, but for the CLR) have no special advantage for any of these scenarios. They don't even have the theoretical advantage that they have no side effects and therefore you can speculatively multithread them without breaking the language semantics. They do have the massive practical disadvantage, in most of the scenarios I described, of needing unpredictable amounts of memory, having massive libraries, and using pointers all over the place. Using pointers all over the place kills your locality of reference and your ILP. Having massive libraries and using unpredictable amounts of memory makes it impossible to run them inside your GPU and means they can't run on an FPGA (except by using external memory, like the awesome Reduceron). And nothing about the language semantics helps with SIMD either. So, sheesh, go read Alan Bawden's dissertation or whatever, but don't go around claiming that ML (or even Haskell) is going to magically make your algorithms parallel. We tried that. It didn't work. We're trying something else now.

snprbob86 18y ago

I'm learning F# now because it will be another weapon in my arsenal that I would be allowed to use here. My impression of it, so far, is: "Heh, kinda cool". It is basically the total compromise functional language, but in a good way. Immutability is optional, you can write imperative code whenever it makes sense, and there is a reasonably syntax for defining .NET object oriented constructs. It is very much a functional language that peacefully co-exists with the rest of the .NET ecosystem and that is a strength if you need it. Sure, all of that interop comes at a power and complexity cost, but it is surprisingly small.