9 ms·

The Functional Programming Hiring Problem

108 points by _peeley 2y ago

coolThingsFirst 2y ago
Tldr: we want experts in our programming language but they charge a lot so it’s not good for our budget.
- deleted 2y ago
  [deleted]
- neeh0 2y ago
  That's very strange conclusion. I think only person with limited exposure to tech hiring can produce that.
tjbai 2y ago
> The multi-armed bandit is a really interesting problem in mathematical optimization... This problem is so interesting, in fact, that during World War II the Allies proposed air dropping copies of the original paper over Germany. The end result, or so it was theorized, was that German scientists would be so fascinated and distracted by the problem that they would abandon the war effort and cripple any German military research projects in the process. This is incredible
- chrisco255 2y ago
  Sounds like an impractical (and ineffective) idea that was never implemented, so not actually all that incredible. Rather boring, inconsequential anecdote that adds nothing to the discussion.
  - tjbai 2y ago
    Something can be inconsequential and yet still interesting/amusing
    - chrisco255 2y ago
      Is it amusing that someone suggested an impractical and ineffective idea once? There are billions more where that came from.
- lijok 2y ago
  I heard something similar about the collatz conjecture that it was pushed/popularized by soviets to distract western development
- bavell 2y ago
  Wait, they actually tried nerd sniping[0]?!? [0] https://xkcd.com/356 https://xkcd.com/356
- RheingoldRiver 2y ago
  Yeah, by far the highlight of the article for me. In the very abstract, the idea to stop destruction by inspiring creativity is kinda beautiful
- saithound 2y ago
  It's so incredible you should not believe it. Multi-armed bandits were introduced in the 50s, years after the end of World War 2.
  - _peeley 2y ago
    Pulling from this published source[0]: > As I said, the problem is a classic one; it was formulated during the war, and efforts to solve it so sapped the energies and minds of Allied analysts that the suggestion was made that the problem be dropped over Germany, as the ultimate instrument of intellectual sabotage. [0]: https://academic.oup.com/jrsssb/article-pdf/41/2/164/49097406/jrsssb_41_2_164.pdf https://academic.oup.com/jrsssb/article-pdf/41/2/164/4909740...
  - deleted 2y ago
    [deleted]
- kreetx 2y ago
  I would say "citation needed". Who said it? Where?
