4 ms·

The author seems to argue that Haskell's mental fit of the language is a better fit for the domain of data science, and so, really it's the lack of libraries th

The author seems to argue that Haskell's mental fit of the language is a better fit for the domain of data science, and so, really it's the lack of libraries that are holding Haskell back. So, obvious question, why did the libraries get created in R and Python..? Many blog post about Haskell seem to include something like... "This is not a language for beginners..." "This language will make you smarter but there is a steep learning curve..." "I don't feel smart enough to want to learn Haskell..." And I haven't seen many other posts attempting to dispel that notion. Libraries are written by people. How big is Haskell's userbase? What is the Haskell community doing to increase it? It's at a natural disadvantage when you've got schools (like MIT and Harvard school) using Python as the learning language of choice now and Python has a reputation for being easy to pickup and just being really pleasant to write it.

ellisv 8y ago
Students usually learn R in a statistics class - while also trying to learn statistics! They usually don't have any prior programming experience so the forgiving nature of the language makes sense. Trying to learn Haskell and statistics at the same time might be asking too much, esp. if the libraries aren't there.
DonaldPShimoda 8y ago
I think the problem isn't Haskell but rather the way programming is usually taught. Imperative programming is the most widespread paradigm, by far. When people find an introduction to programming, it's going to be in a language like C, C++, Java, Python, C#, JavaScript, etc. Many of these languages support functional style in some way or another, but none of them truly embrace it — and anyway, you wouldn't find any mention of it in introductory material. In an imperative language, you write down a list of instructions for the computer. You can think of it as a step-by-step recipe, and the computer will dumbly follow your instructions to the T. This is easy to explain, and since it's what most people use it's also what most people teach. Haskell (and pure functional languages in general) are fundamentally different. In a functional language, you're writing data transformations. That's literally all it is. Instead of writing a procedure, you write what essentially amounts to a mathematical function describing how to transform the input data into the desired output. It's not a list of steps, but rather a single modification. You compose multiple functions together to get the desired result. This definitely seems more aligned with the goals of data science, for the most part. (Though I'm not a data scientist, so I could be wrong!) I don't think functional programming is significantly more difficult to learn. It's just hard to learn after you've already learned the imperative style. It's hard to go back and figure out a different way to explain things to the computer once you're used to doing it the one way. I think this is the part that those quotes you have are really talking about. I don't think Haskell is inherently more difficult to learn than Java for somebody whose programming knowledge is a blank slate; it's just hard to learn after you've started down the path of imperative thinking.
- patagonia 8y ago
  I don't disagree with what you've said, but I'd like to redirect. I don't think there is a general expectation that programmers or software engineers should approach writing software primarily from a mathematical perspective. If for a given input one generates the expected output then you've written good code (over generalization). So, when I sit down to extend a library with a bit of new functionality, I'm generally not going to also go through the process of learning a new language or making changes to the language I already know. I'm going to express this new functionality using my existing tools. The library is being extended, not the language. Which is why I find the other comment's mention of Racket to be interesting. I've always found it weird that the grammar, syntax, notation, etc of various different maths are not better represented in programming languages. Software is after all, theoretically, infinitely flexible. But most new code is written using the same tricks as old code. Compare this with mathematics. When you switch from linear algebra to calculus you're expressing it all on the chalk board in completely different terms. You don't write calculus in the language of linear algebra. (Yeah, I know many ideas can be expressed / optimized using it, I'm speaking of how does one achieve the greatest level of mental ergonomics when thinking about or expressing an idea. Maybe call it speaking native Calculus.) Different symbols. Different layouts. It all facilitates a different thinking about different ideas. This is clearly where LaTeX, Mathematica, SageMath, and others come in. But if we're talking about Python and R libraries, well that is no where near as natural. Programming is taught just fine for those wanting to program. Maybe mathematicians need to put more effort into leveraging the tool we call software into building out tools, languages, libraries, and human/computer interfaces for the activity we call mathematics. Or not. We're probably at the state where we are at because to some extent it gets the job done. With maths and software being so important to our future, though, I personally feel that improving the ergonomics of tools used for computational sciences would pay hefty dividends.
