60

Don Syme in his SPLASH talk says that F# is NOT intended to be a replacement for C# even though it has the general capabilities. He goes on to say that there are areas where F# makes no sense in using, but doesn't expand on the thesis.

  1. Can somebody please tell me what areas should be avoided while using F# ?
  2. You could also mention areas where C# shine.

Related question:

In what areas might the use of F# be more appropriate than C#?

Community
  • 1
  • 1
unj2
  • 52,135
  • 87
  • 247
  • 375
  • 18
    I think he says that in order to keep the C# team and management happy (something about strategy). Its kind of like talking about Scala at a Java conference. – Ritch Melton Mar 12 '11 at 13:40
  • 12
    How is this off topic? How is this not related to programming? "Questions on Stack Overflow are expected to generally relate to programming or software development in some way, within the scope defined in the faq. – unj2 Mar 12 '11 at 13:50
  • 3
    Mentioning no names, I can think of at least one F# advocate who won't like this news (that F# isn't intended to replace C#)... ;p – Marc Gravell Mar 12 '11 at 14:28
  • 2
    @kunjan kshetri: It's a 'squishy' question that invites debate and doesn't have a 'right' answer. Typically these sorts of questions belong on http://programmers.stackexchange.com/ – Omnifarious Mar 13 '11 at 23:57
  • @Omnifarious : What about this question? http://stackoverflow.com/questions/2785029/in-what-areas-might-the-use-of-f-be-more-appropriate-than-c – unj2 Mar 14 '11 at 00:20
  • @kunjan kshetri: That question is only slightly better than this one, and I notice that many people thought it was too subject for StackOverflow as well. I'm tempted to start a close vote on it again. – Omnifarious Mar 14 '11 at 00:41
  • 8
    Sorry guys, voting to reopen. – Benjol Mar 14 '11 at 06:14
  • Did anyone else get the sense that Don is leaving F# from this talk? – Robert Jeppesen Mar 20 '11 at 10:42

9 Answers9

58

My take is that replacing a language as rich and mature as C# would be very expensive. So, for example, at the moment, C# is absolutely the best choice for WinForms development if using the Visual Studio WinForms designer can give you an advantage: F# has no WinForms designer.

C# also has better LINQ-to-SQL support at the moment. I'm sure there are many other examples along these lines.

Then there is requiring the entire C# skilled workforce to update their skills to F#, while preserving C# skills for maintaining applications, again expensive.

Finally, C# is an excellent language with a lot of great features, some F# doesn't even have like co/contra variant generics and out of the box support for dynamic programming against the DLR (F# just has an unimplemented operator).

So by not expecting F# to replace C#, F# can evolve in new ways instead of spending all it's time playing catch-up in areas already well-covered.

Stephen Swensen
  • 22,107
  • 9
  • 81
  • 136
  • 11
    I thought the last part was a really excellent point. This is a really well written post. Kudos! – Ritch Melton Mar 12 '11 at 22:09
  • "C# 5.0 asynchronous feature will be geared more towards GUI programming than F#'s". Can you elaborate on this? While you're at it, can you explain how this will work in C# without tail call elimination? My async code in F# always seems to rely on tail calls and it would be a real PITA to write without them... – J D Mar 14 '11 at 21:50
  • Hi @Jon - I went ahead and removed that comment about C# 5.0's asynchronous feature being more geared towards GUI programming than F#'s: looking into it more, I believe that was a false impression on my part due to emphasis given by Anders in his PDC presentation, compared to typical F# async introductory examples (I don't have hands-on experience with either, but F# async looks at least as capable through further reading). – Stephen Swensen Mar 15 '11 at 00:57
  • 9
    Thanks to everybody for your kind words and generous upvotes. As an aside, I want to express that I personally find F# hugely more productive and satisfying than C# in many, many areas (option types, immutability, tail call optimization, nested functions, async right now, code quotations, pattern matching, active patterns, sequence expressions, custom computation expressions, Hindley–Milner type inference, structural typing, structural comparison, first-class tuples, ...) and would love to see wide-spread adoption of the language. – Stephen Swensen Mar 25 '11 at 14:21
23

