3 ms·

> 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

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

riwsky 3y ago
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.
- ParetoOptimal 3y ago
  > 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.
  - riwsky 3y ago
    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”.
    - ghostwriter 3y ago
      > 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).
      - riwsky 3y ago
        > 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.
        ParetoOptimal 3y ago
        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: It's not what programming languages do, it's what they shepherd you to https://nibblestew.blogspot.com/2020/03/its-not-what-programming-languages-do.html https://nibblestew.blogspot.com/2020/03/its-not-what-program... 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".
- aranchelk 3y ago
  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.
  - riwsky 3y ago
    > 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.
    - aranchelk 3y ago
      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.
      - 3y ago

riwsky 3y ago

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.

ParetoOptimal 3y ago
> 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.
- riwsky 3y ago
  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”.
  - ghostwriter 3y ago
    > 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).
    - riwsky 3y ago
      > 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.
      - ParetoOptimal 3y ago
        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: It's not what programming languages do, it's what they shepherd you to https://nibblestew.blogspot.com/2020/03/its-not-what-programming-languages-do.html https://nibblestew.blogspot.com/2020/03/its-not-what-program... 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".
aranchelk 3y ago
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.
- riwsky 3y ago
  > 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.
  - aranchelk 3y ago
    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.
    - 3y ago