Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Given that the future of programming is functional, at some point in the nearish future I want to be paid to code in a functional language, preferably Haskell.

Assuming I have a firm grasp of the language, plus all the basic programmer attributes (good communication skills/sense of humour/hygiene etc), what should I concentrate on learning to maximize my chances? Are there any particularly sought after libraries I should know?

Alternatively, would another language be a better bet, say F#?

(I'm not too fussed about the kind of programming work, so long as it's reasonably interesting and reasonably well paid, and with nice people)

share|improve this question
1  
The first thing to work on would be a grasp of reality. Functional programming has been/is gaining market share, but it's still tiny. Considering the amount of work still done in COBOL, my guess is that nobody alive today will live to see even a simple majority of programming being done functionally. –  Jerry Coffin Mar 20 '11 at 6:34
1  
@dan_waterworth, what makes programming for pervasive multi-core processing possible isn't functional programming per se. It's the "Actor/Model" execution concept where every actor lives in it's own thread/process. The fact that functional programming is already organized around this type of execution model helps--but it is not the only language that supports it. –  Berin Loritsch Mar 20 '11 at 12:37
3  
@dan, the problem is computer languages are for humans as much as computers, and 50% of programmers graduated in the bottom half of their class. This is why you mostly see functional programming only in either very small 1-2 person teams, or very highly-qualified teams like high frequency trading. Having nice benefits like actor/model or immutable data doesn't help if you can't hire enough people that can understand those concepts. My opinion is the "future" will be multi-paradigm languages, where your top programmers can do FP, while the "rabble" does what is most comfortable. –  Karl Bielefeldt Mar 20 '11 at 16:18
1  
@Karl, I don't think that the myth that functional languages are more difficult to use than imperative languages is justified, but I think that library code will become multi-threaded, and the 'rabble' will just use these new libraries. @Jerry, no I agree, my personal preference would be to use a functional synchronous dataflow language which is an entirely different beast. –  dan_waterworth Mar 20 '11 at 16:38
1  
@Jim, the need for CRUD programming is already exhausted, the idea that you should write the same code over and over and over and over again for different objects is horrible, some people just don't realise that yet. –  dan_waterworth Mar 20 '11 at 18:29

3 Answers 3

At the moment, you have to be really lucky to be employed to program in a functional language. However, you can program in an imperative language in a functional way.

You can use functional data-structures. You can (so long as your compiler does tail call optimization) write recursive code. You can use discriminated unions for all your data-types. You can write functions to only use immutable data.

You may not have all of the same syntactic sugar, but you can still do functional programming.

share|improve this answer
    
That's pretty much where I am now - using FP techniques when it makes more sense (mostly in Javascript) and missing them when it's just too awkward to be worth the hassle (C++, PHP) –  Rob Agar Mar 21 '11 at 2:42

Given that the future of programming is functional...

Since when did we agree that it is?

Look, no less than Anders Hejlsberg has noted a movement towards a functional style of programming, specifically in C#, but I highly doubt that even he would categorically state that 'The Future of Programming is Functional.'

at some point in the nearish future I want to be paid to code in a functional language, preferably Haskell.
Assuming I have a firm grasp of the language, plus all the basic programmer attributes (good communication skills/sense of humour/hygiene etc), what should I concentrate on learning to maximize my chances? Are there any particularly sought after libraries I should know?

First, you need to fully appreciate the tradeoffs between functional and imperative programming. Once you do, you'll be able to identify problem spaces in which functional programming can facilitate a vastly superior solution, relative to imperative programming.

All things being equal, I think a familiarity with advanced computer science topics, a graduate C.S. degree, or both would help you towards this goal. [Emphasis: Formal, classroom education is not a requirement. It's just that some classroom discussion might further your appreciation and imagination in this realm.]

Alternatively, would another language be a better bet, say F#?

Don't worry so much about which language you choose.

Choose the one that you like best, and then develop your appreciation for the functional paradigm. The syntax of the other languages should be easy enough to pick up afterwards.

(I'm not too fussed about the kind of programming work, so long as it's reasonably interesting and reasonably well paid, and with nice people)

Good - That's the way you should be.

share|improve this answer
    
OK, I admit the future of programming bit was just to get people's attention. I believe it will happen one day, but not any time soon. –  Rob Agar Mar 21 '11 at 2:44

Create a startup! A number of startups have done very well with functional programming, all the way back to ViaWeb in the '90s which was using Lisp.

Outside that Javascript, ruby and python can all be programmed in a functional style. Scalla and Erlang are starting to pick up as well.

share|improve this answer

Your Answer

 
discard

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.