4 ms·

The main reason for that phenomenon is it's more personally advantageous to rewrite than to learn Haskell and extend what's there. Haskell advocate quits? Blam

The main reason for that phenomenon is it's more personally advantageous to rewrite than to learn Haskell and extend what's there. Haskell advocate quits? Blame them for selfishly using a toy language (they're gone anyways - who is gonna disagree?), and save the day by spending a long time reimplementing an MVP subset of what they already did. Congrats - you're a hero! The end product has less functionality, but at least you didn't have to do something actually hard like learn Haskell and work with Someone Else's Code. I've seen this happen multiple times. For shame - and yes people did get promotions for it. Pathetic.

taeric 5y ago
That would be the sad case. I have also seen the case where the code was impenetrable and did not at all lend itself to extension.
- whateveracct 5y ago
  I've worked on a Haskell project supposedly like that. Took me a couple weeks of not complaining to improve it significantly. The trick was not closing my eyes at the sight of ugly bad code.
  - taeric 5y ago
    My problem with this, is you can replace "Haskell" with any other language in that sentence, and it still works.
    - whateveracct 5y ago
      Why's that a problem? It is true if any language. But people act like Haskell can create a mess that is beyond what other languages can create. To the point where it isn't true that you can just..fix it by not complaining.
      - taeric 5y ago
        Hmmm. I can see your point that folks act like it can create a mess beyond other languages. I agree that that is not accurate. I suspect it is more a reaction to the seeming claim that it is immune to that. For my part, my claim was meant to be that it needs an advocate. That is all. I do not know why they other languages have in built advocacy across the board. Python, in particular, is seeing a ton of good will in ways I just don't understand.
ramesh31 5y ago
>The end product has less functionality, but at least you didn't have to do something actually hard like learn Haskell and work with Someone Else's Code. But did the business need all of that functionality? Rewriting a subset of an application that is far more maintainable and cost effective in the long run can be a huge win. I am currently rebuilding an application full of intractable bugs and proprietary DSLs that was implemented in Salesforce with lots of bells and whistles that nobody wants or needs to be a simple Golang/Mysql app hosted on AWS. Yes, it is a tiny subset of the current functionality. But it solves the business case and will save millions of dollars per year in Salesforce fees while simultaneously making the user experience an order of magnitude simpler and allowing faster onboarding. Engineers allowed to run free can often times spend an inordinate amount of time building things out that no one really asked for. Your Haskell backend was probably a thing of pure beauty from a programmers point of view. But an expensive liability to the business.
- whateveracct 5y ago
  > But did the business need all of that functionality? Rewriting a subset of an application that is far more maintainable and cost effective in the long run can be a huge win. It was needed enough that the rewrite (which was slow) had to delay release and the legacy software had to be kept alive well past its sunset date (and plenty of people jetted by then.) Because the business had to keep the lights on! The missing functionality at least was said to be missed by the business folks who made use of it. "If only we had feature X" definitely was said. There wasn't anything too beautiful about the Haskell. It was mostly systems work. But incrementally evolving and improving would've definitely be cheaper long term than a rewrite .. but it does require people to learn Haskell, which seems to be a nonstarter for many. If people don't wanna, they don't wanna.
ufmace 5y ago
This sounds like a good thing to me actually. If your company's primary language is X and you only have one enthusiast for Haskell (or any other such language), it's a bad idea to let them build critical components in their pet language. It's worth longer time for a rewrite and maybe fewer features if you can now count on anybody in the company being able to start working on it fast, instead of having to learn a whole new language and ecosystem first. It might even be less work to learn that language, but that work has to be repeated anytime somebody new needs to touch the code. If you wanna have a supported component in some new language, you need higher-level commitment to keeping a reasonable size bench of developers who know that language at various skill levels. Of course unless you're a rather big company, maintaining hiring and training pipelines for multiple languages can be quite inefficient.
- whateveracct 5y ago
  The main problem in my experience is the initial engineering team that builds the MVP is very into Haskell, and then as the team/org/company grows, they bring in outside leadership. Outside leadership doesn't embrace Haskell (they don't know it), so they see it as a threat instead of as something to value. So then the Haskellers bleed (either due to the culture clash or due to the leadership intentionally hiring against Haskell. I saw a VPE literally say that "wanting to work in Haskell" as a motivation is a "red flag"!) and now you have a Haskell project but no Haskellers. It wasn't Haskell's fault. But it'll take the blame by the boneheads.
  - taeric 5y ago
    Main problem that I have seen, is that new programmers jump on a lot of the higher level abstractions, mainly just because they can. It winds up obscuring more than it helps. Worse, it often locks them in to particular abstractions that aren't a good direction for where things are going.
    - whateveracct 5y ago
      Juniors write bad code in all languages. Why is Haskell's version of this so much worse?

