3 ms·

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

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.

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.