37

I'm CTO of a software firm with a large existing codebase (all C#) and a sizable engineering team. I can see how certain parts of the code would be far easier to write in F#, resulting in faster development time, fewer bugs, easier parallel implementations, etc., basically overall productivity gains for my team. However, I can also see several productivity pitfalls of introducing F#, namely:

1) Everyone has to learn F#, and it's not as trivial as switching from, say, Java to C#. Team members that have not learned F# will be unable to work on F# parts of the codebase.

2) The pool of hireable F# programmers, as of now (Dec 2010) is non-existent. Search various software engineer resume databases for "F#", way less than 1% of resumes contain the keyword.

3) Community support as of now (Dec 2010) is less available. You can google almost any problem in C# and find someone that has already dealt with it, not so with F#. Third party tool support (NUnit, Resharper etc) is also sketchy.

I realize that this is a bit Catch-22, i.e. if people like me don't use F# then the community and tools will never materialize, etc. But, I've got a company to run, and I can be cutting edge but not bleeding edge.

Any other pitfalls I'm not considering? Or anyone care to rebut the pitfalls I've mentioned? I think this is an important discussion and would love to hear your counter-arguments in this public forum that may do a lot to increase F# adoption by industry.

Improve this question
3
  • 7
    "The pool of hireable F# programmers [...] is non-existent" - Almost non-existent. However, if you do find a programmer who has or is willing to specialise in F#, they're likely to be pretty special.
    – Tim Robinson
    Dec 24, 2010 at 23:31
  • You are asking for real-life pitfalls, but are including potential pitfalls in your question. This is inviting for more "imaginary" pitfalls in answers, or for off-topic answers refuting the pitfalls you are considering. If would downvote your because of this formulation problem if I could (reputation too low)
    – Joh
    Jan 3, 2011 at 20:06
  • Nick, I would say: pick out some senior, capable language geeks that you already have and let them play with F# with the purpose of making the company smarter / better / more productive, and not just for fun. There are a couple of guys like that where I work.
    – Job
    Sep 23, 2011 at 22:49

9 Answers 9

Reset to default
28

Search resumes for other functional languages such as Scheme, Lisp or Haskell. A lot of people learn these in school and have them on their resumes; I'm sure many of them wouldn't mind learning F#. I have Scheme in my resume even though I never used it after school and a job involving F# would probably get my attention too.

Improve this answer
0
13

Any other pitfalls I'm not considering?

In practice, the main mistake I see people make is trying to force the use of F# for problems where it is the wrong tool for the job.

Or anyone care to rebut the pitfalls I've mentioned?

They are all obviously valid concerns to some degree but I'd question to what degree.

For example, you say that everyone would have to learn F# in order to work on F# code. Although true, this is not a big deal in practice. Learning F# is no more significant than learning WPF, Silverlight or the TPL. I'm teaching about 30 developers how to use F# for a client in London right now and about a dozen were working full time on F# code after only a few weeks and they just shipped their first product (on-time and in-budget!) written almost entirely in F# after only a few months. In point of fact, they had more technical difficulties with Silverlight than F# and they found the tech support for Silverlight to be much worse than for F#.

You refer to the relatively small pool of available F# programmers but, again, given how easy it is to pick up F# I don't think this is a significant concern. I doubt you'll need to hire many, if any. My client has two F# guys for over 100 programmers and our job is to seed and supervise the use of F#.

Your third and final concern regards less community support, Googling for C# solutions vs F# and third party tool support. Again, I haven't found these to be problematic in practice. I e-mailed fsbugs with a comment about units of measure in F# and got a response within 24 hours from the researcher who invented it with a detailed explanation of why my interpretation was wrong and why it works the way it does. I never got that from Anders Hejlsberg ;-). I Google for solutions all the time and find them written in C#, VB or even IronPython but, in 3 years of using F# industry, can recall only a single instance where translating the solution into F# was not trivial. In point of fact, I recently converted the data serializer C# sample from MSDN to F# and it was 5× shorter. Finally, you mentioned F# support in tools like NUnit when we've been using NUnit from F# without issue for some time. These are .NET tools, not C# tools.

Case study: My current client is not only using NUnit for unit testing but they built TickSpec in F# on top of NUnit as a technically superior alternative to SpecFlow for BDD. The author made a point of showing me that TickSpec is a tiny fraction the size of SpecFlow and provides more features. Moreover, several of the developers at work with no prior F# experience (and, I believe, no prior functional programming experience) have picked it up and started using it in unrelated projects without issue precisely because F#+TickSpec make it easier to solve their problems.

