tags:

views:

8734

answers:

8

I work for a tech company that does more prototyping than product shipment. I just got asked what's the difference between C# and F#, why did MS create F# and what scenarios would it be better than C#.

I've been using the language for a while now and I love it so I could easily go on about the great features of F# however I lack the experience in C# to say why we should use one over the other.

What's the benefits of using C# vs F# or F# vs C#?

+15  A: 
  • F# Has Better Performance than C# in Math
  • You could use F# projects in the same solution with C# (and call from one to another)
  • F# is really good for complex algorithmic programming, financial and scientific applications
  • F# logically is really good for the parallel execution (it is easier to make F# code execute on parallel cores, than C#)
Rinat Abdullin
Thanks, bullets are good.
gradbot
+5  A: 

You're asking for a comparison between a procedural language and a functional language so I feel your question can be answered here: http://stackoverflow.com/questions/23277/what-is-the-difference-between-procedural-programming-and-functional-programming

As to why MS created F# the answer is simply: Creating a functional language with access to the .Net library simply expanded their market base. And seeing how the syntax is nearly identical to OCaml, it really didn't require much effort on their part.

Spencer Ruport
Although I think your general answer is correct that the real question is about the comparison of programming paradigms and not languages, I feel that the answer in the question you are referring is a bit shallow.
Jeroen Huinink
Feel free to suggest another question if you have a better one. That's the highest rated one I found from a google search.
Spencer Ruport
I think he was trying to be kind about you sounding like an ass for saying F# didn't require much effort on Micrsoft's part.
Matthew Whited
+1 for market base comment. Simple and has some truth to it.
gradbot
I don't buy into that other link answering my question. C# supports a lot of functional constructs in newer versions.
gradbot
C# vs F# != procedural vs functional.
Jon Harrop
+21  A: 

It's like asking what's the benefit of a hammer over a screwdriver. At an extremely high level, both do essentially the same thing, but at the implementation level it's important to select the optimal tool for what you're trying to accomplish. There are tasks that are difficult and time-consuming in c# but easy in f# - like trying to pound a nail with a screwdriver. You can do it, for sure - it's just not ideal.

Data manipulation is one example I can personally point to where f# really shines and c# can potentially be unwieldy. On the flip side, I'd say (generally speaking) complex stateful UI is easier in OO (c#) than functional (f#). (There would probably be some people who disagree with this since it's "cool" right now to "prove" how easy it is to do anything in F#, but I stand by it). There are countless others.

Rex M
+1... Excellent analogy
Dave Swersky
If all you have is a hammer, everything looks like a nail. -Maslow
Charlie Salts
Nice analogy - Totally agree with you
Dario
I'm not going to up vote this because it doesn't give any real specifics except for the one data example. I know they are different tools. I'm asking what jobs these two tools are best and worst at in comparison to each other. I know a philips is often the best tool for the job even though a smaller flathead will work.
gradbot
If he won't upvote you I will. :P +1
Spencer Ruport
Haha, thanks @Spencer ;) @gradbot - no problem! Sorry my answer isn't exactly what you're looking for... hopefully others will find it useful.
Rex M
If all you have is a hammer, everthing looks like a thumb.
ebpower
i agree with gradbot, this is a good answer hence no downvote from me, however it doesn't really get to the specifics of the original questions. This answer is just a vague conceptual explanation, but really misses the point of answering the question exactly.
Stan R.
+4  A: 

F# is not yet-another-programming-language if you are comparing it to C#, C++, VB. C#, C, VB are all imperative or procedural programming languages. F# is a functional programming language.

Two main benefits of functional programming languages (compared to imperative languages) are 1. that they don't have side-effects. This makes mathematical reasoning about properties of your program a lot easier. 2. that functions are first class citizens. You can pass functions as parameters to another functions just as easily as you can other values.

Both imperative and functional programming languages have their uses. Although I have not done any serious work in F# yet, we are currently implementing a scheduling component in one of our products based on C# and are going to do an experiment by coding the same scheduler in F# as well to see if the correctness of the implementation can be validated more easily than with the C# equivalent.

Jeroen Huinink
-1. F# is a multi-paradigm (OO+FP) language. Only **purely** functional languages don't have side-effects (like Haskell), but F# is not pure.
Mauricio Scheffer
+31  A: 

General benefits of functional programming over imperative languages:

You can formulate many problems much easier, closer to their definition and more concise in a functional programming language like F# and your code is less error-prone (immutability, more powerful type system, intuitive recurive algorithms). You can code what you mean instead of what the computer wants you to say ;-) You will find many discussions like this when you google it or even search for it at SO.

Special F#-advantages:

  • Asynchronous programming is extremely easy and intuitive with async {}-expressions - Even with ParallelFX, the corresponding C#-code is much bigger

  • Very easy integration of compiler compilers and domain-specific languages

  • Extending the language as you need it: LOP

  • Units of measure

  • More flexible syntax

  • Often shorter and more elegant solutions

Take a look at this document

The advantages of C# are that it's often more accurate to "imperative"-applications (User-interface, imperative algorithms) than a functional programming language, that the .NET-Framework it uses is designed imperatively and that it's more widespread.

Furthermore you can have F# and C# together in one solution, so you can combine the benefits of both languages and use them where they're needed.