kccqzy 2y ago
This is just a hiring problem, not related to functional programming. I agree with the basic premise of the article however: depending on the financial condition of the company, hiring people who are overly attached to or obsessed with a single technology probably isn't a good idea. But that's of course not exclusive to functional programming. Right now you will find plenty of people obsessed with Rust (not a functional language) who don't care about the business goals and only want to write Rust. A few years ago it was Go. Before that it was Node.js. A few more years ago it was Ruby on Rails.
- lmm 2y ago
  Not sure if this was a deliberate bait to demonstrate the problem, but Rust is a functional language in the modern sense (it has most of ML's features).
- dboreham 2y ago
  For the casual reader: Rust is one of the most functional of the not-totally-functional languages.
  - CrimsonCape 2y ago
    For the casual reader, if you think Rust is a casual way to play with functional programming, you will encounter the lifetimes booby trap. It's almost always better to 'play' in a language that abstracts everything away except for the problem domain. Not like Rust, which introduces multiple complex language domains to learn before you can play wih your target domain.
- bri3d 2y ago
  This - I’ve had this same experience in both the FP, middle ground (Kotlin, Scala, etc.) and Rust space. It’s not FP, it’s that some engineers are interested in business goals and others are interested in conceptual goals. Those who are interested in conceptual goals gravitate towards conceptually interesting paradigms. Those who are interested in business goals gravitate towards business goals. It’s not mutually exclusive; I’ve met Scala and Rust obsessed engineers who also deliver; and Java engineers who can’t see past the next AbstractProxyFactory. But if I were forced to stereotype, new paradigms come with people who are more interested in the concepts than the goal (yes, I know FP isn’t new, blah blah, professionally speaking…)
wavemode 2y ago
The problem, as posed, seems to be "when you hire $LANG devs, all they want to do is write $LANG, even when $LANG is poorly suited to solving the problem at hand". 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.
- yarekt 2y ago
  As with everything, there’s some truth to that, but also C#’s json parsing libs are sub-par… and that’s really the least that a modern language should do well
  - rqtwteye 2y ago
    I think Newtonsoft is quite ok, but the MS library lacks a lot.
    - nathanaldensr 2y ago
      Your information is very out of date. Microsoft long ago worked with the Newtonsoft.Json creator when introducing their native .NET replacement for Newtonsoft.Json. Performance in the new set of libraries is excellent as they rely heavily on the newer performance primitives like Utf8String, Span, etc.
mjmsmith 2y ago
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.
BWStearns 2y ago
I work at a place that has ancestral Gooby code. It is truly horrific and an affront to whatever machine god (GPT-X?) may judge us in the future. The badness has literally nothing to do with the language. All the bad parts are due to the original team having reached for the most esoteric thing available at the time. I like playing with weird tech shit but there is a time and a place, and that place is not in prod for a startup. 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-budget https://steveklabnik.com/writing/the-language-strangeness-bu...
- pram 2y ago
  I've personally seen this, it can be pure goddamn cancer. The company hired a very smart charlatan and he convinced them to start a greenfield project in Haskell. Then they need to hire Haskell developers for this specific thing because everyone else only knows Java and Python. Nearly a year later they're barely getting started, but it's getting hyped like you couldn't believe. A lot of sprint planning time starts to become 'how do we start integrating [New thing]' because the Directors have been fluffing it so hard. Anyway it never got used in prod. The development turned into a disaster and the original guy quit. The team got dismantled and the whole thing got memory-holed. Anyone in the org hearing the word "Haskell" would invariably just think about it lol
  - BWStearns 2y ago
    Not even sure these guys fit the standard mantle of language hyping charlatans. Most of the catastrophic choices were things you could do in any language. With the bonus of no meaningful comments and just committing to master so there's no PR comment history to help the future team's archeology project.
ggm 2y ago
Hire from group #2
jll29 2y ago
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/ 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.
- downrightmike 2y ago
  When you have one expert in something, you'll need to back them up or replace them in the future. You're job is to find three or four people that are decent at thing, and then put them all on expert tasks, as a team, so they grow into experts. This also frees up your expert to do that level or higher work.
- singpolyma3 2y ago
  I'm always surprised when I see this approach to hiring. I have a lot of Haskell in the codebase at my current company. It hrs never occured to me to try to hire from the "Haskell community" we always hire from our product community because tech is easier to teach than product.
DrDroop 2y ago
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.
sesm 2y ago
Hiring open source rockstars is problematic, so is hiring resume-driven trend-chasers. 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.
- warcher 2y ago
  At this point pretty much any language you want to pick for me is a couple weeks’ ramp up time. I couldn’t really care less. What’s the right language? Probably the language you’re already using for the rest of your stuff so we can interface with the rest of the org efficiently. Is it new? Grab whatever the industry standard is for your segment. Lots of libs, lots of mindshare, easy to hire, get it done. I do get caught in HR filters a lot without a bunch of projects in gooby though.
  - singpolyma3 2y ago
    > At this point pretty much any language you want to pick for me is a couple weeks’ ramp up time. I couldn’t really care less. This is the right attitude
    - warcher 2y ago
      It’s just not that hard. Problem domains are hard. If you asked me to work in computer vision that’d be hard for me. Same for high frequency trading. Asking me to write this device driver in rust versus nasty old C, whatever man, bits is bits. I lie about my experience in different stacks solving the same old troubles all the time. Languages are boring. Problem domains can be a lot of fun.
  - aleph_minus_one 2y ago
    > At this point pretty much any language you want to pick for me is a couple weeks’ ramp up time. I couldn’t really care less. When you learn a programming language for a few weeks, the knowledge will be very superficial. Rather consider a few years of additional learning outside and in addition to the job to be realistic to get a decent understanding of the very encompassing and non-trivial details of the programming language, its lore, its culture and its often huge ecosystem.
PheonixPharts 2y ago
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.
- snapdaddy 2y ago
  That's a really interesting data point about your experience with TypeScript. I'm going to have to file that away as something that I'm not sure what to do with right now, but also as an interesting thought to keep in mind going forwards.
jsyang00 2y ago
The author brings up some good points here, but I would just make sure to build my business around trading obscure financial instruments in a clever way, so as to generate such an overwhelming amount of profit that we can singlehandedly rewrite and maintain everything in our stack from scratch. 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.
- eric-hu 2y ago
  Is this a reference to one particular company/language?
  - Hasnep 2y ago
    Sounds a bit like Jane Street with OCaml
jongjong 2y ago
The way I see it, functional programming converts are often people who failed to properly grasp other, more challenging methodologies and decided that they need training wheels on their bikes. Though they won't frame it that way of course; they'll say that other methodologies lack the 'proper guardrails' which is telling... 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.
- nisa 2y ago
  Interesting take and it feels familiar. I'm definitely in the "I need a tool to keep complexity under control" camp but I don't see it as a bad thing. Coming from a support and sysadmin/ops position seeing the same kind of problem every time makes you want to avoid the problem class. Of course it's often a fantasy. However I realized most problems I experienced were due to a general lack of understanding of the tools and concepts used. This was Java, Spring Framework, Aspect Oriented Programming and an ORM wrapper (MyBATIS) and 99% of my ops problems were due to the devs working around and against these concepts and tools with lots of bad code and so many NPE's that I still get nightmares. A skilled crew of veterans familiar with i.e. Spring, MyBATIS could have refactored this in a few months and most problems would be gone just using each tool how it was meant to be used. But we only added poorly understood layers upon poorly understood layers... I understand everyone that goes into functional programming after realizing classes of problems don't exist there. I like guardrails. I learned to like immutable functional data structures after realizing 70% of time is Java serialization in the flame graph and I'd rather had the clojure way of solving these problems instead of the hidden magic. But properly learning all the mentioned tools and not abusing them would be enough.
- danielscrubs 2y ago
  Do you have a great example of a code base that meets your ideals? I think one of the problems is that we just don’t have people that we admire in programming compared to other areas like biology or literature.
joe_the_user 2y ago
The classic story is how pg created a storefront in lisp that he sold to yahoo. Yahoo couldn't hire lisp programmers and rewrote it in another language (c++?) and it wasn't as good. But the decision still made sense from a business perspective. 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.
- MajimasEyepatch 2y ago
  The problem is not with opinionated engineers. (Almost every engineer I know is opinionated; the ones who are not tend not to be very good.) The problem is with engineers who are excessively opinionated about the wrong things. Having opinions about the product is way more valuable than being obsessed with writing the umpteenth JSON parsing library in Gooby because the others aren’t built exactly the way you’d build it.
  - aleph_minus_one 2y ago
    > Having opinions about the product is way more valuable Be careful with this statement: many programmers value very different properties of the product than the typical customer.
- resonious 2y ago
  Reminds me also of Figma converting all of their custom language stuff into Typescript, even though Typescript is slower.
readthenotes1 2y ago
One of brooks's papers (the guy that brooks's law is named after) is about how software developers would rather write the tools to solve the problem and then solve the problem itself. A fair amount of this article is observing this problem persists 60 years later.
- skydhash 2y ago
  > how software developers would rather write the tools to solve the problem and then solve the problem itself. That's because you know you'll be stuck with maintaining the solution. Nowadays, we have resume-driven people that just build stuff without any care as they know they're only here for two or three years.
