The Functional Programming Hiring Problem

If you've already decided to use Gooby, a senior engineer who has already made significant contributions to successful Gooby projects seems like an ideal hire. If you haven't decided to use it, it's a waste of their talents, which they're letting you know before you hire them.

Hire from group #2

In 2005, I needed to hire a Haskell dev with deep NLP expertise to replace a member of my startup team.

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 used to be more into functional programming but then I found other excuses to learn mathematics. I still think about how my imperative implementation can be turned into a functional one, or the other way around, but honestly the computer graphics programmers and machine learning engineers are doing cooler stuff. Even learning about category theory without needing to have an excuse to implement it makes it a lot more enjoyable.

Is this written from a different time line were TypeScript doesn't exist?

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.