Dario
Nice Power Point. I'm interested to see what it says once they complete it.
gradbot
They combine in very weird ways. For example, you can overload the > operator in F#. C# developers can then use it. However, F# developers can't. That's right, F# can emit operator overloads that it can't consume.
Jonathan Allen
Downvoters: Please comment why you do so!
Dario
Because the ppt you've linked to has C# code that makes me go "wtf!?". Very unfair and pointless comparison. I was expecting to see real life code compared, not a comparison between procedural ways of doing things and an inheritance overuse.
HeavyWave
+4  A: 

F# is essentially the C++ of functional programming languages. They kept almost everything from Objective Caml, including the really stupid parts, and threw it on top of the .NET runtime in such a way that it brings in all the bad things from .NET as well.

For example, with Objective Caml you get one type of null, the option<T>. With F# you get three types of null, option<T>, Nullable<T>, and reference nulls. This means if you have an option you need to first check to see if it is "None", then you need to check if it is "Some(null)".

F# is like the old Java clone J#, just a bastardized language just to attract attention. Some people will love it, a few of those will even use it, but in the end it is still a 20-year-old language tacked onto the CLR.

Jonathan Allen
+1, This may be the cold hard truth however I'm still quite happy that I can use a functional language in VS with .NET
gradbot
Here's hoping the masses beat some sense into them and F# 5 will be a bit more pragmatic.
Jonathan Allen
I agree that Nullable<T> should have the compiler do some magic aliasing for us. I'm not sure that making "Some null" be equivalent to None would always work - some interop code might rely on it. But reference null? How are you going to work around a major hole in .NET? Wrap every reference type in an option?In practise, this only seems to be an issue with certain interop scenarios.
MichaelGG
Close. Wrap every reference type in an option, unless the function returning it is marked as non-nullable by a Code Contract. .NET 4 is supposed to have all the pieces needed to do this right.
Jonathan Allen
"Wrap every reference type in an option" -- uh, that'd suck. It'd add lots of overhead and look quite disgusting. F# started in 2004 -- well before Code Contracts, which will only be in .NET 4. So that's not a real answer for us using 3.5 or Mono.
MichaelGG
FWIW, I've been coding professionally in F# for several years (longer than almost anyone else in the world) and I have never seen this problem or the code `Some null` in any F# code anywhere. Of all the things people might gripe about, this has to be *waaay* down on the list...
Jon Harrop
+12  A: 

To answer your question as I understand it: Why use C#? (You say you're already sold on F#.)

First off. It's not just "functional versus OO". It's "Functional+OO versus OO". C#'s functional features are pretty rudimentary. F#'s are not. Meanwhile, F# does almost all of C#'s OO features. For the most part, F# ends up as a superset of C#'s functionality.

However, there are a few cases where F# might not be the best choice:

  • Interop. There are plenty of libraries that just aren't going to be too comfortable from F#. Maybe they exploit certain C# OO things that F# doesn't do the same, or perhaps they rely on internals of the C# compiler. For example, Expression. While you can easily turn an F# quotation into an Expression, the result is not always exactly what C# would create. Certain libraries have a problem with this.

    • Yes, interop is a pretty big net and can result in a bit of friction with some libraries.

    • I consider interop to also include if you have a large existing codebase. It might not make sense to just start writing parts in F#.

  • Design tools. F# doesn't have any. Does not mean it couldn't have any, but just right now you can't whip up a WinForms app with F# codebehind. Even where it is supported, like in ASPX pages, you don't currently get IntelliSense. So, you need to carefully consider where your boundaries will be for generated code. On a really tiny project that almost exclusively uses the various designers, it might not be worth it to use F# for the "glue" or logic. On larger projects, this might become less of an issue.

    • This isn't an intrinsic problem. Unlike the Rex M's answer, I don't see anything intrinsic about C# or F# that make them better to do a UI with lots of mutable fields. Maybe he was referring to the extra overhead of having to write "mutable" and using <- instead of =.

    • Also depends on the library/designer used. We love using ASP.NET MVC with F# for all the controllers, then a C# web project to get the ASPX designers. We mix the actual ASPX "code inline" between C# and F#, depending on what we need on that page. (IntelliSense versus F# types.)

  • Other tools. They might just be expecting C# only and not know how to deal with F# projects or compiled code. Also, F#'s libraries don't ship as part of .NET, so you have a bit extra to ship around.

  • But the number one issue? People. If none of your developers want to learn F#, or worse, have severe difficulty comprehending certain aspects, then you're probably toast. (Although, I'd argue you're toast anyways in that case.) Oh, and if management says no, that might be an issue.

I wrote about this a while ago: Why NOT F#?

MichaelGG
+4  A: 

I work for a tech company that does more prototyping than product shipment... What's the benefits of using C# vs F# or F# vs C#?

The main advantage of F# over C# is much lower development costs (once your developers are familiar with F#, which will probably only take a few weeks).

From my personal experience I would estimate the productivity boost (= drop in development cost) to be 2-10×. This is strongly dependent upon the application, of course. The best cases for F# are applications requiring dense algorithmics (i.e. hard problems) or DSL implementations. The worse cases for F# are primarily where other languages have better tooling, e.g. GUI designer, WSDL code generator.

Jon Harrop