I think it's less about linters and more about basic tooling for toolchains, dependencies, cross compiling, lsp, etc... compare the Haskell tooling to Rust tooling and it's easy to see how deficient it is.
> Backwards compatibility is simply a design aspect, not some holy commandment you must adhere to all times.
It's also something that has enormous influence on industry adoption.
I adore Haskell the language. I use it daily. But I make no excuses for its many shortcomings. I would love to see Haskell prioritize industry needs over academic purity.
Sure, it might help with industrial adoption, but the more you commit to backward compatibility, the more mediocre your language becomes. (You can't really adapt new things if you have to keep everything around.)
What's the point in creating the N+1th generic blub language?
What's the point of creating a language that isn't used? If the goal of the language is to academically research new programming techniques, then fine. Other languages will eventually adopt some of the more useful ideas and industry development will improve because of it.
Not creating something because people don't want to use it is really myopic thinking in my opinion. That's like not creating art because no one buys it. Deliberately aiming for something worse in hopes of public/industrial acceptance is not a good approach IMO.
> Deliberately aiming for something worse in hopes of public/industrial acceptance is not a good approach IMO.
It's not "worse", it's a tradeoff between backwards compatibility and fixups. Backwards compatibility is a really useful feature in and of itself, and the question is whether this outweighs the usefulness of all the tiny fixups. In my opinion it mostly does.
I agree with you, it's a tradeoff. I definitely don't want to say that backwards compatibility is not important..... but when you have N other languages priding themselves on that, what is the value add in creating another stagnant but stable language like that?
I think the reason why this is not emphasised more is because breaking compatibility is a visible cost (program broke, time to investigate and fix it) while the pains from maintaining backwards compatibility is an invisible cost. (you can't easily quantify the wasted hours and extra bugs from unintuitive/broken language features)
This is kind of a natural consequence of the incentives, so I understand why it happens. I'd be happier if it wouldn't.
I think it's less about linters and more about basic tooling for toolchains, dependencies, cross compiling, lsp, etc... compare the Haskell tooling to Rust tooling and it's easy to see how deficient it is.
> Backwards compatibility is simply a design aspect, not some holy commandment you must adhere to all times.
It's also something that has enormous influence on industry adoption.
I adore Haskell the language. I use it daily. But I make no excuses for its many shortcomings. I would love to see Haskell prioritize industry needs over academic purity.