labradore 2y ago
Just like functional programming itself, if you keep your hiring within some practical boundaries, you'll not go far wrong.
agentultra 2y ago
Sometimes just using the language the majority of folks enjoy working in is fine. 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.
banish-m4 2y ago
4. They're SREs/PEs who mastered concepts in breadth of many languages and depth down the stack. Some us are even EEs who can do EDA work too for your custom hardware devices and write custom kernel modules.
lll-o-lll 2y ago
This is a problem that extends far beyond “esoteric language of choice”. It’s the challenge of being a nerd in a boring business world. 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.
- aleph_minus_one 2y ago
  > 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. I think the problem rather is that many "business people" have a deep hate against people who love to think about whether there is a deeper hidden mathematical structure behind the business problems. Just to be clear: there also exist some few business people who appreciate this, but the latter are typically "nerds" who mostly switched to business because it pays much better. It's not my experience that the latter group of programmers ignores the business problems, they just rather have their own much less anti-intellectual way of approaching them.
  - deleted 2y ago
djaouen 2y ago
>Are you sure you aren’t just using Gooby because it is fun? No. I don’t do anything (by choice) if it is not fun.
- iLemming 2y ago
  Exactly this. I'm indifferent to the most popular, ubiquitous, top-10-on-every-X-list trends. It's a pattern: something gains massive adoption only to fizzle out a few years later. XML, the one-size-fits-all OOP, all-in microservices, Silverlight, Flash, etc. Usually, there are some good, pragmatic reasons why something gets selected, and it is always accompanied by trade-offs. The decision is not mine alone to make; we need buy-in from everyone on the team. If the choice turns out to be not very delightful or fun, it becomes obvious - replace it. My initial reaction to the question "Why are you using Gooby? I've never even heard about it..." is always "because it's fun" And it is absolutely normal to become a team where everyone enjoys Gooby, and they'd try to hire like-minded people.
