none
When & Where do we use F#? RRS feed

  • Question

  • I think C# and vb.net is enough……So Why F#?

    It seems that F# doesn't support WinForm & WebForm……directly at least.

    Thx anyway

    Tuesday, July 31, 2012 9:28 AM

Answers

  • I believe it's rather not a question but general discussion. First of all C# and VB are not very different languages. You could consider VB as C# with very ugly syntax. F# is a different language. Yes, in Visual Studio it lacks UI tooling support but you can do any kind of .NET development using F#.

    See for example: http://stackoverflow.com/questions/141985/why-should-a-net-developer-learn-f

    Also here a good interview about F# and functional programming: http://www.infoq.com/interviews/trelford-functional#.UBZ6lQ_y35w.twitter

    For me F# is better than C# because it has:

    Immutability by default

    Type inference

    Discriminated unions

    Pattern matching

    Computation expressions


    Petr

    • Marked as answer by TimoYang Sunday, August 5, 2012 2:51 AM
    Tuesday, July 31, 2012 12:40 PM
  • You could equally say "I think C# is enough, so why vb.net?"

    Part of the promise when .net was launched over a decade ago was that it would be a polyglot platform, so you could write code in whichever language made sense for the particular component, and they would still all interoperate through the CLR.

    It seems that F# doesn't support WinForm & WebForm……directly at least.

    What F# doesn't have is the drag and drop visual designer crutches -- you can still invoke the UI classes directly.

    If you are starting a new web offering these days, it's more likely to be AJAX based -- and with tools like WebSharper, you can do the client-side in F# as well as the server-side.
    • Marked as answer by TimoYang Sunday, August 5, 2012 2:51 AM
    Tuesday, July 31, 2012 10:33 AM