This is a tricky question, because it isn't very well qualified. Are you talking about the language in general, or are you talking about the language together with current IDE support? Or are you talking about using F# given the libraries available?

  • Language in general - I don't think there are areas where using F# would be an absolute nonsense. It would be great for systems programming of fully managed OS (e.g. Singularity) and I think that functional programs would be easier to verify formally (which could be a big deal for OS). For low-level embedded systems, you could use meta-programming and langauge-oriented facilities (e.g. to model signal flow in hardware etc.)

  • Language with current IDE - The current F# IDE has some limitations - it doesn't work with WinForms designer (but it works well with Blend and WPF).

  • Language given developer education - It is more difficult to hire F# programmers than to hire C# programmers. If you're creating some application that doesn't have any complicated core (e.g usual "interface for a database") then developing it in C# will be cheaper (If you could hire good F# developers they would likely finish it faster and with less bugs, but it may not be worth the cost).

  • Language given libraries available - If you want to restrict yourself to using F# with just libraries that work well with it then the domain shrink a bit more. For example, LINQ to SQL and ASP.NET MVC can be used with F#, but it isn't perfect. However, for many projects it would make sense to develop your own libraries and then F# becomes great language for that.

Tomas Petricek
  • 240,744
  • 19
  • 378
  • 553
  • Are there any literatures on the web that discuss the drawbacks of using LINQ to SQL in F#? It is a bummer that the translation is not perfect. Do you know of any effort to improve this aspect? – unj2 Mar 13 '11 at 14:38
  • This was a much more detailed post than I had anticipated. I should have been clearer in what I was expecting. I think I would be interested to know why the libraries in the .NET do not work well with F# and what can be done about it. – unj2 Mar 13 '11 at 14:39
  • 6
    FWIW, I spoke to a couple of database gurus recently (this is not my remit) and they both said that LINQ to SQL sucks and shouldn't be used anyway. – J D Mar 14 '11 at 21:55
  • 4
    Also, I'd like to echo what Tomas says here about F# and WPF. I have been developing commercial WPF apps in F# for years and found that it works very well indeed. I recently met a team of a dozen people in London developing much more sophisticated LOB WPF GUIs using a lot of F# and loving it. For some reason, quite a few people say that F# and GUIs don't mix but they're wrong. – J D Mar 14 '11 at 21:57
  • 3
    @Jon - FWIW, I've been working with LINQ to SQL for the past month or so and it's been a real joy. In the past I've worked plenty with raw ADO, raw ADO.NET, raw JDBC, Grails / Hibernate, iBatis, and custom ORMs; I would choose LINQ to SQL over any of those any day. It's quite elegant, dragging and dropping tables on the designer surface and writing statically checked C# LINQ queries against the generated object mappings is such a simple pleasure over working with raw SQL or monstrosities like Hibernate. It's been a real productivity boost. I wonder what alternative those db gurus would suggest – Stephen Swensen Jun 06 '11 at 20:35
  • 1
    @StephenSwensen 1. I LOVE unquote -THANK YOU! 2. Re the LINQ to SQL comments - a lot of L2S complaints are about it specifically - the query processing & optimization is a V1 effort with lots of pretty common cases not covered - as you more than anyone will be aware, if an expr traverse impl is incomplete, you're hosed (and a V0.9 impl will be v incomplete!). It is not being worked on and just being simpler than EF does not make it viable. I have not used EF with FS and have not done a lot of EF but I've never been simply snookered like I was with L2S in more than one case. – Ruben Bartelink Nov 20 '13 at 22:25
  • I wish you'd also mention how F# would fit in UI apps, such as WPF, Xamarin.Forms etc. (neglecting the fact it isn't currently supported by IDEs). – Shimmy Weitzhandler May 03 '17 at 09:15
17

Good question. I'd say that there are zero language reasons and many unfortunate skill-set, aptitude, and attitude reasons on the part of developers, managers, and customers.

Ritch Melton
  • 11,498
  • 4
  • 41
  • 54
8

You might want to think twice about using it for operating system kernel development or low-level embedded systems :-)

paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
  • Of course, any runtime-based language would make "absolute no sense" for those purposes. (Assuming the question meant to highlight the comparison to C#). – harpo Mar 12 '11 at 13:51
  • Why? Is there a problem with using functional languages in hardware? Defined embedded? Is a multi-core iPad an embedded device? – Ritch Melton Mar 12 '11 at 13:55
  • @Rich, notwithstanding his being a bit tongue-in-cheek, I think by "low-level embedded" Sr. Diablo meant firmware environments that preclude the use of a virtual machine (on the order of the JVM or CLR). And of course operating system kernels are by definition written directly against (or very close to) the hardware. – harpo Mar 12 '11 at 14:01
  • 1
    I meant embedded as in low level stuff where you don't want hidden costs like a VM or methods that you don't have a lot of control over. In other words, things that are ideally suited to asm or C. – paxdiablo Mar 12 '11 at 14:05
  • 2
    @harpo - The point that I am arguing is that there is nothing that precludes functional languages from interacting with hardware any more than there is a benefit to using procedural, or OO languages. – Ritch Melton Mar 12 '11 at 14:07
  • @Ritch, you can write an OS in COBOL and you can write an accounting application in x86 assembler. The fact that it's possible doesn't make it a good idea :-) The question was "what areas _should_ be avoided?", not "where is it impossible?". – paxdiablo Mar 12 '11 at 14:09
  • 3
    Going deeper, I'd argue that functional ideas translate to hardware-design better than procedural or OO ideas do. – Ritch Melton Mar 12 '11 at 14:09
  • @paxdiablo - That's a straw-man response. We're not talking COBOL, or asm, we're talking about functional languages, F# in particular. – Ritch Melton Mar 12 '11 at 14:12
  • Erlang programming language, which was developed by the Swedish company Ericsson in the late 1980s, was originally used to implement fault-tolerant telecommunications system – Ritch Melton Mar 12 '11 at 14:15
  • Scheme dialect of Lisp was used as the basis for several applications on early Apple Macintosh computers,[2][3] and has more recently been applied to problems such as training simulation software[4] and telescope control. – Ritch Melton Mar 12 '11 at 14:16
  • Haskell, although initially intended as a research language,[12] has also been applied by a range of companies, in areas such as aerospace systems, hardware design, and web programming – Ritch Melton Mar 12 '11 at 14:16
  • It's more an analogy than a straw man. If you have an F# that doesn't need .NET and assembled to native code without too much overhead, you could probably use it. But, even if that were available, pretty much _any_ examples you can come up with will pale into insignificance compared with the number done is C/asm :-) – paxdiablo Mar 12 '11 at 14:17
  • 2
    @paxdiablo - I've done quite a few systems in C w/asm blocks where needed (HC12/16, ARM, RabbitCore, i386EX) on custom hardware and, other than the RabbitCore (which was 64k, no linker), many of my implementations would have worked cleaner with functional styles. I think that the C choice is a matter of developer inertia and experience. – Ritch Melton Mar 12 '11 at 14:22
  • @Ritch, they may _well_ have worked better with functional coding. I very much doubt they would have worked better with a .NET under the covers. I suspect we may to agree to disagree here since it seems unlikely that either of us will change our minds :-) – paxdiablo Mar 12 '11 at 14:25
  • 2
    @Ritch: While function ideas may work well for design of (parallel) logic circuits, that's not the same as working well for the hardware-software interface. Most peripherals are highly stateful, you need a sequential approach to work with them, which maps to an imperative language much better than a functional one. OTOH F# isn't a purely functional language. – Ben Voigt Mar 14 '11 at 13:42
8

Many of Microsoft's UI technologies such as WPF have excellent support for databinding. Effective databinding uses two-way binding to update the underlying objects when the user interacts with the UI. This implies that effective databinding requires mutable objects.

F#, with its emphasis on immutable types, is a pretty poor match to that type of databinding model. While it's possible to create mutable types in F#, doing so would remove a lot of the benefits from the language. It simply makes better sense to use a language (such as C#) where mutability comes more natural.

Mark Seemann
  • 225,310
  • 48
  • 427
  • 736
  • Indeed, writing UIs is one of the primary places where immutability falls on its face. – Gabe Mar 14 '11 at 07:49
  • 9
    -1: Given the absence of any concrete example, I just don't buy this. I haven't had any such problems developing commercial GUI apps in F# using WPF and an obvious counter-example to your statement about mutable data structures is that F# has syntax for mutable array literals (`[|1;2;3|]`) and C# does not! – J D Mar 14 '11 at 22:01
  • 1
    There's no reason you can't implement INotifyPropertyChanged with mutable, or pass around state objects that are transformed. – Ritch Melton Mar 15 '11 at 03:46
  • 3
    I think this falls into the category _lack of good F# libraries_. F# emphasises immutability at the conceptual level, but you can use immutability as an implementation technique. I can imagine a perfectly functional declarative library for specifying two-way data binding that is used in a functional/immutable way, but does all the nasty mutable WPF stuff under the cover (Just imagine something like `Event.map` and `Event.merge` or Rx Framework that is extended in some clever way to write two-way computations). – Tomas Petricek Mar 20 '11 at 15:18
6

If you're willing to give up tools particular to C#, and pay whatever cost of adoption is applicable, there is no particular area where F# would not be at least as capable as C#.

Dan
  • 3,179
  • 1
  • 16
  • 13
  • 2
    you could say the same for punchcards, yet no one is using them anymore. why would that be? – oɔɯǝɹ Apr 04 '11 at 17:51
  • 2
    @oɔɯǝɹ it sounded more diplomatic than "F# is better than C# for everything, WYSIWYG is for sissies" – Dan Apr 13 '11 at 21:49
