4 ms·

There was an article posted somewhere about why Haskell isn't used very much in the data science/ML community, and the feedback was that the tooling is mostly n

There was an article posted somewhere about why Haskell isn't used very much in the data science/ML community, and the feedback was that the tooling is mostly not so good. It was kind of amusing to read all of the comments on /r/haskell saying "no it's good." I don't think Haskellers would really understand, but lots of people (especially data scientists in my experience) view languages only as tools. The Haskell community seems to derive lots of value from spending tremendous time basking in the elegance of their tool, rather than actually using it to solve problems. So /r/haskell will continue basking, the rest of the world will continue not using it to solve problems. Or an extremely long winded "yeah I have the same experience as you."

merijnv 7y ago
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.
- alexbanks 7y ago
  > 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.
agentultra 7y ago
I use it to solve problems. I have a database with millions of unstructured JSON documents. I wrote a tool in Haskell to scan the database, parse the unstructured documents and collect the results. It displays the ratio of successful parses and the top N parse errors with a sample to add to my test suite. Once I can parse 100% of the database I can use another library I'm working on that can migrate between data structures while preserving information and provenance. Then I can safely migrate millions of lines of unstructured documents with dozens of weird corner cases to a collection of documents with consistent structure and few corner cases. Sure I could do this in pretty much any language on the market but I've put relatively little effort into this and am nearly done. Programming in Haskell has a good power-to-weight ratio. I don't really have anything to complain about tools-wise. It's all standard fare or better than most other language ecosystems as far as I'm concerned.

merijnv 7y ago

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.

alexbanks 7y ago
> 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.

agentultra 7y ago

I use it to solve problems. I have a database with millions of unstructured JSON documents. I wrote a tool in Haskell to scan the database, parse the unstructured documents and collect the results. It displays the ratio of successful parses and the top N parse errors with a sample to add to my test suite. Once I can parse 100% of the database I can use another library I'm working on that can migrate between data structures while preserving information and provenance. Then I can safely migrate millions of lines of unstructured documents with dozens of weird corner cases to a collection of documents with consistent structure and few corner cases. Sure I could do this in pretty much any language on the market but I've put relatively little effort into this and am nearly done. Programming in Haskell has a good power-to-weight ratio. I don't really have anything to complain about tools-wise. It's all standard fare or better than most other language ecosystems as far as I'm concerned.