juancn 2y ago
Language or any other technology you choose has the same problem. 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.
throwawaymaths 2y ago
I'm actually suffering from the opposite problem. CTO is a well known Gooby developer. But we wrote everything in C++ because "it will be easier to hire down the line", pulling in well known C++ libraries by various bigcos that actually don't compose together and make a royal mess of the codebase. We've missed every single deadline, and are light years behind where we should be. Honestly we should have written it in C, but I'm too far down the totem pole to make that call
- nicce 2y ago
  Now, the correct comment in this context; why not Rust?
  - throwawaymaths 2y ago
    I shudder to think of the levels of architecture astronaut that the CTO would rise to if we put rust in his hands
redpoint 2y ago
There's another side to this where one attempts to take the pragmatic or business value view (it' seems so obvious to) and is met with ostracism by those that are entrenched in a specific technology.
rebeccaskinner 2y ago
I've been on several sides of this issue. I've been using Haskell for around 16 years, and I currently work on a product that's written almost entirely in Haskell on the backend. I've worked in a variety of languages throughout my career, and I've taken plenty of jobs that involved no FP at all, jobs that involved a mix of languages, and some that were primarily Haskell. 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.
andrewstuart 2y ago
In 2024 it is irresponsible to start that company off using gooby. 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.
- throwaway2037 2y ago
  This is a good post with good points. What languages do you consider "garden variety" these days? For me: JavaScript/TypeScript, Java, C#, Python, Ruby. Unless you have very specific systems programming needs, I would avoid C++ and Rust, as once the project grows complex enough, you need to hire very skills (read: expensive) engineers.
throwaway2037 2y ago
The blog post has some reference numbers embedded, but I cannot find the references below. (Did I miss something?) Specifically, the author hinted about a language and a company for #1. I guess this is Jane Street with OCaml? To be clear, you can make any insane language choice that you wish, so long as you pay so much money that no one will care. Exhibit A: Jane Street with OCaml
- _peeley 2y ago
  Ah, I think you're referencing the sidenotes. Sometimes the website doesn't render properly on mobile (I've tried getting click-to-expand working, but it's tricky), so try reading in desktop mode. Regarding sidenote #1, I actually very deliberately did not mention the language or company ;) Here's the full text of the sidenote, if you're still unable to get it rendering: > I'm not going to name the language itself, because this post would just turn into a flame war over that language specifically, and I definitely don't want to cast shade on any language/community in particular. I'm also kind of hoping that the most annoying people read this and think, "Ah, of course he's talking about that language over there! This criticism obviously doesn't apply to my perfect and favorite language!" Regardless, I feel that the thesis and content of this post applies pretty evenly to most functional programming languages.
kazinator 2y ago
Here is the problem in the article: nearly every language is going to have the (3) people. 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.
_xiaz 2y ago
Great post and very relatable. I too had my phase with a month of Haskell and then many more with Clojure. Even some other lisp exploration. It's a lot of fun, but I've since come to terms that from a career and business perspective I'm better off writing Python or Shell. (I'm a Infra/Devops guy, if it matters)
librasteve 2y ago
An insightful post, this point resonated with me in particular… 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!
kiviuq 2y ago
That's the thing, though. Gooby is just a means to an end; the ultimate end goal of your company is to write software that is useful to people and makes money. For the zealots, however, Gooby is the end in and of itself. 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.

