Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Let's assume, for a second, that you're "the boss", or architect, or whatever position would permit you the authority to decide on the following question:

You work on a product that's existed for a number of years and it's developed entirely in an imperative style/language. Let's also say that there is a feature or subsystem to be implemented that would benefit from a functional language/approach.

A hypothetical example might be that the product is implemented in C# and the subsystem/feature could be implemented in F#.

So your dev, who's a proficient F# developer, comes to you and says "I want to write this subsystem/feature in F#".

Do you say yes, or no? Why or why not?

share|improve this question
"paradigm" and "language" are two pairs of shoes... – tdammers May 26 '12 at 16:32
Consider saying "Yes, but only if you do it as pair programming, as I want to minimize the bus factor. Also the whole team needs to peer review your code!" – user1249 May 26 '12 at 17:37

My question would be, who is going to support this application when Ms. F# leaves for greener pastures. It's hard enough to hire good C# programmers in this town; where am I going to find F# programmers? What happens if F# falls out of fashion (is it in fashion?) and I have to hire some kid who knows Erlang and is doing his best to figure out F#?

It's not that the language is functional, it's the risks involved in later maintenance that is the major consideration. If there's no readily available local support system for the proposed language, I would have to say no. Otherwise, I'd ask for a POC and see where it goes.

share|improve this answer
True ... I'd argue that functional programs (well, purely functional) are less maintenance in the short and long term anyways as they have no bugs due to side-effects, and if you eliminate nulls, no bugs due to null reference exceptions. – Richard Hein Jan 29 '13 at 15:15

This depends on what the team is like and what the project is like. If we are talking about a large system that is being developed and maintained by a team of developers, then the answer is "probably not". In such a case, regardless of who wrote the original feature, the team as a whole has to maintain it. This means that as much as possible, each feature should be developed in a way that any other member of the team can jump into the code at any time. If your the only guy who knows F#, that's not going to work.

A manager also has to be concerned about hiring new developers. Can they find new F# guys off the street? I know this attitude make it hard for newer (and possibly better) languages from taking hold, but at the end of the day, our job is to deliver working software, not to promote good languages.

On the other hand, if the entire team knows F#, or wants to learn F#, then maybe it's ok. Regardless, it needs to be a team decision, as does everything else that goes into the project.

On the other hand, if this something completely separate from the main task, then maybe it's ok. A few years ago, we had a task to write a program to do some back-end database manipulation to create data for our client application. The dev wanted to use Perl, and since it was entirely decoupled from our client (which used C++) and since it isn't hard to find Perl people in the group, this was no problem.

Ask yourself what would happen if your dev got hit by a bus half way through development? Will it be a problem that his code is all F#? That should answer your question for you.

share|improve this answer

Were I a manager, I would say yes. Here’s why.

Developing a solution in a language well suited to the problem is to my mind a no-brainer. Provided of course that it’s quantifiably better suited than (and integrates well with) the prevailing toolset, a developer can be an order of magnitude more productive when using the right tool than when striving for uniformity. The price you pay for that productivity is increased maintenance cost in the event of the original developer’s departure or bus-related demise.

The technical edge tends to be worth the cost.

To riff on your example: F# is not a wildly popular language, but it is well-supported. As a .NET language, it is eminently compatible with the C# predominant at your (hypothetical) workplace. Microsoft intends to maintain it for some time, and there are resources out there for learning it and maintaining systems written in it. As such, you will always be able to find F# developers. Moreover, the (current) programming language status quo ensures that F# developers are not only well equipped to handle F#, but also probably good developers in general. The same goes for Haskell, or Lisp—languages that people know when they really know what they’re doing.

share|improve this answer
"some time" is never long enough. Ask any VB6 programmer. – user1249 May 26 '12 at 17:39
I disagree that "the technical edge tends to be worth the cost". You may gain productivity, but you introduce risk. All of your gains can be lost in an instant if a critical bug is found in the field the week after your only F# programmer quits. Plus, unless the original environment was stupidly chosen, I find claims of order of magnitude increases in productivity dubious. (And if they are true, that argues for your entire team to switch, not just one developer.) – Steven Burnap May 26 '12 at 17:49
@StevenBurnap: Just offering my own experience. If I’m writing a compiler, I can do it faster in Haskell than in C, but that doesn’t mean C is necessarily a stupid choice of language for all compilers—and if my teammates are working on a game engine in C that the compiler targets, there’s no reason for them to switch to Haskell. There aren’t any silver bullets, just case-by-case good choices, and I prefer to use the right tool for the job when possible, even at the expense of uniformity. – Jon Purdy May 28 '12 at 1:22
@Jon Purdy It's not really a question of uniformity but whether or not anyone else can step into your shoes if you are hit by the proverbial bus. "worth the cost" depends a lot on whether there are others in the team who can jump in and work on your Haskell compiler. If so, then great. – Steven Burnap May 28 '12 at 1:27
@StevenBurnap: Yeah, it’s definitely dependent on the team. But hey, I’m already hypothetically a manager, so I might as well have my hypothetical dream team, eh? – Jon Purdy May 28 '12 at 1:37

The main reasons not to are a break in consistency and maintainability. If it's simply a feature, I would be disinclined to let the programmer break from the current standard (unless everything is moving to that standard) since then you would then have essentially two codebases to switch between. If it's a standalone module that occasionally interacts with the existing codebase, then I'd be inclined to go with the best tool for the job (taking maintainability into account).

But it also depends on political/social aspects. You don't want to isolate the programmer politically by making it seem as though he can do whatever he likes; but also you want to let him be creative and have input into the engineering process. You're the boss, so you'll need to determine how big a deal that is for your situation.

share|improve this answer

This question is easy to answer. It's a big no-no. The reason is the following:

  1. Answering YES will allow programmers to use new nice features with end result of one happy programmer. All the other programmers will need to learn some strange environment. But causes large amount of wrapping between languages and tools, which is just waste of time. Two environments will have difficulty communicating. It's like your codebase is split to two separate parts.
  2. Answering NO will keep the status quo. One programmer will be unhappy, but the system you're building is going to have less limitations and restrictions.
share|improve this answer

Its just risk evaluation. Are there other engineers on staff that know f#? Is it easy to find f# programmers relative to c#? Do they require higher pay? What is the benefit of writing in f# vs. c#? Faster time to market? Easier to maintain or understand? More reliable? Personally unless I knew f# AND there are at least 2-3 f# engineers on staff I think it's a bit risky.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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