Are you a functional programmer? [closed]

Question

Are you a functional programmer?

By that I mean

• employed full time
• paid by someone else
• using a recognized functional language (Haskell, Scala, Erlang, F# etc, not just using FP techniques in an imperative language like Javascript)

If so, what do you do, and how did you get there?

Answer 1

Yes (partially).

I work for a major financial institution. Our codebase is mostly Java, but we are starting to do some development in Scala. Scala serves very well as a "better Java". Right now we are using it mostly when we want to use Actors to manage concurrency. We are only using it for backend code, and haven't tried doing a web app with Lift yet.

Since seamless interop with Java is a must, our only other viable functional language choice would be Clojure. As much as I love Clojure, Scala just makes a lot more sense for us. A team full of uninitiated Java programmers can pick up Scala MUCH faster than Clojure.

Answer 2

I am employed full time as a functional programmer by a company that design tools that are used by quants to analyze stocks, bonds, and portfolios, and I get to work on the open source functional programming libraries that we use.

I mostly work in Scala and Haskell, but in the past I have also done paid consulting in Erlang.

How did I get here?

I abandoned college to do programming at Ford and to run a very early internet startup out of my basement back in 94. I transitioned to working at the regional internet service provider that was hosting me, doing misc. systems programming, and eventually transitioned to CTO. Along the way I became involved in the demo scene, and licensed technology to game companies.

I also spent a lot of my spare time obsessing about how to design better programming languages, but sadly I lacked knowledge of the state of the art in that area. I became heavily interested in concurrency and proving the correctness of code, unfortunately, my world-view was somewhat distorted, and I only thought of the latter through the lens of Hoare triples and separation logic.

By the time the dot-com crash hit, we were a nationwide DSL provider and my resume was too mismatched to find work, between the lack of formal education and the glut of senior management experience.

Licking my wounds I went back to college and binged through a bunch of degrees as quickly as I could. While I was working on my second Masters I discovered Haskell, and I had more or less a religious conversion experience. Here was a language that had solutions to many of the things that I had been trying to express in my pet language projects backed by a much more sound theory than any of the ad hoc solutions I had come up with to date.

I binged obsessively through Types and Programming Languages, everything I could find on substructural logic and pure type systems, and read every paper I could find on functional programming for the better part of a year.

Because it is relevant to the conclusion, I'll sermonize a bit. Along the way I spent a lot of time obsessing about how category theory and functional programming interact. This has led to a lot of interesting and surprisingly practical applications for Kan extensions, the Yoneda lemma, etc. But ultimately, what I like about functional programming is that with fine grained control over side-effects, parallelism and concurrency are vastly easier to reason about. I like to go as far out into theory as I can drag kicking and screaming back into practice. Object-oriented code sprinkles synchronization points across your entire codebase, due to the existence of objects that have mutable state. Pure functional code on the other hand provides far fewer choke points.

After that, the economy recovered, and my resume was no longer so mismatched. I moved to the coast to do defense contracting for a few years, and started doing consulting on massively-distributed systems and functional programming.

My current position came about when a couple of folks from ClariFi came out to see a talk that I gave at the Boston Haskell user group on how one can use monoids in purely functional code to increase opportunities for parallelism.

They went and implemented that solution, and brought me in to do consulting, and later offered me enough to lure me away from the defense contracting world and to convince me to come on board full time.

Now, I spend a lot of time on the clock working on scalaz, the main scala functional programming library. It adapts many Haskell ideas such as monads, etc. to Scala, but more interestingly, it has no real legacy code base and pile of books to support, so it has been able to fix many of the historical accidents and warts of the Haskell Prelude.

Others built scalaz before I even learned scala, but there is a lot of overlap between the communities, and it was based fairly heavily on work that I did in Haskell, so it has been a very smooth transition.

So ultimately, I get paid to work on a mishmash of open- and close- sourced code, much of which was based on my own choice of abstractions.

There are worse jobs.

TL;DR I got here through a mixture of real world experience, contacts, academic credibility, community involvement, a lot of open source software development, and consulting.

Answer 3

I have been paid to program in G (LabVIEW) for many years. You can argue whether or not it's a real functional programming language (or even a real language), but the mindset needed to program in G is the same as that needed for other functional programming languages. As a data acquisition engineer I found that G (LabVIEW) was the best language for the job, especially since most of the DAQ hardware we used came from National Instruments (NI).

To get a job like that you need a reasonable background in electronics and instrumentation. NI offers demo versions of their latest LabVIEW offerings and there are user groups throughout the country where you can get free hands-on demonstrations. There aren't as many job openings looking for LabVIEW expertise as there are for more traditional languages, but they are out there--do a search on monster.com.

Also, there are many people who are paid to develop complex spreadsheets. While spreadsheets are not usually included with programming 'languages', they can perform the same tasks that are usually assigned to typed programming languages, especially typed functional programming languages. I suspect you'll find a lot more 'spreadsheet programmers' in accounting and other financial areas, but they can be useful in other areas as well.

Answer 4

At my last job we were writing simulations, most of the code was in C for number crunching, with bash and perl for glue, but there were a few bits and pieces written in Lisp and Haskell. Currently I'm doing algorithm design and prototyping, and again mostly working in C and C++, but I've used a fair bit of Haskell in my last couple of projects.

I never tried to look for jobs specifically where I could use functional programming, but I do try to look for jobs that let me use the best tool for the job, and empower me to decide what that tool is.

Answer 5

No. I'm a programmer employed full-time by someone else, but I don't use a functional language and I've really never seen the point of using one. I use functional techniques when they would enhance my work, and when they wouldn't, I do something else instead. I enjoy the flexibility of being able to do that, whereas too many functional languages make the same mistake as Java--thinking that there's only One True Programming Paradigm and making tasks that don't fit that paradigm painful.