108 points by _peeley 2y ago

coolThingsFirst 2y ago

Tldr: we want experts in our programming language but they charge a lot so it’s not good for our budget.

deleted 2y ago
[deleted]
neeh0 2y ago
That's very strange conclusion. I think only person with limited exposure to tech hiring can produce that.

tjbai 2y ago

> The multi-armed bandit is a really interesting problem in mathematical optimization... This problem is so interesting, in fact, that during World War II the Allies proposed air dropping copies of the original paper over Germany. The end result, or so it was theorized, was that German scientists would be so fascinated and distracted by the problem that they would abandon the war effort and cripple any German military research projects in the process. This is incredible

chrisco255 2y ago
Sounds like an impractical (and ineffective) idea that was never implemented, so not actually all that incredible. Rather boring, inconsequential anecdote that adds nothing to the discussion.
- tjbai 2y ago
  Something can be inconsequential and yet still interesting/amusing
  - chrisco255 2y ago
    Is it amusing that someone suggested an impractical and ineffective idea once? There are billions more where that came from.
lijok 2y ago
I heard something similar about the collatz conjecture that it was pushed/popularized by soviets to distract western development
bavell 2y ago
Wait, they actually tried nerd sniping[0]?!? [0] https://xkcd.com/356 https://xkcd.com/356
RheingoldRiver 2y ago
Yeah, by far the highlight of the article for me. In the very abstract, the idea to stop destruction by inspiring creativity is kinda beautiful
saithound 2y ago
It's so incredible you should not believe it. Multi-armed bandits were introduced in the 50s, years after the end of World War 2.
- _peeley 2y ago
  Pulling from this published source[0]: > As I said, the problem is a classic one; it was formulated during the war, and efforts to solve it so sapped the energies and minds of Allied analysts that the suggestion was made that the problem be dropped over Germany, as the ultimate instrument of intellectual sabotage. [0]: https://academic.oup.com/jrsssb/article-pdf/41/2/164/49097406/jrsssb_41_2_164.pdf https://academic.oup.com/jrsssb/article-pdf/41/2/164/4909740...
- deleted 2y ago
  [deleted]
kreetx 2y ago
I would say "citation needed". Who said it? Where?

kccqzy 2y ago

This is just a hiring problem, not related to functional programming. I agree with the basic premise of the article however: depending on the financial condition of the company, hiring people who are overly attached to or obsessed with a single technology probably isn't a good idea. But that's of course not exclusive to functional programming. Right now you will find plenty of people obsessed with Rust (not a functional language) who don't care about the business goals and only want to write Rust. A few years ago it was Go. Before that it was Node.js. A few more years ago it was Ruby on Rails.