taeric 5y ago

That would be the sad case. I have also seen the case where the code was impenetrable and did not at all lend itself to extension.

whateveracct 5y ago
I've worked on a Haskell project supposedly like that. Took me a couple weeks of not complaining to improve it significantly. The trick was not closing my eyes at the sight of ugly bad code.
- taeric 5y ago
  My problem with this, is you can replace "Haskell" with any other language in that sentence, and it still works.
  - whateveracct 5y ago
    Why's that a problem? It is true if any language. But people act like Haskell can create a mess that is beyond what other languages can create. To the point where it isn't true that you can just..fix it by not complaining.
    - taeric 5y ago
      Hmmm. I can see your point that folks act like it can create a mess beyond other languages. I agree that that is not accurate. I suspect it is more a reaction to the seeming claim that it is immune to that. For my part, my claim was meant to be that it needs an advocate. That is all. I do not know why they other languages have in built advocacy across the board. Python, in particular, is seeing a ton of good will in ways I just don't understand.

ramesh31 5y ago

>The end product has less functionality, but at least you didn't have to do something actually hard like learn Haskell and work with Someone Else's Code. But did the business need all of that functionality? Rewriting a subset of an application that is far more maintainable and cost effective in the long run can be a huge win. I am currently rebuilding an application full of intractable bugs and proprietary DSLs that was implemented in Salesforce with lots of bells and whistles that nobody wants or needs to be a simple Golang/Mysql app hosted on AWS. Yes, it is a tiny subset of the current functionality. But it solves the business case and will save millions of dollars per year in Salesforce fees while simultaneously making the user experience an order of magnitude simpler and allowing faster onboarding. Engineers allowed to run free can often times spend an inordinate amount of time building things out that no one really asked for. Your Haskell backend was probably a thing of pure beauty from a programmers point of view. But an expensive liability to the business.

whateveracct 5y ago
> But did the business need all of that functionality? Rewriting a subset of an application that is far more maintainable and cost effective in the long run can be a huge win. It was needed enough that the rewrite (which was slow) had to delay release and the legacy software had to be kept alive well past its sunset date (and plenty of people jetted by then.) Because the business had to keep the lights on! The missing functionality at least was said to be missed by the business folks who made use of it. "If only we had feature X" definitely was said. There wasn't anything too beautiful about the Haskell. It was mostly systems work. But incrementally evolving and improving would've definitely be cheaper long term than a rewrite .. but it does require people to learn Haskell, which seems to be a nonstarter for many. If people don't wanna, they don't wanna.

ufmace 5y ago

This sounds like a good thing to me actually. If your company's primary language is X and you only have one enthusiast for Haskell (or any other such language), it's a bad idea to let them build critical components in their pet language. It's worth longer time for a rewrite and maybe fewer features if you can now count on anybody in the company being able to start working on it fast, instead of having to learn a whole new language and ecosystem first. It might even be less work to learn that language, but that work has to be repeated anytime somebody new needs to touch the code. If you wanna have a supported component in some new language, you need higher-level commitment to keeping a reasonable size bench of developers who know that language at various skill levels. Of course unless you're a rather big company, maintaining hiring and training pipelines for multiple languages can be quite inefficient.

whateveracct 5y ago
The main problem in my experience is the initial engineering team that builds the MVP is very into Haskell, and then as the team/org/company grows, they bring in outside leadership. Outside leadership doesn't embrace Haskell (they don't know it), so they see it as a threat instead of as something to value. So then the Haskellers bleed (either due to the culture clash or due to the leadership intentionally hiring against Haskell. I saw a VPE literally say that "wanting to work in Haskell" as a motivation is a "red flag"!) and now you have a Haskell project but no Haskellers. It wasn't Haskell's fault. But it'll take the blame by the boneheads.
- taeric 5y ago
  Main problem that I have seen, is that new programmers jump on a lot of the higher level abstractions, mainly just because they can. It winds up obscuring more than it helps. Worse, it often locks them in to particular abstractions that aren't a good direction for where things are going.
  - whateveracct 5y ago
    Juniors write bad code in all languages. Why is Haskell's version of this so much worse?