The Functional Programming Hiring Problem

What attracts people to being a programmer? For some people it’s “looks like a reasonable job with good pay and conditions”. For others, it’s more “I love computers, programming, and abstract puzzles to solve”. This latter group (of which I am one), is more likely to provide both benefits and problems.

The benefit is they will generally be capable of greater innovation than the former group, but the downside is that they may just focus on interesting puzzles and ignore the needs of the (boring) business. Choosing an exotic language will greatly tilt the ratios towards this later group.

Most people in this later group can discipline themselves to focus on delivery, while remaining a great resource when truely challenging puzzles pop up. Most, but not all. Choosing a very esoteric language is pushing the curve far towards this tail, and the result will be many “brilliant, but useless to our business, people”.

Every small business needs a strong technical leader. I’m convinced of this. You need someone in charge that can stop the arguments, make people put down their toys, and remove people that cannot contribute for whatever reason. So this is my conclusion, it’s boring like so much of business. You need the right manager.

To me, this doesn't seem to be a problem unique to functional programming languages. You'd have this problem when choosing any language outside the mainstream, I think.

From the article:

> Then, one thing leads to another, and you're knee deep in learning about homotopy type theory or continuations or whatever. Meanwhile, you're a week behind on that Jira ticket for issuing JSON Web Tokens because there's no actively maintained JWT libraries for Gooby.

You wouldn't have this problem in the first place if the language you chose -did- have an actively maintained JWT library.

Like, a company that chooses Haskell is a lot more likely to run into this problem than a company that chooses Clojure, due to the simple fact that Clojure can use Java libraries, whereas Haskell exists within its own isolated ecosystem. So, between the two, the likelihood is generally lower that you will, in the first place, run into a problem that Clojure can't easily solve.

So, in my mind, this essentially boils down to the same sort of risk/reward assessment you always need to make when choosing any language for any project.

They way overspent their strangeness budget[0] at every step of the stack. Even though I love (this) Gooby in general, in this case it has caused extreme damage to the organization.

I am still angry at the original devs for their choices because they basically poisoned the whole org against the language even though it would be useful for the org as a whole to adopt it in a non psychotic manner. It basically resulted in a reflexive ban for all Gooby in the future even when it might make sense.

[0] https://steveklabnik.com/writing/the-language-strangeness-bu...

But I think that author is missing at least one more category: senior engineers that worked in multiple programming languages over their career, who can see how design of Gooby and values of it's community create a better programming environment.

This is incredible

And this article sadly shows why. Objectively, they aren't fair to "Goody engineers". Often, they mean opinionated engineers. Now opinionated engineers can be good and bad for profits - they work hard and point maybe good direction and maybe bad directions. But they make the company harder to sell and that objectively reduces the stock price and so it's bad from the "economic standpoint" even if it makes profits somewhat higher.

You get programming astronauts in every language. There’s nothing special about Gooby or functional programmers that makes them deficient in the ways described. You could easily replace Gooby with Rust, Lisp, Python, C++, C#, Java, JS.

What makes the functional programming astronauts stand out is pure optics. If you’re tolerant of C++ templates or Python’s metaclasses you might view discussions on Profunctors to sound like gibberish. If you’re not someone who even uses those tools at all and avoid them out of principal it can sound like a plot for a hostile takeover. To an experienced Haskell programmer it’s likely to be fairly banal.

Which kind of blows this whole theory that Gooby programmers are the problem.

The real problem are those who seek to use a hammer regardless of what problem they’re trying to solve. I’m certain anyone whose been around for a while had encountered the “patterns astronaut,” who will view every problem as an opportunity to figure out how to apply as many GoF patterns as possible. These are the misguided souls we need to bring back into the fold.

After a posting on the Haskell mailing list, zero responses came back.

We realized the world had about 3 people that matched all the requirements: one was the dev that needed to be replaced, the other one was a tenured professor of a U.S. university (Hi, Hal!), and there was one more, whom I don't remember but it may just as well have been Simon Peyton-Jones himself (only slightly exaggerating here).

Note the Haskel NLP mailing list - https://archives.haskell.org/projects-pipermail/nlp/ - did not exist then, it was formed only in 2009.

In the end, I forced a complete re-write in Java of our initial "rapidly prototyped" Haskell codebase at the time, and I often wonder what I would do nowadays, nearly 20 years later (Python is slow, has the commercial disadvantage of letting customers read off your secret sauce if code runs on their machines, but has a good dev pool to hire from, and definitely is both high-level enough as well as suitable regarding library support; ironically, Java is still a contender, despite the boilerplate Kotlin isn't getting the traction that Rust is getting against C, C++ has changed dramatically every 5 years in the 20 years since, and still ads complexity, which is all very scary, and Julia has a small talent pool, and isn't ready for prime time yet, certainly not regarding NLP libraries).

I know, since this is HN, people will say "LISP!", but I'm not sure; I always loved the aestetics of Scheme, but not the ergonomics - and my conjecture is there might be something about keywords that makes them superior cognitively for humans compared to just piles of nested parentheses.

EDIT: fixed a typo.

I have a long history of doing FP in a bunch of the traditional FP languages (Scheme/Haskell/etc). Ended up working at a young startup with equally young employees awhile back and was sort of surprised to see that the long heralded fantasy of cranky FP enthusiasts has, for better or worse, come true in Type Script.

I saw a generation of new programmers truly doing type-driven development and using a range of functional programming techniques without them even realizing that this was a big thing. Funnily enough they were terrified of anything resembling object oriented programming. If the word "class" appeared in the code base (their was some Python), they would quietly walk away.