lmm 2y ago
Not sure if this was a deliberate bait to demonstrate the problem, but Rust is a functional language in the modern sense (it has most of ML's features).
dboreham 2y ago
For the casual reader: Rust is one of the most functional of the not-totally-functional languages.
- CrimsonCape 2y ago
  For the casual reader, if you think Rust is a casual way to play with functional programming, you will encounter the lifetimes booby trap. It's almost always better to 'play' in a language that abstracts everything away except for the problem domain. Not like Rust, which introduces multiple complex language domains to learn before you can play wih your target domain.
bri3d 2y ago
This - I’ve had this same experience in both the FP, middle ground (Kotlin, Scala, etc.) and Rust space. It’s not FP, it’s that some engineers are interested in business goals and others are interested in conceptual goals. Those who are interested in conceptual goals gravitate towards conceptually interesting paradigms. Those who are interested in business goals gravitate towards business goals. It’s not mutually exclusive; I’ve met Scala and Rust obsessed engineers who also deliver; and Java engineers who can’t see past the next AbstractProxyFactory. But if I were forced to stereotype, new paradigms come with people who are more interested in the concepts than the goal (yes, I know FP isn’t new, blah blah, professionally speaking…)

wavemode 2y ago

The problem, as posed, seems to be "when you hire $LANG devs, all they want to do is write $LANG, even when $LANG is poorly suited to solving the problem at hand". 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.

yarekt 2y ago
As with everything, there’s some truth to that, but also C#’s json parsing libs are sub-par… and that’s really the least that a modern language should do well
- rqtwteye 2y ago
  I think Newtonsoft is quite ok, but the MS library lacks a lot.
  - nathanaldensr 2y ago
    Your information is very out of date. Microsoft long ago worked with the Newtonsoft.Json creator when introducing their native .NET replacement for Newtonsoft.Json. Performance in the new set of libraries is excellent as they rely heavily on the newer performance primitives like Utf8String, Span, etc.

mjmsmith 2y ago

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.

BWStearns 2y ago

I work at a place that has ancestral Gooby code. It is truly horrific and an affront to whatever machine god (GPT-X?) may judge us in the future. The badness has literally nothing to do with the language. All the bad parts are due to the original team having reached for the most esoteric thing available at the time. I like playing with weird tech shit but there is a time and a place, and that place is not in prod for a startup. 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-budget https://steveklabnik.com/writing/the-language-strangeness-bu...

pram 2y ago
I've personally seen this, it can be pure goddamn cancer. The company hired a very smart charlatan and he convinced them to start a greenfield project in Haskell. Then they need to hire Haskell developers for this specific thing because everyone else only knows Java and Python. Nearly a year later they're barely getting started, but it's getting hyped like you couldn't believe. A lot of sprint planning time starts to become 'how do we start integrating [New thing]' because the Directors have been fluffing it so hard. Anyway it never got used in prod. The development turned into a disaster and the original guy quit. The team got dismantled and the whole thing got memory-holed. Anyone in the org hearing the word "Haskell" would invariably just think about it lol
- BWStearns 2y ago
  Not even sure these guys fit the standard mantle of language hyping charlatans. Most of the catastrophic choices were things you could do in any language. With the bonus of no meaningful comments and just committing to master so there's no PR comment history to help the future team's archeology project.

ggm 2y ago

Hire from group #2

jll29 2y ago

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/ 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.

downrightmike 2y ago
When you have one expert in something, you'll need to back them up or replace them in the future. You're job is to find three or four people that are decent at thing, and then put them all on expert tasks, as a team, so they grow into experts. This also frees up your expert to do that level or higher work.
singpolyma3 2y ago
I'm always surprised when I see this approach to hiring. I have a lot of Haskell in the codebase at my current company. It hrs never occured to me to try to hire from the "Haskell community" we always hire from our product community because tech is easier to teach than product.

DrDroop 2y ago

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.

sesm 2y ago

Hiring open source rockstars is problematic, so is hiring resume-driven trend-chasers. 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.

warcher 2y ago
At this point pretty much any language you want to pick for me is a couple weeks’ ramp up time. I couldn’t really care less. What’s the right language? Probably the language you’re already using for the rest of your stuff so we can interface with the rest of the org efficiently. Is it new? Grab whatever the industry standard is for your segment. Lots of libs, lots of mindshare, easy to hire, get it done. I do get caught in HR filters a lot without a bunch of projects in gooby though.
- singpolyma3 2y ago
  > At this point pretty much any language you want to pick for me is a couple weeks’ ramp up time. I couldn’t really care less. This is the right attitude
  - warcher 2y ago
    It’s just not that hard. Problem domains are hard. If you asked me to work in computer vision that’d be hard for me. Same for high frequency trading. Asking me to write this device driver in rust versus nasty old C, whatever man, bits is bits. I lie about my experience in different stacks solving the same old troubles all the time. Languages are boring. Problem domains can be a lot of fun.
- aleph_minus_one 2y ago
  > At this point pretty much any language you want to pick for me is a couple weeks’ ramp up time. I couldn’t really care less. When you learn a programming language for a few weeks, the knowledge will be very superficial. Rather consider a few years of additional learning outside and in addition to the job to be realistic to get a decent understanding of the very encompassing and non-trivial details of the programming language, its lore, its culture and its often huge ecosystem.

PheonixPharts 2y ago

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.

snapdaddy 2y ago
That's a really interesting data point about your experience with TypeScript. I'm going to have to file that away as something that I'm not sure what to do with right now, but also as an interesting thought to keep in mind going forwards.

jsyang00 2y ago

The author brings up some good points here, but I would just make sure to build my business around trading obscure financial instruments in a clever way, so as to generate such an overwhelming amount of profit that we can singlehandedly rewrite and maintain everything in our stack from scratch. 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.

eric-hu 2y ago
Is this a reference to one particular company/language?
- Hasnep 2y ago
  Sounds a bit like Jane Street with OCaml

jongjong 2y ago

The way I see it, functional programming converts are often people who failed to properly grasp other, more challenging methodologies and decided that they need training wheels on their bikes. Though they won't frame it that way of course; they'll say that other methodologies lack the 'proper guardrails' which is telling... 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.

nisa 2y ago
Interesting take and it feels familiar. I'm definitely in the "I need a tool to keep complexity under control" camp but I don't see it as a bad thing. Coming from a support and sysadmin/ops position seeing the same kind of problem every time makes you want to avoid the problem class. Of course it's often a fantasy. However I realized most problems I experienced were due to a general lack of understanding of the tools and concepts used. This was Java, Spring Framework, Aspect Oriented Programming and an ORM wrapper (MyBATIS) and 99% of my ops problems were due to the devs working around and against these concepts and tools with lots of bad code and so many NPE's that I still get nightmares. A skilled crew of veterans familiar with i.e. Spring, MyBATIS could have refactored this in a few months and most problems would be gone just using each tool how it was meant to be used. But we only added poorly understood layers upon poorly understood layers... I understand everyone that goes into functional programming after realizing classes of problems don't exist there. I like guardrails. I learned to like immutable functional data structures after realizing 70% of time is Java serialization in the flame graph and I'd rather had the clojure way of solving these problems instead of the hidden magic. But properly learning all the mentioned tools and not abusing them would be enough.
danielscrubs 2y ago
Do you have a great example of a code base that meets your ideals? I think one of the problems is that we just don’t have people that we admire in programming compared to other areas like biology or literature.

joe_the_user 2y ago

The classic story is how pg created a storefront in lisp that he sold to yahoo. Yahoo couldn't hire lisp programmers and rewrote it in another language (c++?) and it wasn't as good. But the decision still made sense from a business perspective. 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.

MajimasEyepatch 2y ago
The problem is not with opinionated engineers. (Almost every engineer I know is opinionated; the ones who are not tend not to be very good.) The problem is with engineers who are excessively opinionated about the wrong things. Having opinions about the product is way more valuable than being obsessed with writing the umpteenth JSON parsing library in Gooby because the others aren’t built exactly the way you’d build it.
- aleph_minus_one 2y ago
  > Having opinions about the product is way more valuable Be careful with this statement: many programmers value very different properties of the product than the typical customer.
resonious 2y ago
Reminds me also of Figma converting all of their custom language stuff into Typescript, even though Typescript is slower.

readthenotes1 2y ago

One of brooks's papers (the guy that brooks's law is named after) is about how software developers would rather write the tools to solve the problem and then solve the problem itself. A fair amount of this article is observing this problem persists 60 years later.