All replies

  • You could equally say "I think C# is enough, so why vb.net?"

    Part of the promise when .net was launched over a decade ago was that it would be a polyglot platform, so you could write code in whichever language made sense for the particular component, and they would still all interoperate through the CLR.

    It seems that F# doesn't support WinForm & WebForm……directly at least.

    What F# doesn't have is the drag and drop visual designer crutches -- you can still invoke the UI classes directly.

    If you are starting a new web offering these days, it's more likely to be AJAX based -- and with tools like WebSharper, you can do the client-side in F# as well as the server-side.
    • Marked as answer by TimoYang Sunday, August 5, 2012 2:51 AM
    Tuesday, July 31, 2012 10:33 AM
  • I believe it's rather not a question but general discussion. First of all C# and VB are not very different languages. You could consider VB as C# with very ugly syntax. F# is a different language. Yes, in Visual Studio it lacks UI tooling support but you can do any kind of .NET development using F#.

    See for example: http://stackoverflow.com/questions/141985/why-should-a-net-developer-learn-f

    Also here a good interview about F# and functional programming: http://www.infoq.com/interviews/trelford-functional#.UBZ6lQ_y35w.twitter

    For me F# is better than C# because it has:

    Immutability by default

    Type inference

    Discriminated unions

    Pattern matching

    Computation expressions


    Petr

    • Marked as answer by TimoYang Sunday, August 5, 2012 2:51 AM
    Tuesday, July 31, 2012 12:40 PM
  • First of all C# and VB are not very different languages. You could consider VB as C# with very ugly syntax. F# is a different language.

    Well, if it's different, then all the more reason to ask why we need it. The difference between VB.NET and C# is basically syntactic as you said, so you have two choices as to how to write your code, but F# is a new approach altogether. I'm just starting to look at it, and still haven't really got my head around the motivation for using it.

    OK, before I go any further, let me clarify that. I have a motivation for learning it because I'm insatiably curious, and love programming. I want to learn something new, especially something that is fairly orthogonal to the standard OO-based programming I've been doing for years. However, that's purely motivated by my own interest. Other than a few edge cases where F# provided improvements for parallel programming (which is something I almost never need to do), I've yet to see any reason why I might use F# in my job. Put parallel coding aside for a minute, what sort of cases would you find in standard business scenarios where F# would be a better choice than C#?

    I think that is more the main point of the question. I would be very interested to hear some comments.

    For me F# is better than C# because it has:

    Type inference

    I'm currently reading "Functional Programming For The Real World" by Tomas Petricek, and he mentions this point every time he compares F# to C#, but he doesn't really explain why type inference is so great. A look around this forum shows that the issue is held in high regard by many other F# people. Why?

    I like to see the types of my variables explicitly. I never, ever use the C# keyword "var" as it hides that from me. Sure, the F# compiler can infer the type without me needing to type it explicitly, but that won't help me three months down the line when I come back to this code and need to understand what it does. I want to see it as clearly as possible, and hiding the types just gives me one more thing to break my head over, whilst debugging code.

    I'm sure there must be some good reason why people like type inference, but I have yet to find it. Maybe you could explain it to me, because it feels to me like the bad old days of weakly-typed languages. I know F# is strongly typed, but without seeing the types stated explicitly, it's like reading a weakly typed language, and having to keep the types in your head as you read the code.

    Please understand that I'm not having a go, nor criticising. I'm genuinely interested in learning more about F#. I'm just struggling to see anything other than academic interest at the moment.

    Thanks for any enlightenment you can bring :)


    FREE custom controls for Lightswitch! A collection of useful controls for Lightswitch developers. Download from the Visual Studio Gallery.

    If you're really bored, you could read about my experiments with .NET and some of Microsoft's newer technologies at http://dotnetwhatnot.pixata.co.uk/

    Thursday, September 20, 2012 1:44 PM
  • 1. "Put parallel coding aside for a minute, what sort of cases would you find in standard business scenarios where F# would be a better choice than C#?"

    First of all, parallel and asynchroonous processing IS a standard business scenario in almost all modern applications:). Although F# is better choice for any business rule application layer I could imagine. F# is almost ideal for creating DSLs. If you have some math calculations in your business process it will become even more clear.  UI development (I speak mostly for controls and layouts) is not very easy with F# because of lack of tooling support (Visual designers, Blend etc) but ViewModels could be easily coded in F#. Data access in any application became natural to F# with introduction of TypeProviders in F# 3.0.

    See for example this interview with Phil Trelford, he explains all this much better than I.: http://www.dotnetrocks.com/default.aspx?ShowNum=799

    2. Type inference and strict type checking helps avoid the whole class of runtime errors related to incorrect type casting which are very common for C# applications for example. It helps also maintain correctness of the program because very often where your C# program needs maintaining unit tests after refactoring F# program will give you compiler error right now.

    From my own experience very often when your program is compiled it just works correctly and require much less maintenace time.

    It also helps make programs more readable because in this case your code is not polluted by unneeded type declarations (BTW I believe it is one of the main reason for dynamic language popularity). Again you don't have to keep your types in your head because compiler will tell you when types are incorrect:)


    Petr

    Thursday, September 20, 2012 2:27 PM
  • Hi Petr, thanks for the reply.

    1) Hee hee, I think maybe I didn't explain what I meant clearly. I know there is a lot of parallel work going on, but for me (and most developers I know), a "standard" business scenario is an application where the user is shown a list of entities (customers, orders, etc), then double-click one and see a window with details of that entity. They do things to it, close it and choose another.

    That sort of scenario doesn't need parallel code in general, as it's mainly assembling objects from the database and saving the changes. What benefits would F# bring to those sort of applications?

    Also, you said "F# is better choice for any business rule application layer I could imagine" but you didn't explain why. The "why" is the bit that I'm trying to get at :)

    2) Can you explain how type inference avoids casting errors? My own experience is that if you make sure to keep all your objects as the correct types, you don't run into casting errors. What sort of cases do you have in mind where type inference can help?

    As for making the code more readable, I really can't see that. Sure explicit typing uses more characters, but it's immediately obvious what types every variable is, no possibility for mistake. If I look at F# code, I have to stop and think what type each variable is, because it's not written in the code. Shorter code is not necessarily more readable!

    Thanks again for the reply. I would be interested in any further comments. I've saved that interview for listening later :)


    FREE custom controls for Lightswitch! A collection of useful controls for Lightswitch developers. Download from the Visual Studio Gallery.

    If you're really bored, you could read about my experiments with .NET and some of Microsoft's newer technologies at http://dotnetwhatnot.pixata.co.uk/

    Thursday, September 20, 2012 2:58 PM
  • "application where the user is shown a list of entities (customers, orders, etc), then double-click one and see a window with details of that entity. They do things to it, close it and choose another."

    I couldn't imagine this as a "standard" application. More standard business case would be "hundreds, thousand or million users are shown a list of entities at the same time using the same datastore and application logic layer" etc.

    Even in modern "standard" single user UI app there are many different parallel notifications and animations happens simultaneously on the same page/form/screen. This is why C# and WinRT also introduced 'async' keywords.

    About readability - I speak just from my own point of view. I could read the code more easily when it looks like

    let getItemFromDictionary key dict = ...

    then

    Func<VeryEffectiveDictionary<MyKey, MyGenericBusinessEntity<FancyType>>,  MyGenericBusinessEntity<FancyType>> GetItemFromDictionary(MyKey key, VeryEffectiveDictionary<MyKey, MyGenericBusinessEntity<FancyType>> dict) = ...

    Again, just my opinion. Sorry, don't have much time for general discussion now. Just try to write complete small app in F# and you could decide which programming style is better for you. There are a ton of similar discussions going on on Stackoverflow, Quora and similar sites.


    Petr

    Thursday, September 20, 2012 3:30 PM
  • Regarding inference, I agree with Petr that readability is one of the most important reasons.  Of course you're right that concise code isn't inherently more readable than more verbose code, and readability is also somewhat subjective.  I think that many C# practitioners would disagree with your anti-var sentiment (especially when it comes to generic types like dictionaries, where the type names are huge), and F# basically enables a var-on-steroids approach, allowing inference in many places where C# requires type annotations.  Of course, just like in C# you can eschew type inference and add explicit annotations if you'd like, but most people find this unnecessary.  In F#, you can always just hover your mouse cursor over a variable to see the inferred type, so there's not much disadvantage compared to explicit annotations (as I recall, in C# you can hover over uses of the variable, but not its definition; in F# you can hover over both).

    The combination of type inference and F#'s lightweight syntax (lack of curly braces, nice array and list literals, etc.) mean that you can directly transliterate C# to F# and fit the results into about half as much space.  In my experience, this almost always makes it easier to understand the resulting code, because you can see so much more context when you're reading an individual line.

    If I were to try to summarize why I prefer F# to C#, here would be a list of the high points for me:

      • Rapid prototyping.  If I want to see how some F# code works, I can use F# Interactive to try it out immediately without having to go through a write-compile-debug cycle.  This is incredibly powerful, and applicable to any kind of code (business logic, algorithms, etc.).  F# 3.0 adds some features that make it possible to do this even for things like data access code, where in C# (or F# 2.0) you'd need to perform additional code generation steps.  Of course, F#'s lightweight syntax and type inference also help here, since it takes less effort to bootstrap something that you can start playing with in F# interactive.
      • Data modeling.  F# has several kinds of lightweight types that C# lacks, such as discriminated unions.  For certain domains, these types are simply a better way to model things than the best C# equivalents.  In general, it's a lot easier to declare simple types in F# than in C#, even for plain .NET types (e.g. you can use constructor parameters instead of explicit fields, etc.).
      • "Functional programming".  This is a nebulous term, but I'm using it here to mean a combination of features that make F# very expressive: first class functions (like delegates in C#, but a bit nicer in some ways), pattern matching, tuples, etc.  In general I find that these features make it easier to express certain operations than I would be able to using a C# approach.

    There are plenty of other nice things about F# that may be applicable to particular scenarios (ease of asynchrony, etc.), but this list should apply to pretty much any code you want to write.

    Thursday, September 20, 2012 3:41 PM
    Moderator
  • "application where the user is shown a list of entities (customers, orders, etc), then double-click one and see a window with details of that entity. They do things to it, close it and choose another."

    I couldn't imagine this as a "standard" application. More standard business case would be "hundreds, thousand or million users are shown a list of entities at the same time using the same datastore and application logic layer" etc.

    That's actually what I meant, not that there would only ever be one user.

    However, I don't see how this necessarily requires parallel processing. Most of the heavy lifting would be done by the database, and most of them are geared towards this sort of thing anyway, so you don't need to do any parallel coding to get them to work.

    Even in modern "standard" single user UI app there are many different parallel notifications and animations happens simultaneously on the same page/form/screen. This is why C# and WinRT also introduced 'async' keywords.

    You've switched from parallel to asynch. They are not the same, and may not go together. All the discussions on parallel processing in F# that I've seen have centred around number-crunching, not threading issues in UIs. It was the number crunching that I was saying wasn't necessarily a general business case.

    About readability - I speak just from my own point of view. I could read the code more easily when it looks like

    let getItemFromDictionary key dict = ...

    then

    Func<VeryEffectiveDictionary<MyKey, MyGenericBusinessEntity<FancyType>>,  MyGenericBusinessEntity<FancyType>> GetItemFromDictionary(MyKey key, VeryEffectiveDictionary<MyKey, MyGenericBusinessEntity<FancyType>> dict) = ...

    I agree the F# is much easier at first glance, but then the C# "var" keyword would get you half way.

    I was more thinking about understanding the code. If I can see the type right in front of me, it's one less thing to think about. Also, your example, whilst not unlikely, is less common than most where the type is somewhat simpler.

    I guess this is something I will have to put aside for the moment, and see how I feel about it when I have more experience of F#. Right now it doesn't look like a benefit to me, but I can only speak from my current mind set, not from the F# mind set that I imagine I would get from more experience.

    Again, just my opinion. Sorry, don't have much time for general discussion now. Just try to write complete small app in F# and you could decide which programming style is better for you. There are a ton of similar discussions going on on Stackoverflow, Quora and similar sites.

    I've read a lot of discussions, but still not really found a good answer. I appreciate your time. As I said, I guess a lot of this will become clearer with experience, I was just looking for some answers now :)

    Thanks again.


    FREE custom controls for Lightswitch! A collection of useful controls for Lightswitch developers. Download from the Visual Studio Gallery.

    If you're really bored, you could read about my experiments with .NET and some of Microsoft's newer technologies at http://dotnetwhatnot.pixata.co.uk/

    Thursday, September 20, 2012 3:46 PM
  • Hi Keith, thanks for the reply. You've clarified a few things for me...

    Regarding inference, I agree with Petr that readability is one of the most important reasons.  Of course you're right that concise code isn't inherently more readable than more verbose code, and readability is also somewhat subjective.

    Yup, and being used to one style makes it harder to see the benefits of another. However, a point you made below completely changes my point of view on this issue, so I'll refrain from comment until then...

    I think that many C# practitioners would disagree with your anti-var sentiment

    Yup, I know! However, my personal opinion is fairly anti-var, and out of all the programmers I know and/or work with, I don't know any who like it. It's a bit of a religious issue, like most in programming!

    In F#, you can always just hover your mouse cursor over a variable to see the inferred type

    Now that's a game-changer! If you could do this in C#, then I might be more inclined to use var there! Basically you get the shorter (ie more readable ) code without losing a clear statement of the explicit type. I'm convinced :)

    Admittedly, this is not a language feature at all, this is a VS feature, and so is not a benefit of F# per se. They could (and should if you ask me) easily add this for C# as well.

    The combination of type inference and F#'s lightweight syntax (lack of curly braces, nice array and list literals, etc.) mean that you can directly transliterate C# to F# and fit the results into about half as much space.  In my experience, this almost always makes it easier to understand the resulting code, because you can see so much more context when you're reading an individual line.

    True, it does look like F# produces shorter code, but as I've only seen simple introductory code so far, I haven't been able to see how "real life" code would translate.

    Doing well here, I'm becoming more and more convinced :)

    If I were to try to summarize why I prefer F# to C#, here would be a list of the high points for me:

        • Rapid prototyping.  If I want to see how some F# code works, I can use F# Interactive to try it out immediately without having to go through a write-compile-debug cycle.  This is incredibly powerful, and applicable to any kind of code (business logic, algorithms, etc.).  F# 3.0 adds some features that make it possible to do this even for things like data access code, where in C# (or F# 2.0) you'd need to perform additional code generation steps.  Of course, F#'s lightweight syntax and type inference also help here, since it takes less effort to bootstrap something that you can start playing with in F# interactive.

    I must admit that the interactive window is something I've long wished for in C#. If I'm writing a complex application, and just want to play around with one small utility method, It's a pain to have to run the whole application for that. The interactive window is a brilliant idea.

    Again, this isn't really a language feature, more a VS one, and something they could add for C#. Still, I can see that having it in F# would help you code more quickly.

  • Data modeling.  F# has several kinds of lightweight types that C# lacks, such as discriminated unions.  For certain domains, these types are simply a better way to model things than the best C# equivalents.  In general, it's a lot easier to declare simple types in F# than in C#, even for plain .NET types (e.g. you can use constructor parameters instead of explicit fields, etc.).
  • OK, you're beyond my knowledge here. I'm only starting out with F#, and haven't come across these sorts of things yet. Something to look forward to!

  • "Functional programming".  This is a nebulous term, but I'm using it here to mean a combination of features that make F# very expressive: first class functions (like delegates in C#, but a bit nicer in some ways), pattern matching, tuples, etc.  In general I find that these features make it easier to express certain operations than I would be able to using a C# approach.
  • This was the thing that made me most interested in F# in the first place. So far, most of the time, I've been able to see how you would do the same in C#, although not always as elegantly. However, I still have a long way to go to get a proper clarity in functional programming, so I guess the true benefits of F# are waiting for me there!

    There are plenty of other nice things about F# that may be applicable to particular scenarios (ease of asynchrony, etc.), but this list should apply to pretty much any code you want to write.

    That's a brilliant reply, thanks very much. I was going to look at it anyway, but your comments have given me enough reason to think that I could use F# in my day job, where parallel processing is really not an issue. The other points you mentioned would be benefit enough to justify it.

    Thanks again.


    FREE custom controls for Lightswitch! A collection of useful controls for Lightswitch developers. Download from the Visual Studio Gallery.

    If you're really bored, you could read about my experiments with .NET and some of Microsoft's newer technologies at http://dotnetwhatnot.pixata.co.uk/

    Thursday, September 20, 2012 4:01 PM
  • In F#, you can always just hover your mouse cursor over a variable to see the inferred type, so there's not much disadvantage compared to explicit annotations (as I recall, in C# you can hover over uses of the variable, but not its definition; in F# you can hover over both).

    In C# you can hover over the `var` keyword rather than the variable name to see the inferred type at the point of definition.

    Thursday, September 20, 2012 6:08 PM
  • In C# you can hover over the `var` keyword rather than the variable name to see the inferred type at the point of definition.
    Well cut off both my legs and call me Shorty! I didn't know that!

    FREE custom controls for Lightswitch! A collection of useful controls for Lightswitch developers. Download from the Visual Studio Gallery.

    If you're really bored, you could read about my experiments with .NET and some of Microsoft's newer technologies at http://dotnetwhatnot.pixata.co.uk/

    Thursday, September 20, 2012 6:37 PM
  • I think C# and vb.net is enough……So Why F#?

    It seems that F# doesn't support WinForm & WebForm……directly at least.

    Thx anyway

    Instead of providing a general answer, let me tell you our story at the company where I work: Prover Technology.

    We provide services around the design and verification of safety-critical systems, mostly railway signalling systems. Our job revolves around processing system definitions in the format of choice of our customer to produce models in our own formats which are suitable for automated static analysis tools.

    It is important to have great confidence in the quality of our translators. One of the ways to achieve such high levels of confidence is to write a specification of the translator "in math language", then write an implementation. We often write two implementations, one in a imperative language (typically C), another one in OCaml (a functional language which has a lot in common with F#).

    This allows us to draw some comparisons between C and OCaml/F#, and I have noticed some tendencies:

    • Quality-wise (number of known bugs), the C and OCaml implementations seem comparable. But that's because we have one great C programmer, but that's about it. We have a handful of people who can write code in OCaml/F#.
    • Performance-wise, there are no significant differences (and when there are, they are easily closed by optimizing the slower implementation).
    • It takes less time to develop in OCaml/F# than in C.
    • It's a lot easier to assess the correctness of source code in OCaml, as it's very close in style to the specification.

    To summarize: Use F# when it's important to develop bug-free software. F# is also a great choice for short development cycles, because you spend very little time debugging, but this assumes familiarity with the language, which you can't get overnight if you are new to functional programming. No pain no gain.


    [url=http://www.twitter.com/deneuxj]@deneuxj on twitter[/url] -- [url=http://marketplace.xbox.com/sv-SE/Product/Asteroid-Sharpshooter/66acd000-77fe-1000-9115-d80258550797]Asteroid Sharpshooter[/url] -- [url=http://sharp-gamedev.blogspot.com]F# + XNA[/url]

    Thursday, September 20, 2012 8:09 PM
  • It takes less time to develop in OCaml/F# than in C.

    That's a pretty significant point. I know it's a vague question, but do you ahve any guesstimate as to how much time you save by developing in F#?

    To summarize: Use F# when it's important to develop bug-free software.

    When isn't it? Debugging software consumes an enormous amount of the development cycle, and using a language that reduces the number of bugs would be a huge benefit.

    I don't know about the OP, but based on your reply, I'm certainly impressed! Thanks


    FREE custom controls for Lightswitch! A collection of useful controls for Lightswitch developers. Download from the Visual Studio Gallery.

    If you're really bored, you could read about my experiments with .NET and some of Microsoft's newer technologies at http://dotnetwhatnot.pixata.co.uk/

    Thursday, September 20, 2012 9:10 PM