4 ms·

> I wonder if the first point is due to a paradox of advanced tools.. society lives around "how do you assemble teams to solve big problems", they need organiza

> I wonder if the first point is due to a paradox of advanced tools.. society lives around "how do you assemble teams to solve big problems", they need organization tricks more than logic/language ones. That's why RoR, go, etc win, they allow most groups to end up with something workable. Haskell and the likes are more about exploration.. not tending to companies needs for profits. I feel like "not tending to companies needs for profits" is a way to elevate Haskell and monadic FP abstractions with appeal to conspiracy/(postmodern) ideology. I don't mean this to be a pro-or-anti capitalism sentiment, but the excuse here is that "in a more just/less captalist/<other> world, Haskell would be a great tool, but our flawed world makes it not so" and I disagree with that. I just don't think Haskell is that good of a tool regardless (and I see the Haskell community these days appealing to this take a lot, trying to blame anyone but themselves.) I think that people genuinely don't derive much value from Haskell and monadic FP. My experience, having written and maintained non-production-grade Haskell code, has been that the community is obsessed with toys and small examples, derives a lot of pleasure from clever abstractions which don't materially affect development (like Lenses), and most importantly doesn't really care about shipping software. There's exceptions like SPJ and Joey Hess who definitely ship useful Haskell, but the community doesn't care nearly enough about making it easy to actually produce software that a non-Haskell enthusiast would care about using. Libraries are often created for a Masters project and abandoned. Even if a library works, debugging edge cases is never thought of. Almost nothing is written about testing in Haskell. No two libraries can agree on which monad stack to use, so a non-trivial amount of integration code involves matching and lifting into other monads (nor the performance implications of doing all of this matching and lifting). There are very few examples of organizational patterns for Haskell codebases for folks trying to create a project other than GHC itself, Pandoc, and perhaps XMonad. The community loves talking about abstractions and unifying concepts but doesn't really seem to have any practical tips about writing software. The string types in the language are confusing and poorly differentiated. The cabal and stack split is confusing and makes no sense to outsiders. The weird cargo-cult obsession in the community about category theory from people with little formal mathematical knowledge is bizarre. I can go on and on, but I don't want to dunk on the language endlessly (and I can certainly do this to any language I've used in love or anger :) Fundamentally I don't think Haskell offers the programmer much more than what you'd get out of a language like Rust, Java, or Go (yes even Go) as the GP said. It's a language with a lot of interesting concepts that's fun for folks who like to solve algebra problems and is certainly a clean introduction to monadic FP. I'm looking forward to a successor that takes its concepts, cleans them up, and offers a way to write actual software with them. Then again, Multicore Ocaml is landing soon...

pyrale 4y ago
Several of the issues you talk about are true enough, especially the ones about the community not making it easier for newcomers to get the ropes. The reason for that is that people who do haskell for a living are dwarfed by the hobbyist community which makes them invisible, and they're spread thin on maintaining the ecosystem. GHC, HLS and all the other good things there are are the work of people on their free time, while other, more successful languages simply have companies dedicating time, money and contracts to tooling. All of that means that it's not easy to move from the hobbyist haskeller group to the paid haskeller group. Most people usually get there by getting hired in a place where the stack, library choices, etc. are made by people who had done haskell professionally before and have solved the problem you cite for the team. Once you're in, the benefits of Haskell are tangible, otherwise people would stop using it, and there wouldn't be a professional community. That is not to say that there are no problems, it's just that they are different problems, and people that stick to haskell for their job usually do it as a tradeoff.
- Karrot_Kream 4y ago
  What are the problems y'all see in production then with Haskell code? I'm curious since I never ran my code in a prod setting so I don't know what one cares about when operating Haskell code.
  - unhammer 4y ago
    That would be a nice "ask hn" :-)
  - pyrale 4y ago
    Honestly, the problems I had with Haskell were mostly related to organization rather than tech. How recruitment would happen. What rules we would set in place to make sure the codebase didn't become overcomplicated. How to make sure people don't get engrossed in tech and neglect the business aspect. How to make sure a large part of the codebase is mundane enough that newcomers can contribute on it quickly. The tech itself really works well, but it required either an org mature enough to do the things correctly, or a shop purely focused on haskell that would accept the complexity. Also, sometimes the library ecosystem is a bit lacking. It wasn't an immovable roadblock, but we did write stuff that may have been available as a lib in other languages. This was a minor impediment for us, but it can get bad in other contexts.

pyrale 4y ago

Several of the issues you talk about are true enough, especially the ones about the community not making it easier for newcomers to get the ropes. The reason for that is that people who do haskell for a living are dwarfed by the hobbyist community which makes them invisible, and they're spread thin on maintaining the ecosystem. GHC, HLS and all the other good things there are are the work of people on their free time, while other, more successful languages simply have companies dedicating time, money and contracts to tooling. All of that means that it's not easy to move from the hobbyist haskeller group to the paid haskeller group. Most people usually get there by getting hired in a place where the stack, library choices, etc. are made by people who had done haskell professionally before and have solved the problem you cite for the team. Once you're in, the benefits of Haskell are tangible, otherwise people would stop using it, and there wouldn't be a professional community. That is not to say that there are no problems, it's just that they are different problems, and people that stick to haskell for their job usually do it as a tradeoff.

Karrot_Kream 4y ago
What are the problems y'all see in production then with Haskell code? I'm curious since I never ran my code in a prod setting so I don't know what one cares about when operating Haskell code.
- unhammer 4y ago
  That would be a nice "ask hn" :-)
- pyrale 4y ago
  Honestly, the problems I had with Haskell were mostly related to organization rather than tech. How recruitment would happen. What rules we would set in place to make sure the codebase didn't become overcomplicated. How to make sure people don't get engrossed in tech and neglect the business aspect. How to make sure a large part of the codebase is mundane enough that newcomers can contribute on it quickly. The tech itself really works well, but it required either an org mature enough to do the things correctly, or a shop purely focused on haskell that would accept the complexity. Also, sometimes the library ecosystem is a bit lacking. It wasn't an immovable roadblock, but we did write stuff that may have been available as a lib in other languages. This was a minor impediment for us, but it can get bad in other contexts.