skydhash 2y ago
> how software developers would rather write the tools to solve the problem and then solve the problem itself. That's because you know you'll be stuck with maintaining the solution. Nowadays, we have resume-driven people that just build stuff without any care as they know they're only here for two or three years.

labradore 2y ago

Just like functional programming itself, if you keep your hiring within some practical boundaries, you'll not go far wrong.

agentultra 2y ago

Sometimes just using the language the majority of folks enjoy working in is fine. 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.

banish-m4 2y ago

4. They're SREs/PEs who mastered concepts in breadth of many languages and depth down the stack. Some us are even EEs who can do EDA work too for your custom hardware devices and write custom kernel modules.

lll-o-lll 2y ago

This is a problem that extends far beyond “esoteric language of choice”. It’s the challenge of being a nerd in a boring business world. 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.

aleph_minus_one 2y ago
> 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. I think the problem rather is that many "business people" have a deep hate against people who love to think about whether there is a deeper hidden mathematical structure behind the business problems. Just to be clear: there also exist some few business people who appreciate this, but the latter are typically "nerds" who mostly switched to business because it pays much better. It's not my experience that the latter group of programmers ignores the business problems, they just rather have their own much less anti-intellectual way of approaching them.
- deleted 2y ago

djaouen 2y ago

>Are you sure you aren’t just using Gooby because it is fun? No. I don’t do anything (by choice) if it is not fun.