What I saw was also incredible because these, largely junior, programmers were using types for exactly the thing old-Haskell people had hoped they would. Things would ship to prod lightning fast as all engineers had to do was make sure the types all lined up and the compiler was happy and they would send the PR off!

But then I saw the downside: these type-happy programmers almost never tested anything. I'm not talking about formal unit tests or integration tests, some of those existed. I mean these were programmers that had entirely lost (or maybe never had) the ability to play around with the code that they just wrote and make sure it worked. I kid you not, "print debugging" was viewed as some advanced technique to do in emergency situations. When bugs were introduced to prod I would ask "did this work when you ran it locally?" only to be met with quizzical stares. If it pasted the type check it was good to go.

It also had the negative consequence of inadvertently discouraging abstraction in favor of just adding more complexity to your existing types. Because refactoring code takes time and the entire point of the type check doing all your thinking is to ship fast.

All that said, I'd much rather work with that code base than one made by a similarly proficient team in say Ruby.

There are tons of skilled (and less skilled) functional programmers out there. The real problem is if you're looking for both highly competent programmers who also happened to be hung up on a particular niche language. I'm sure there are plenty of excellent "Gooby" engineers out there, but they likely choose jobs based on other factors than the language being used.

I acknowledge, however, a lot of people never think to do this when starting their business, and consequently run into all sorts of this kind of trouble, sadly.

Getting lost in the "tech $X is better for this than $Y" can easily become a distraction. Engineering is a form of applied science for money.

Since it's economically driven, the two most important things you as an engineer need to know are:

- who is paying for this?

- why?

Those two questions should underpin every single decision you make. If you lose sight of that, theres a huge chance you won't succeed.

A fair amount of this article is observing this problem persists 60 years later.

There’s plenty of mainstream programming languages that get the job done just fine without the hiring problems.

I’m 100% certain you don’t “need” gooby.

Hiring for gooby doesn’t scale, so unless your company’s goal is to stay small, don’t use gooby. And “the CTO likes it” isn’t good enough reason.

The original gooby loving CTO always leaves to spread more gooby to other companies and the owners of the company are left with a long term problem.

Just use the garden variety languages that there is a large talent pool for.

Do your gooby at home on your personal projects.

Hire people for embedded C and you will run into some some people to whom C programming and their side projects in it are more important than whatever you're trying to ship.

Substitute anything. Rust, C++, Ruby, Java, ...

And of course the resume stuffing (1) people are also a language-independent problem.

Certain languages probably won't have too many people in the (2) category (excited recent grads). But those are the good candidates in relation to (1) and (3), according to the Gooby analysis in the article.

Honestly we should have written it in C, but I'm too far down the totem pole to make that call

So, where's the difference? One doesn't care about what they sell as longs it makes them money, the other as long they have fun.

However, I think that we all need to be a little more honest with ourselves as software engineers. […] Are you sure you don't use Gooby just because it's fun to write?

Why? I use raku every day just because it’s fun to write!

No. I don’t do anything (by choice) if it is not fun.

I've certainly seen people in the Haskell teams I've worked on who fit the article's description of people who were there to write Haskell and didn't care about much else. It didn't go great, but they were a minority of the people I've worked with.

Importantly, I've also seen plenty of that kind of behavior in other teams using other tech stacks. I've worked with "Agile people" whose answer to every problem is pair programming. I've worked with people who only care about microservices, or their favorite frontend framework. I've worked with people who see more object orientation as the solution to every problem more often than I've seen people who want to apply FP to every problem.

A few of these people can be find to have on a medium or larger sized team- if the worst of their instincts are tempered they can be a great source of internal education and advocacy, and they can bring expertise that can help you deal with the inevitable problems and tradeoffs that come with any technical choice. You just need to be careful to, on balance, have a team of mostly product-minded people.

Product people aren't necessarily tech-stack agnostic. To use myself as an example, I really like functional programming and I think it's often a good technical choice. At the end of the day though, my job is a job and I'm there to build the best product I can to make my employer (and myself) money. I've turned down Haskell jobs because I didn't believe in the product or team, and taken jobs in less preferred tech stacks because I did. A lot of people can be both enthusiasts and pragmatists, you just need to look for them.

I think one of the biggest issues I have with the article is that it overlooks a significant source of hiring: product minded people who are open to, but not specifically enthusiastic about your tech stack. People don't need to be an FP enthusiast to work in a functional language. I've written a lot of Python and Go in my career, even though neither of them are my favorite language. By the same token, there are plenty of people who can work with Haskell, OCaml, or a lisp just fine with a bit of training even if FP isn't something they are going to devote themselves to. I've worked with a lot of people who do Haskell in their day job, but prefer to spend their free time using Rust.

None of this is to say that everyone should go out and use an FP language. I think the most important factor in picking a language is generally going to be picking something that your team likes and understands well. Most languages are good enough at most problems that individual preference is going to matter more than technical concerns. If Haskell or OCaml or Gooby is that preferred language for your team, I don't think you should avoid it.

I'm yet to meet an FP fanatic who actually properly understood OOP. Few seem to even understand the core principles of 'high cohesion, loose coupling' and fewer are even able translate that into a programming methodology.

My view of FP proponents is the opposite as the author claims. They're not rockstars who can master anything. More like the opposite; they're often people who are incapable of taking something complex and simplifying it. They're people who can't keep complexity under control and they need an external tool to do it for them.