4

Well, at the risk of stating the obvious, F# is first and foremost a functional programming language and OOP programming in F# can be a pain in the neck. So if you're working with a problem that is best expressed with OOP I imagine using C# does make more sense.

Mutually recursive types and explicit implementation of interfaces are the first examples off the top of my head of why OOP in F# can be cumbersome.

An (often cited) example of "problem that is best expressed with OOP" is creating a UI library. You have many widgets, which encapsulate their own state and you want to ask them to do a few things like "draw yourself" polymorphically (is that even a word?)

Paolo Falabella
  • 24,914
  • 3
  • 72
  • 86
  • 2
    "So if you're working with a problem that is best express with OOP" Can you expand on this statement? – unj2 Mar 12 '11 at 15:41
  • @kunjan well, see for instance the so-called ["expression problem"](http://www.daimi.au.dk/~madst/tool/papers/expression.txt). both F# and C# fall short of resolving it. If you are in the case where you have a hierarchy of types that implement a well-defined set of functions and you wish to be more flexible in creating new sub-types than in creating new functions that work on all the types, then C# will be a better tool than F#. – Paolo Falabella Mar 12 '11 at 16:01
  • 4
    On the other hand, writing constructors and assigning parameters of constructor to fields is such a pain in C# once you try using implicit constructor syntax in F#... – Tomas Petricek Mar 12 '11 at 16:46
  • @Tomas I do love the F# way of (non)writing constructors. I'm just trying to point out that while other languages (like scala) are pushing the boundaries of both their OOP and functional aspects, F# as it is today is IMHO a language that was meant to write functional code AND to interact with a mostly OOP-oriented framework (in this order). Writing purely OOP code in F# is almost like writing purely functional code in C#, possible but not what the two languages shine at; so my point was, if you're going to write OOP, C# will probably be a better choice than F#. – Paolo Falabella Mar 12 '11 at 19:00
  • @Tomas by the way, I've learned most of my F# from you and Matthew Podwysocki (indirectly... reading what you wrote) so I'm perfectly aware of who I'm discussing F# with, here. – Paolo Falabella Mar 12 '11 at 19:08
  • "other languages (like scala) are pushing the boundaries of both their OOP and functional aspects". With neither type inference nor TCO, Scala is a poor man's functional language. – J D Mar 14 '11 at 22:14
  • @Jon I didn't mean to say that scala is a better language for purely functional programming than (say) Haskell, but it does have some cool "new" functional things: "unapply" in scala does what active patterns in F# do (and active patterns are considered one of the best innovations F# brought to the functional table). However,my point was about F# leaning much more on its functional side than its OO side and this (in turn) makes a "natively OO" language like C# better for writing OO applications. It sounded like a very trivial point when I wrote it, so I'm surprised it caused so many comments. – Paolo Falabella Mar 22 '11 at 15:08
  • I agree with your answer about OO and your statements about F# leaning toward FP. My concern was just with your remark about Scala but now I'd also add that features like active patterns (1987!) are far from new and people had been using them in at least OCaml and Haskell for years before Scala and F# reused the idea. – J D Mar 22 '11 at 23:22
3

Web Applications where Frameworks e.g. ASP.NET MVC lend themselves better to C#. "Absolutely no sense" is an extreme, I would say "under normal circumstances."

Of course it could be used for libraries that the web application referenced, but not the actual application itself.

t3rse
  • 10,024
  • 11
  • 57
  • 84
  • 4
    Why does a framework like ASP.NET MVC lend itself better to C#? Right now, that's just a claim you made, and I don't understand your reasoning behind it... – Mark Seemann Mar 13 '11 at 10:56
  • 2
    It makes sense to use F# for web applications. See Websharper for instance. – Laurent Mar 23 '11 at 02:49
3

Until f# is fully supported by Visual Studio (ASP.NET, WebForms, WPF, etc) and third party tools, f# will always be a second class citizen.

Let's face it, language choice usually doesn't make much difference to productivity when compared to a solid library (.NET, available to both c# and f# - no advantage to either here), the IDE (intellisense, syntax coloring, etc), (only partially support available to f# as far as I know... e.g. no Razor support), and third party tools (e.g. resharper).

So with that in mind, I don't think anyone can recommend a complete replacement of c# until all of those tools are in place for f#. A good compromise is to use f# in class libraries and continue to use c# on the front end.

Giovanni Galbo
  • 12,963
  • 13
  • 59
  • 78