What's wrong with F#?

views:

2118

answers:

+12 Q:

What's wrong with F#?

That is, what about the language would make it unsuitable for production environments (excluding the fact that it's not yet officially graduated from MS Research)? I'm interested in functional programming (especially on .NET) and I'd like to learn this language, but I worry about its applicability in the real world.

Edit: I'm aware of the benefits of F# - I want this question to concentrate on the deficits - I want to know why F# would be a poor choice, and for what sorts of projects it would be a poor choice.

Edit 2: I asked this question a while ago, when F# was still in beta, but I believe it's more relevant a question now as it nears release with Visual Studio 2010. Any new answers would be great to see, especially now that many people have had the chance to get their hands on it and figure it out.

+7 A:

Currently I would say that the biggest problems are tooling issues and the practicallity given the limited (but growing) mindshare of it.

If can find people willing to work and maintain the application using F# then I would say that most of the challanges can be overcome, basicly for the large enterprise I think the biggest hurdle is the still scarce situation when it comes to finding "resources" for future development and maintenance.

Torbjörn Gyllebring 2008-10-02 06:50:15

Heh, maybe early F# adoption can be "job security"? =P

Erik Forbes 2008-10-02 06:54:11

If your hiring process doesn't suck, people you hire will be able to use F# just as easily as C#.

MichaelGG 2008-10-19 18:07:36

Good, motivated programmers will have no problem learning F#. However it may be difficult to convince a manager to write a new app in F# if no one else knows the language, especially if it is something that must be maintained for several years down the road.

Justin Ethier 2009-05-23 15:03:20

A lot of programmers wouldn't have problems moving VB<->C#<->Java<->Delphi, but F# and similar languages would present a large number of new and very much unfamiliar concepts all at once.

Pavel Minaev 2009-12-19 00:41:33

I actually found the learning curve w. F# to be a lot easier than I expected. I'm a C#/C/C++ programmer with no experience of functional languages. It took a little while to get my head around the whole thing but really only a few weeks, especially when I realised I could TDD it.I think setting expectations is important. F# is a lot more thinking and then writing a little code. C# tends to be more write/think/refactor, at least for me doing TDD. The biggest point of friction for me is now the tooling; intellisense, debugger and decypering error messages.

Ade Miller 2009-12-29 20:11:30

+1 A:

One characteristic of F# is that because of the architecture of the .NET platform, it is not a pure functional language, like Haskell for examlpe, but I don't think that is necessarily wrong.

I think it only means that there will be specific scenarios to which it will be best suited, like typical enterprise applications written in .NET but that need some processing best done with functional style programming, contrasted with the more academic research kind of programming done with a pure functional language.

But I am also waiting to see first how people start using it in real world scenarios.

Sergio Acosta 2008-10-02 06:50:53

Yeah, I know F# isn't *pure* functional - but from what I've seen so far I like the blend of OO and functional. Thanks for the input. =)

Erik Forbes 2008-10-02 06:53:34

Very few functional languages are pure, actually, and people seem to get along just fine writing large, reliable applications in the non-pure ones, such as LISP and OCaml. Don't get me wrong: I love purity. But I don't think that the lack of it in F# is a major strike against it when viewed in the broad context of FP language implementations in use today.

Curt Sampson 2009-05-19 14:26:07

I don't mind the impurity when compared to Haskell ... but where I think Haskell is ahead in the functional department is its laziness. Cool algorithms can be expressed clearer and more concise in Haskell because of its lazy nature.

Alexandru Nedelcu 2009-06-10 21:30:24

Well, F# has lazy sequences as well as lazy values in general on language level (sequence comprehensions, and `lazy` keyword) - they're just opt-in rather than opt-out. It also seems that lazy sequences are very much the norm in idiomatic F#. On the other hand, pervasive laziness can be detrimental to performance sometimes, and makes it very hard to estimate the costs.

Pavel Minaev 2009-12-19 00:45:27

+1 A:

As I understand it, F# would come in useful for those areas in your code that are heavily algorithmic in nature, as opposed to best being solved by objects.

So taking a "typical" CRUD web app, I would see F#'s real world applicability being in the areas of the system that e.g. perform lots of data processing, rather than the whole web app being written in F# (although i'm sure that would be possible)

If you're already a .net developer, I think F# is going to be a really useful tool to have in your toolbox for fairly specific types of problem

Paul

Paul Nearney 2008-10-02 06:57:18

So, like building functional libraries in F# for algorithmic code, and calling that from C# or VB.NET? That makes since and is an interesting use-case I hadn't considered yet (it is .NET after all). Thanks! =)

Erik Forbes 2008-10-02 07:01:25

I've yet to see what C# does that would make it better for writing "the rest" of any application.

MichaelGG 2008-10-19 18:09:09

C# does GUIs and WSDL better and value types more efficiently.

Jon Harrop 2008-10-24 19:23:10

"Data processing" can also refer to data mining, and this involves heavy algorithms that can better be expressed in a more expressive language.I think you're thinking more about interface-building, where the interactions between objects is more important.

Alexandru Nedelcu 2009-06-10 21:34:00

@MichaelGG: OOP, at least using conventional .NET patterns, is generally less clumsy with C# (consider event declarations, interface implementations, etc). Another big deal is IDE support - even as basic as editor formatting and refactoring.

Pavel Minaev 2009-12-19 00:43:34

Paul Stovell had some interesting (and amusing) comments today on his blog entry Bindable Linq - F# is Overhyped

Whilst I don't necessarily agree with him, it was a refreshing counterpoint to the current F#e hype.

johnc 2008-10-02 07:12:56

That's funny, I just read this article earlier today (and left the first comment) =P

Erik Forbes 2008-10-02 07:16:27

I did wonder if there was a link :)

