Subtle correction: as far as I’m aware if you were to disable lazy evaluation (which you can now do via compiler pragma) on any Haskell program of significant complexity it would blow up. Common practice is to force evaluation of critical sections of code. That’s something the compiler can sometimes do for you.
Laziness in Haskell is a great way to write declarative code, you really are describing a concept rather that telling the computer what to do. That can lead to very clear and orderly source code.
Having said that, the drawbacks are significant, performance, memory usage, and debugging can all be a real pain. The last one sucks because it affects development of all kinds of programs, not just performance critical (and challenged) ones.
Shout out for PureScript, which is essentially a strictly evaluated Haskell that runs on the browser, servers, and PaaS.
Difficulty hiring on a small scale in my experience is complete BS, there are still many passionate users looking for professional gigs. Once that pool is exhausted, I think a company should probably look outside the language for people with some type of FP experience and expect language-specific training as part of onboarding, whether that’s worth the time and cost is entirely settled for me but certainly a topic for debate.
> Subtle correction: as far as I’m aware if you were to disable lazy evaluation (which you can now do via compiler pragma) on any Haskell program of significant complexity it would blow up. Common practice is to force evaluation of critical sections of code. That’s something the compiler can sometimes do for you.
Anecdotally I can confirm this is true.
> Laziness in Haskell is a great way to write declarative code, you really are describing a concept rather that telling the computer what to do. That can lead to very clear and orderly source code.
100% agree.
> Having said that, the drawbacks are significant, performance, memory usage, and debugging can all be a real pain. The last one sucks because it affects development of all kinds of programs, not just performance critical (and challenged) ones.
I think this largely depends on domain. Then, it's not clear if the best tradeoff is to go fully strict or develop better intuition for lazy evaluation in many of those cases.
> Difficulty hiring on a small scale in my experience is complete BS
I have a theory this meme is repeated by people who don't know where to find the many functional programming candidates.
If a candidate is primarily interested in your company because of your particular tech stack, they are probably the wrong candidate.
If your company needs to find candidates primarily on the basis of their familiarity with your particular tech stack, that is probably the wrong tech stack.
> If a candidate is primarily interested in your company because of your particular tech stack, they are probably the wrong candidate.
I disagree. I believe that most candidates are likely only interested in your salary, benefits, or other things not relevant to what your company does. A necessary state of affairs where worker rights and worker loyalty don't count for much in the face of the horribly named "right-to-work" laws.
Therefore a candidate that has a strong interest because of your tech stack is a positive where there wouldn't otherwise be one.
I agree that “here for the tech stack” is generally better than “here for the money”, but I’ve just been fortunate enough to work in situations where people were there for the mission and there for the people. It’s also really hard to blame people for being there for the money when, hey, we don’t know what kind of student loans or life financial situation they have. And when you don’t know a domain or company really well, “we pay more” is a harder-to-forge signal about prospective coworker quality than “oh our mission is really inspiring”.
> I’ve just been fortunate enough to work in situations where people were there for the mission and there for the people.
How is "being there for the mission and for the people" better than "being there for money and for tech stack"? The latter also has to do with people and missions, only the missions and the people are important and related to the candidate directly, and not through company owners' or hiring managers' goals (most likely motivated by prospects of monetary rewards too).
> How is "being there for the mission and for the people" better than "being there for money and for tech stack"
Tech stacks change; human stacks stay the same. Intellectual honesty isn't going to obsoleted by some shinier virtue in 5 years—and if a company needs to pivot, it's still going to be a right tool for the job.
Typically tech stacks don't change for good reasons, just subjective reasons.
Why should I value the subjective decision of some new engineering manager that decided the tech stack should change so they can pad their resume?
Even if I'm there for the mission, this would give me pause.
If I was there for the tech stack alone, I'd quickly be looking for a new job.
The central point you seem to be making is "hiring for people there for the mission means employees friendlier to company changes/pivots". This feels valid, however the tech stack could affect execution of the mission. Or a given person could just hold the opinion that tech stack affects execution of the mission.
I guess my counter-argument to that then is it's not such a straight-forward win.
However my views are that tech stacks and programming languages matter a lot more than most give them credit for. See:
So it's easy for me to recoil to hearing "right tool for the job" cargo-culted without real arguments justifying the comment.
Circling back to the central point, I do think I would bias towards hiring people that seem "there for the mission". I believe many people would probably be just pretending though, so it's not that great of a postive signal imo.
However we may differ in that I don't think I'd heavily avoid hiring people "there for the tech stack" any more than I'd try (and fail) to avoid hiring people "there for the money".
I think where we're ending up here is that—while all these points ("tool for the job", "here for the mission") may be true—they are often cited by people who are full of shit, so seeing them in job postings, interviews, etc doesn't really send any useful signal.
If you're working at a for-profit corporation, "the mission" is "money", so there's no distinction between "here for the mission" or "here for the money". Anyone who says otherwise is either naive about what the mission is, or lying (which I can't blame them for, because that's often the politically savvy move). Exceptions exist, but they're temporary because competition usually kills them.
Sadly, the mission is often money at nonprofits as well, because capitalism won't let you survive without it. But the "here for the mission" folks skew a lot more toward the "naive" side of the spectrum than the "lying" side. Again, exceptions exist.
I’ve seen versions of the first statement several times from different users on HN, so know I’m not singling you out, but I believe this to be a deeply flawed view:
It’s not the candidate’s job to be interested in your company. As a founder, leader, or even hiring manager it’s your job. Create a positive working environment. Get to know your employees and what their goals and interest are. Do your best to find ways to incorporate their interests into their work and align it with the company’s needs. Build rapport and treat them with respect, so when you must ask them to do tasks that don’t align with their long term goals they won’t resent you.
If you can use your tech stack to get desirable talent in the door, that’s excellent. Now it’s your job to retain them, keep them productive and happy.
Regarding your second statement, every job ad I’ve ever seen for software engineering contains a list of preferable languages and libraries, and I’ve never doubted that all things being equal, preference would be given to candidates with greater familiarity in that stack. Should it ever the primary criterion for hiring? Probably not.
> It’s not the candidate’s job to be interested in your company. As a founder, leader, or even hiring manager it’s your job.
It’s my job to do that for the right candidates. Positive working environment, caring about employee growth, long term goals—all these things you mention are extremely important, and they are what we should be competing on. If an engineer would forgo an opportunity that provides those just so they can compose monoids in the category of endofunctors, that’s unfortunate—but I am under no obligation to indulge them.
> Should it ever the primary criterion for hiring? Probably not.
I explicitly referred to when it’s the primary concern; we don’t disagree here.
Surely there must be some lower bound of technology after which a candidate can be completely excused for turning down a job regardless of the factors you have said should be their criteria. Examples: Perl, COBOL, or punch cards.
There is—at which point you need to find candidates primarily by their willingness to work with your tech stack, which means you probably have the wrong tech stack. It's not like leadership at punchcard-dependent firms disagree, and think their tech stack is great; they just can't switch that choice on a dime, and often need those punchcard experts specifically for the get-of-the-punchcards effort.
Laziness in Haskell is a great way to write declarative code, you really are describing a concept rather that telling the computer what to do. That can lead to very clear and orderly source code.
Having said that, the drawbacks are significant, performance, memory usage, and debugging can all be a real pain. The last one sucks because it affects development of all kinds of programs, not just performance critical (and challenged) ones.
Shout out for PureScript, which is essentially a strictly evaluated Haskell that runs on the browser, servers, and PaaS.
Difficulty hiring on a small scale in my experience is complete BS, there are still many passionate users looking for professional gigs. Once that pool is exhausted, I think a company should probably look outside the language for people with some type of FP experience and expect language-specific training as part of onboarding, whether that’s worth the time and cost is entirely settled for me but certainly a topic for debate.