I dunno why people think functional programming jobs are vanishingly scarce. They are not. If you can demonstrate skill in functional languages, you might even get recruited.
It's true there are more wage-slave code-a-day jobs, but those jobs can be easily filled by uninspired hacks who are in it for the money. If you're reading this, the odds of you being one of those hacks is very low. The job market is smaller, but the workforce of talented functional programmers is much smaller, so the demand is still high.
And Clojure & Scala are even easier because you can get a java job and them worm them in. It's not difficult to make a compelling argument that Clojure & Scala are better at Java than Java is.
Functional programming jobs are scarce, but that's because no-one is a "functional programmer" in the same way that you might be a "PHP programmer". Instead you get lots of jobs where you happen to write a lot of code in a functional programming language but you don't look like a programmer in an organizational sense - you're an "analyst" or an "engineer" or whatever. That's where F# is making inroads.
You're not going to do functional (or any other interesting) programming as an IT programmer in a generic financial services company.
If you work for an actual software company (or perhaps an innovative financial services company) as a software engineer (or even on an operations team in some cases e.g., Sysadmins at Google using Haskell, ops tools at Yahoo once built in OCaml), there's plenty of chances to do functional programming (or something else that interests you).
It's just generally people are programmed to think "it's just a job" and choose their jobs based on salary, name recognition, commute hours etc... (Some also have very specialized skills like systems programming or machine learning and aren't particularly interested in programming languages, although I think they're missing out)
I really don't understand your point. What is the difference between a "programmer" and an "engineer"? Why doesn't "functional programmer" as a category include things like "F#", which you suggest is a valid category.
As for me, I interviewed at several jobs that featured functional programming during my last jobsearch. I actually turned down offers that were not devoted to functional (or at least hybrid object/functional) technologies.
If you are an analyst working for a bank, then your job is to do financial analysis to inform trading decisions. That is what your title is, that is the result you are expected to produce, that is what you will see yourself as. But to actually do that, you might be writing F# 40 hrs a week. You wouldn't consider yourself a programmer tho'. The program is not a product in and of itself; it's just a tool you use that you happen to also make yourself 'cos it's easier than writing a spec document and waiting for "a programmer" to do it.
Similarly if you are an engineer working for Ericcson on switches for telcos then you job is to design and implement switches. The result you are expected to produce is a switch that is better than the current one. You will probably see yourself as an electronic engineer - but you might actually be writing Erlang 40 hrs a week. The code isn't a product either - it's just the means by which you tell your switch hardware how to behave.
Whereas if you are a "PHP programmer" someone has already decided that PHP is what we're doing and your role is to do PHP and your end product is a website built with PHP. Which is not a bad thing mind - but it is why you see "PHP jobs" and you don't see so many "F# jobs".
Comments
I dunno why people think functional programming jobs are vanishingly scarce. They are not. If you can demonstrate skill in functional languages, you might even get recruited.
It's true there are more wage-slave code-a-day jobs, but those jobs can be easily filled by uninspired hacks who are in it for the money. If you're reading this, the odds of you being one of those hacks is very low. The job market is smaller, but the workforce of talented functional programmers is much smaller, so the demand is still high.
And Clojure & Scala are even easier because you can get a java job and them worm them in. It's not difficult to make a compelling argument that Clojure & Scala are better at Java than Java is.
Functional programming jobs are scarce, but that's because no-one is a "functional programmer" in the same way that you might be a "PHP programmer". Instead you get lots of jobs where you happen to write a lot of code in a functional programming language but you don't look like a programmer in an organizational sense - you're an "analyst" or an "engineer" or whatever. That's where F# is making inroads.
You're not going to do functional (or any other interesting) programming as an IT programmer in a generic financial services company.
If you work for an actual software company (or perhaps an innovative financial services company) as a software engineer (or even on an operations team in some cases e.g., Sysadmins at Google using Haskell, ops tools at Yahoo once built in OCaml), there's plenty of chances to do functional programming (or something else that interests you).
It's just generally people are programmed to think "it's just a job" and choose their jobs based on salary, name recognition, commute hours etc... (Some also have very specialized skills like systems programming or machine learning and aren't particularly interested in programming languages, although I think they're missing out)
I really don't understand your point. What is the difference between a "programmer" and an "engineer"? Why doesn't "functional programmer" as a category include things like "F#", which you suggest is a valid category.
As for me, I interviewed at several jobs that featured functional programming during my last jobsearch. I actually turned down offers that were not devoted to functional (or at least hybrid object/functional) technologies.
If you are an analyst working for a bank, then your job is to do financial analysis to inform trading decisions. That is what your title is, that is the result you are expected to produce, that is what you will see yourself as. But to actually do that, you might be writing F# 40 hrs a week. You wouldn't consider yourself a programmer tho'. The program is not a product in and of itself; it's just a tool you use that you happen to also make yourself 'cos it's easier than writing a spec document and waiting for "a programmer" to do it.
Similarly if you are an engineer working for Ericcson on switches for telcos then you job is to design and implement switches. The result you are expected to produce is a switch that is better than the current one. You will probably see yourself as an electronic engineer - but you might actually be writing Erlang 40 hrs a week. The code isn't a product either - it's just the means by which you tell your switch hardware how to behave.
Whereas if you are a "PHP programmer" someone has already decided that PHP is what we're doing and your role is to do PHP and your end product is a website built with PHP. Which is not a bad thing mind - but it is why you see "PHP jobs" and you don't see so many "F# jobs".
I don't see how this has any bearing on functional programming jobs.