johnc 2008-10-02 09:21:18

+6 A:

If you want to learn a functional language you can use in production systems, pick up OCAML (strongly related to F# and has a few more features to boot):

http://caml.inria.fr/ocaml/index.en.html

Kendall Helmstetter Gelner 2008-10-02 07:14:09

It's more difficult to work with OCaml, because the standard libraries are lacking basic functionality you'd expect (we've been spoiled by Python, .NET and the like) and because you have to be ready to deal with stuff like Unicode issues, and the lack of polymorphism for standard operators. These issues are not major, but it makes migration more painful than it should be, so F# is a better choice for someone just starting.

Alexandru Nedelcu 2009-06-10 21:27:10

If OCaml is just like F#, but lacks the features of the .NET framework, isn't that an argument FOR F#?

Robert Harvey 2009-07-08 04:11:15

F# lacks some features of OCaml as well - for example, OCaml functors, or statically structurally-typed OO system with MI.

Pavel Minaev 2009-12-19 00:42:26

+1 A:

I don't think there's anything wrong with F# per-se. F# has all the imperative and OO-constructs that C# has so most C# programs can just be translated verbatim to F#. In addition to that you get a lot of functional constructs that you can use to make your applications more performant and to make your design nicer.

I'm not too happy with the way F# integrates the functional and the object oriented though. The divide between objects and functions is too large. An object is a CLR construct and functions are an F# construct. Languages like python seem to do better at mixing oo and functional concepts even though it's even less pure functional. There's less of a divide between things like objects, functions and even methods. In practice this means that it's easier to evolve old-style imperative code to a more functional style of programming.

Mendelt 2008-10-02 08:52:46

+2 A:

The question can also be refrazed as what’s wrong with developers and corporate culture to hinder F# adoption? It's another language to learn with a new way of thinking about programming to get the maximum efficiency out of it. In many companies you have average or below average developers who don't want to or are incapable of learning a new language and technology in a timely enough fashion to help the business. This reminds me a little of the Java verses Scala debate with the exception that C# is improving at a faster rate then Java in part do to the fact that there is much less legacy code written in C# and F# has a large corporate backer which Scala does not have.

Jared 2009-05-29 17:58:04

+1 A:

Visual Studio 2010 which supports it is still in beta.

Lone Coder 2009-12-19 00:18:50

ansaurus

tags:

views:

answers:

What's wrong with F#?

related questions