Bringing new programming paradigms into the workplace

Question

I'm currently learning Haskell, largely for my own entertainment. It seems like some of the programs I develop at work could benefit from being written in a FP language.

However, I'm very aware that if I were to deliver a unit of Haskell code, I'd be presenting my employers with a maintenance challenge: I'd be the only person in the organisation who understood the language or even its underlying paradigm.

If I suggested up front that a project use Haskell, I'm pretty sure it would be vetoed. Sure, it's easier to ask forgiveness than permission - but frankly I agree with the reasoning.

Yet, ten years ago, that was the status of Java.

How does a language make that leap from niche to mainstream? How do you propel a language in that direction?

Answer 1

For an exotic language to become mainstream you need either a big paid hype machine, or a killer feature, or both. In the case of Java, Sun certainly did enough hyping, and "write once, run anywhere" combined with the closeness to C syntax was a killer feature.

As a rather different example, Ruby was an obscure fringe language for a decade until Rails as its killer app brought it into the limelight.

I'm afraid individual developers have very little chance to "propel" a language, unless they do it in droves, which usually happens because of killer features.

Answer 2

A lot of the time this happens when smart developers take the risks on their own without the bureaucracy / management overhead of a large company.

This often happens when lots of developers start using it for hobby projects and some of those hobby projects become useful to others giving the language prominence. Or someone takes a risk, starts their own company and writes a decent app which becomes popular which makes others believe the language is worth taking a risk on. Or it gets proven in companies R&D departments before it gets used in production.

Maybe you can get your company to use it on a small side project which is not critical to the bottom line and can prove its usefulness there.

Answer 3

Try thinking about what you mean by "could benefit from being written in a FP language". Work out what the benefits are. Measure them. Use the measurements to justify. If you can't do this in your own time, or for a small project then the benefits are probably just imaginary, and you just want to justify leaning a new language on work time :-)

Answer 4

Not specific to computer languages, but you may like to read Fearless Change, which describes patterns for introducing new ideas (or technologies) in organizations.

Answer 5

That will be a tough battle for you to win, and IMO you can only win it if you succeed in proving that Haskell would improve the performance of your team.

Take in mind that habits are difficult to change and you will probably have to prove your case to EVERYONE in your team. Honestly, if you don't work on an Open minded team it will never work. Changing a language is hard for many people even if they are mostly the same (c# to VB.net or vice versa), now you can imagine how changing to something completely different will seam to your co-workers.

Most of all i think you need to analyse if the time that will take most people in your team to learn Haskell will be worthwhile (in production terms). If you can prove that with this new way the company will increase their productivity, then just let it go, it will be a battle you wont be able to win.

If you can prove it profitable, then think of EVERY single question your co-workers might ask and have the best answer you can come up with ready, because even if you are right, you will be up to a long fight.

Answer 6

On the topic of Haskell, I'd be careful about trying to use it for real world applications. I know a couple of very bright computer scientists who where Haskell experts and huge fans of the language. They also felt that Haskell would be perfect for this application they where going to write. And even though they eventually managed to get their application working, it was much much more work than they ever expected, and they both admitted, reluctantly, that Haskell really wasn't a good language for writing general purpose applications.

All that being said, I highly recommend learning Haskell (or something similar). Not because you'll ever necessarily use it in the real world, but because it will make you think about programming from a different angle, which can in turn be used to improve your programming in other 'normal' languages

Answer 7

It certainly is possible to do it, but you need to be really careful how you approach it, and you need to both minimise the jump and provide a compelling reason to do so. You also need to be highly aware that most coders have a tendency when first using a new language to gloss over the difficulties of applying it to an existing problem and highlight the advantages ('cause we're all neophiles at heart). For example Haskell may be a really good fit for some particular problem domain but you'll have to reinvent the wheel multiple times for other business rules/issues in your organisation that have been already solved for the standard development environment. If so even if you did get it past management it would be regarded as a failure because the disadvantages would swamp the advantages (and these sort of issues are often massive time sinks so you could easily end up not just with a failure, but a disaster)

In these circumstances you should look for a tightly defined niche where the language fits really well and can be limited to just the niche. It should be a small project and non-critical. If you are a microsoft shop you might also like to reconsider Haskell and go for F# instead as it's a .net language - still functional but lowers the barrier to entry considerably.

Answer 8

If you're working in a language that allows for aspects of FP, even if it's not made for it, like c#, you could start by using those aspects of FP in c# code. If you can demonstrate it's efficacy and make your coworkers more comfortable with the paradigm, that could go a long way towards introducing FP in general to the workplace.

Answer 9

How do new ideas get propelled?

If professors get on board, then they infect students, and it snowballs.

I'd be careful, though. By all means try out new ideas on your own, but anyone can be fooled into thinking "new" ideas are more wonderful than they really are.

This field (software engineering) is particularly susceptible to bandwagons, and since OOP has reached middle-age, folks are hankering for some new excitement. I suggest taking it all with a grain of salt.