iLemming 2y ago
Exactly this. I'm indifferent to the most popular, ubiquitous, top-10-on-every-X-list trends. It's a pattern: something gains massive adoption only to fizzle out a few years later. XML, the one-size-fits-all OOP, all-in microservices, Silverlight, Flash, etc. Usually, there are some good, pragmatic reasons why something gets selected, and it is always accompanied by trade-offs. The decision is not mine alone to make; we need buy-in from everyone on the team. If the choice turns out to be not very delightful or fun, it becomes obvious - replace it. My initial reaction to the question "Why are you using Gooby? I've never even heard about it..." is always "because it's fun" And it is absolutely normal to become a team where everyone enjoys Gooby, and they'd try to hire like-minded people.

juancn 2y ago

Language or any other technology you choose has the same problem. 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.

throwawaymaths 2y ago

I'm actually suffering from the opposite problem. CTO is a well known Gooby developer. But we wrote everything in C++ because "it will be easier to hire down the line", pulling in well known C++ libraries by various bigcos that actually don't compose together and make a royal mess of the codebase. We've missed every single deadline, and are light years behind where we should be. Honestly we should have written it in C, but I'm too far down the totem pole to make that call

nicce 2y ago
Now, the correct comment in this context; why not Rust?
- throwawaymaths 2y ago
  I shudder to think of the levels of architecture astronaut that the CTO would rise to if we put rust in his hands

redpoint 2y ago

There's another side to this where one attempts to take the pragmatic or business value view (it' seems so obvious to) and is met with ostracism by those that are entrenched in a specific technology.

rebeccaskinner 2y ago

I've been on several sides of this issue. I've been using Haskell for around 16 years, and I currently work on a product that's written almost entirely in Haskell on the backend. I've worked in a variety of languages throughout my career, and I've taken plenty of jobs that involved no FP at all, jobs that involved a mix of languages, and some that were primarily Haskell. 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.

andrewstuart 2y ago

In 2024 it is irresponsible to start that company off using gooby. 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.

throwaway2037 2y ago
This is a good post with good points. What languages do you consider "garden variety" these days? For me: JavaScript/TypeScript, Java, C#, Python, Ruby. Unless you have very specific systems programming needs, I would avoid C++ and Rust, as once the project grows complex enough, you need to hire very skills (read: expensive) engineers.

throwaway2037 2y ago

The blog post has some reference numbers embedded, but I cannot find the references below. (Did I miss something?) Specifically, the author hinted about a language and a company for #1. I guess this is Jane Street with OCaml? To be clear, you can make any insane language choice that you wish, so long as you pay so much money that no one will care. Exhibit A: Jane Street with OCaml

_peeley 2y ago
Ah, I think you're referencing the sidenotes. Sometimes the website doesn't render properly on mobile (I've tried getting click-to-expand working, but it's tricky), so try reading in desktop mode. Regarding sidenote #1, I actually very deliberately did not mention the language or company ;) Here's the full text of the sidenote, if you're still unable to get it rendering: > I'm not going to name the language itself, because this post would just turn into a flame war over that language specifically, and I definitely don't want to cast shade on any language/community in particular. I'm also kind of hoping that the most annoying people read this and think, "Ah, of course he's talking about that language over there! This criticism obviously doesn't apply to my perfect and favorite language!" Regardless, I feel that the thesis and content of this post applies pretty evenly to most functional programming languages.

kazinator 2y ago

Here is the problem in the article: nearly every language is going to have the (3) people. 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.

_xiaz 2y ago

Great post and very relatable. I too had my phase with a month of Haskell and then many more with Clojure. Even some other lisp exploration. It's a lot of fun, but I've since come to terms that from a career and business perspective I'm better off writing Python or Shell. (I'm a Infra/Devops guy, if it matters)

librasteve 2y ago

An insightful post, this point resonated with me in particular… 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!

kiviuq 2y ago

That's the thing, though. Gooby is just a means to an end; the ultimate end goal of your company is to write software that is useful to people and makes money. For the zealots, however, Gooby is the end in and of itself. 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.