FWIW, I gave my client a free site subscription to our F#.NET Journal which went down well with many of the devs learning F#.

HTH!

Improve this answer
4
  • 3
    Flat-out assertion: a language you can learn that fast isn't worth adding to a business development mix. The point in F# is to write functional code, and most people aren't going to learn functional programming that fast.
    – David Thornley
    Dec 29, 2010 at 19:11
  • 8
    Flat-out counter example: LINQ. Writing functional code is absolutely not the point of F#, by either definition of "functional". In the context of existing C# devs, they should already be half way there with System.Func.
    – J D
    Dec 29, 2010 at 20:13
  • 1
    If F# is not primarily about functional programming, then what is it really about? How do you know when F# is a better fit than, say, C#?
    – Robert Harvey
    Jan 3, 2011 at 21:19
  • 5
    @Robert: F# offers a variety of features that can make it much more productive than C#. Variant types and pattern matching are hugely powerful for creating and manipulating trees, which appear in everything from compilers to computer graphics. Type inference makes it easy to write heavily generic code, which is ideal for dense algorithmics. The interactive sessions are ideal for disposable code, like massaging data sets from one form to another or even doing sophisticated analysis. These features are only incidentally related to functional programming and all work well in imperative code.
    – J D
    Jan 5, 2011 at 19:38
8

As you recognize in your first point, your programmers who don't know F# can't work on the F# part of your codebase. However, you don't need to rewrite your whole codebase in F# to gain advantages from using it - just rewrite the parts where you would see the biggest benefit. The fact that F# interoperates really well with C# should make it relatively easy to carve out certain parts and create F# assemblies out of them.

If you had your engineers working on a traditional 3-tier application, you probably wouldn't insist that they all needed to have a deep knowledge of SQL, HTML, Javascript, CSS, etc. Instead, you'd naturally have some specialists working on different parts of the application. Therefore, I don't think that adding a new language for one part of your application should be too big of a hurdle. Furthermore, you can use coding standards and other practices to try to make sure that your F# code is readable even by engineers without a deep F# background.

Improve this answer
1
  • 1
    @kvb, my comment is a bit off topic, but just wanted to share that while usually ideal, in practice many companies do not have specialized positions as you've described and do require that, as in your example, a single developer have deep (enough) knowledge of SQL, HTML, Javascript, CSS, etc. and perhaps business analysis as well. I've personally worked under both scenarios (not determined by company size) and each has it's advantages and disadvantages and may be more or less appropriate on a per-project basis, but specialization certainly is luxury.
    – Stephen Swensen
    Dec 25, 2010 at 19:48
7

The pitfalls of adding F# to the languages you use include the pitfalls of introducing any new technology. Regardless of the benefits, if some of your team don't want or aren't flexible enough to learn, they won't be able to work on F# projects. Nevertheless, if you let dinosaurs on your team prevent your adoption of new technologies, your company is doomed.

The only pitfalls I have personally experienced are:

  1. Difficulties when debugging. Following the flow of execution of an expression-based program in a debugger designed for statement-based languages can be tricky.

  2. Frustrating intellisense. Auto-completion stops working exactly when you need it. Microsoft must work on making the background parser more fault-tolerant.

  3. Indentation-sensitive syntax makes it difficult to copy-paste or reformat code.

  4. Lack of refactoring.

  5. Some of the existing convenient VS extensions for F# (code folding, depth colouring) are a bit slow, making the typing experience a bit frustrating.

In my opinion, none of these issues are show-stoppers, and I can live with them for the time being. Tools are easier to improve and fix than languages.

Your fears that hiring new programmers capable of writing in F# would be difficult are quite common but in my opinion unjustified. If you were to write coding guidelines, would you advise against or forbid any of the following features in C#: yield return, LINQ to objects, lambdas, the upcoming async?

If you believe these features help write better code, then there is no reason to refrain from F#. The language supports these features in a smooth and well thought-out manner, which C# can't really do due to its legacy.

If your team is smart enough to understand the concepts behind the features I mentioned, they have all they need to be excellent programmers in F#. The same goes for future recruits: Would you hire anyone who is incapable or unwilling to use features introduced after C# 1.0?

Improve this answer
5

