6 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 c

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.

ParetoOptimal 3y ago
> 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).

ParetoOptimal 3y ago

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