I think the Haskell people saying the tools are good (like me!) are just using a very different criteria of "good" than you (and most data scientists!).
For me a "good tool" is robust, reliable, and easy to fix. For most of the data scientists I know, a "good tool" is one where "a single easy to remember command magically does the thing I want in one go".
And I get it, that last part is super appealing, especially for people who care more about answers to their problem than in technology, I don't blame people for wanting that.
But my personal experience is that many of these magical single command tools break a lot when you try to use them in any non-standard environment (for example, something that is not Ubuntu and where you don't have sudo to fix/install system packages) and I work in environments like that a lot. So the fact that e.g. cabal-install requires a bit more explicit work to setup initially is outweighed by the fact that I can reliably install it on any *nix system where I have a login and sufficient diskspace and have it Just Work.
> I think the Haskell people saying the tools are good (like me!) are just using a very different criteria of "good" than you (and most data scientists!).
Exactly, which is why Haskellers should listen to and respond to feedback rather than asserting it is the feedback-giver that is wrong.
> For me a "good tool" is robust, reliable, and easy to fix. For most of the data scientists I know, a "good tool" is one where "a single easy to remember command magically does the thing I want in one go".
I don't agree with this statement and I think demonstrates some of why Haskellers are kind of frustrating. Most data scientist (and most people in general) want to focus on solving the problem they're tasked with, not elegantly and efficiently positioning themselves to be able to do so. Jupyter and Numpy/Pandas are great because they allow the user to focus exclusively on solving their problem, not on language or framework-level concerns. This is not "a magic command that does the thing I want in one go." It is the separating the needs of the hammer maker from the needs of the carpenter.
For me a "good tool" is robust, reliable, and easy to fix. For most of the data scientists I know, a "good tool" is one where "a single easy to remember command magically does the thing I want in one go".
And I get it, that last part is super appealing, especially for people who care more about answers to their problem than in technology, I don't blame people for wanting that.
But my personal experience is that many of these magical single command tools break a lot when you try to use them in any non-standard environment (for example, something that is not Ubuntu and where you don't have sudo to fix/install system packages) and I work in environments like that a lot. So the fact that e.g. cabal-install requires a bit more explicit work to setup initially is outweighed by the fact that I can reliably install it on any *nix system where I have a login and sufficient diskspace and have it Just Work.