AnimalMuppet 8y ago
If I understand correctly, a bunch of Python's libraries (NumPy, specifically) came from Fortran. The Fortran libraries are very well debugged and tested, and they cover an insane number of special cases. (You want a linear equation solver for sparse complex Hermitian matrices that is both efficient and numerically stable? Sure, we got that.) I don't know whether Haskell could wrap such libraries in the same way. I mean, I assume that technically it's possible, but you'd like to keep Haskell's type safety. Encoding that a matrix has to be Hermitian in a type is possible, I suppose, but it might be messy...

ellisv 8y ago

Students usually learn R in a statistics class - while also trying to learn statistics! They usually don't have any prior programming experience so the forgiving nature of the language makes sense. Trying to learn Haskell and statistics at the same time might be asking too much, esp. if the libraries aren't there.

DonaldPShimoda 8y ago

I think the problem isn't Haskell but rather the way programming is usually taught. Imperative programming is the most widespread paradigm, by far. When people find an introduction to programming, it's going to be in a language like C, C++, Java, Python, C#, JavaScript, etc. Many of these languages support functional style in some way or another, but none of them truly embrace it — and anyway, you wouldn't find any mention of it in introductory material. In an imperative language, you write down a list of instructions for the computer. You can think of it as a step-by-step recipe, and the computer will dumbly follow your instructions to the T. This is easy to explain, and since it's what most people use it's also what most people teach. Haskell (and pure functional languages in general) are fundamentally different. In a functional language, you're writing data transformations. That's literally all it is. Instead of writing a procedure, you write what essentially amounts to a mathematical function describing how to transform the input data into the desired output. It's not a list of steps, but rather a single modification. You compose multiple functions together to get the desired result. This definitely seems more aligned with the goals of data science, for the most part. (Though I'm not a data scientist, so I could be wrong!) I don't think functional programming is significantly more difficult to learn. It's just hard to learn after you've already learned the imperative style. It's hard to go back and figure out a different way to explain things to the computer once you're used to doing it the one way. I think this is the part that those quotes you have are really talking about. I don't think Haskell is inherently more difficult to learn than Java for somebody whose programming knowledge is a blank slate; it's just hard to learn after you've started down the path of imperative thinking.

patagonia 8y ago
I don't disagree with what you've said, but I'd like to redirect. I don't think there is a general expectation that programmers or software engineers should approach writing software primarily from a mathematical perspective. If for a given input one generates the expected output then you've written good code (over generalization). So, when I sit down to extend a library with a bit of new functionality, I'm generally not going to also go through the process of learning a new language or making changes to the language I already know. I'm going to express this new functionality using my existing tools. The library is being extended, not the language. Which is why I find the other comment's mention of Racket to be interesting. I've always found it weird that the grammar, syntax, notation, etc of various different maths are not better represented in programming languages. Software is after all, theoretically, infinitely flexible. But most new code is written using the same tricks as old code. Compare this with mathematics. When you switch from linear algebra to calculus you're expressing it all on the chalk board in completely different terms. You don't write calculus in the language of linear algebra. (Yeah, I know many ideas can be expressed / optimized using it, I'm speaking of how does one achieve the greatest level of mental ergonomics when thinking about or expressing an idea. Maybe call it speaking native Calculus.) Different symbols. Different layouts. It all facilitates a different thinking about different ideas. This is clearly where LaTeX, Mathematica, SageMath, and others come in. But if we're talking about Python and R libraries, well that is no where near as natural. Programming is taught just fine for those wanting to program. Maybe mathematicians need to put more effort into leveraging the tool we call software into building out tools, languages, libraries, and human/computer interfaces for the activity we call mathematics. Or not. We're probably at the state where we are at because to some extent it gets the job done. With maths and software being so important to our future, though, I personally feel that improving the ergonomics of tools used for computational sciences would pay hefty dividends.

AnimalMuppet 8y ago

If I understand correctly, a bunch of Python's libraries (NumPy, specifically) came from Fortran. The Fortran libraries are very well debugged and tested, and they cover an insane number of special cases. (You want a linear equation solver for sparse complex Hermitian matrices that is both efficient and numerically stable? Sure, we got that.) I don't know whether Haskell could wrap such libraries in the same way. I mean, I assume that technically it's possible, but you'd like to keep Haskell's type safety. Encoding that a matrix has to be Hermitian in a type is possible, I suppose, but it might be messy...