I've contemplated this exact situation.

This is what I plan for my team:

  • Mix C# with F#, this can be done by using C# for the majority of the code-base. Where heavy data processing is required, write the associated functions in F# and put it inside a dll, or reference it. Example here

  • Slowly re-factor your existing code-base in the above fashion.

  • Not all code has to be functional.

  • Get your team to learn the basics of Haskell, LISP over the weekends.

  • Get them to learn F#, by trying to solve Euler Project puzzles (that helped me a lot when I was learning F#). Again this should be something done say over the week end, or during work time if you want set a day aside for "training".

Improve this answer
2
  • 15
    are you going to pay your developers to be working on this over the weekend? Lord knows I've spent many-a-weekends and evenings learning F#, but as a hobby. While it is true that when I was tapped for a Grails project I taught myself that framework partly during off-time, but that's just my personality and I enjoyed it, but if anyone had told me to do it during my off-time I would not have been happy.
    – Stephen Swensen
    Dec 25, 2010 at 20:01
  • +1 but: Haskell and Lisp are of purely academic interest. I don't think it would add value to a .NET programmer for them to learn those languages. I think (as the author of several F# books ;-) that reading a good book would be more productive than trying to write F# code (like project Euler puzzles) in vacuo. With guidance, they can be up to speed in one month.
    – J D
    Dec 29, 2010 at 18:27
4

1) Learning a functional language will increase someones overall ability as a programmer however this only applies to those who want to learn and improve. Not every programmer wants to become better nor do they want change in their work environment (know your team.)

2) I can't argue with this. You will have to pay for the 6 month learning curve of any new language however already knowing .net libraries eliminates the extra years required to learn new libraries.

3) Community support while smaller than C# does have quite a few highly skilled active F# developers posting on the web. Don't forget that most language support is library support and there is great support for .NET.

The thousand pound gorilla here is risk management. "I can be cutting edge but not bleeding edge." I'd argue that F# is not bleeding edge. It has been released with VS2010 and is directly supported by Microsoft. Bleeding edge is "beta" and a disclaimer from Microsoft saying something about not being responsible for anything.

Improve this answer
1
  • If someone already knows C# and .Net platform, learning F# usually costs less than one month. (based on the experience from my two co-workers. )
    – Yin Zhu
    Dec 25, 2010 at 2:39
4

As a practical matter, IntelliSense support is quite lacking -- to the point where the productivity gains of type inference are outdone by the less-sophisticated autocomplete available in C#.

The error messages caused by erroneous type inferences also take longer to fix for beginners (and often for intermediate users like myself), simply because you're less inclined to provide type annotations than you would in a language like C#.

OOP is also lacking in surprising ways in F#; for instance, there's no support for nested types/classes. You have to be careful when you're porting code, because there are some things that you can do in C# that you can't do in F#, sadly.

Last but not least, both the size and the quality of the F# community is sort of disappointing. A lot of the F# information out there on the web is either for old versions or simply not very good -- either un-idiomatic, poor performance or flat out incorrect. Then there are people charging huge money for newsletters that are largely just of existing information digests.

I myself use C# for work projects and F# for my own stuff. As much as I love F#, unfortunately, it's a bit hard to predict how/when things might fall apart.

Improve this answer
3
  • 1
    If £39 is "huge money" for training a developer then learning F# is the least of your worries, IMHO.
    – J D
    Dec 29, 2010 at 19:00
  • Uh oh, the man himself. Man, you're everywhere, aren't you? £39 is in fact huge money for the kind of information that in this day and age is almost always made available in blogs or technical papers.
    – Rei Miyasaka
    Dec 29, 2010 at 19:13
  • 2
    All very relevant information, I'm not sure why people are down-voting your post. As much as I like F#, the question has to do with its negative sides, and posts pointing these out should not be down-voted by F#-lovers.
    – Joh
    Jan 3, 2011 at 20:29
1

The main problem is always maintainability.

I would love to code in Scheme, but the next maintainer would probably want to hunt me down and torture me.

Improve this answer
1
  • What if the next maintainer also knows Scheme? I've read on comp.lang.lisp that Lisp programmers network for the purpose of being able to provide replacements to their employers if needed.
    – Larry Coleman
    Dec 25, 2010 at 14:17
0

I would say the first thing you need to do is ask your team members how they feel about introducing F#. If they like the idea, everything will go much smoother then if they don't.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.