3 ms·

Their discussion of Haskell starts with the statement that it is "very abstract" and continues with "Do you really need six different ways to implement factoria

by eapriv 7y ago

Their discussion of Haskell starts with the statement that it is "very abstract" and continues with "Do you really need six different ways to implement factorial?". Well, you have six (in fact, many more that six) ways to implement factorial in any (reasonably expressive) programming language. That's like looking at language that has both if/then/else statements and switch statements, and asking "do we really need both?". The first three ways to implement factorial demonstrated in the article amount to minor differences similar to those between "if/then/else" and "switch", and the last three rely on various standard library functions, which technically doesn't say much about the language itself.

cousin_it 7y ago
Here's another list of factorial implementations in Haskell, which I think does say something about the language and its mindset. Be sure to scroll to the end: https://www.willamette.edu/~fruehr/haskell/evolution.html https://www.willamette.edu/~fruehr/haskell/evolution.html Here's another illustration. Since values in Haskell are immutable, implementing something like foo.bar.baz+=1 becomes a bit clunky, so they wrote a library to make it easier. Check it out, especially the diagram that says "simplified": http://hackage.haskell.org/package/lens http://hackage.haskell.org/package/lens So I agree with the article that Haskell can be dauntingly abstract. (Though you can write code that's perfectly straightforward if you want.)
- kreetx 7y ago
  Both field name overloading and deep updates have been problems and are worked on as we speak: https://github.com/ghc-proposals/ghc-proposals/pull/282 https://github.com/ghc-proposals/ghc-proposals/pull/282. And yes, that is what the lens library has been solving till now.
- imglorp 7y ago
  I would like to see a concerted effort from the Haskell community to set aside the self-gratifying maps and factorials, and show us real work. The OP article, too, focusing on reducing errors, went into the factorial weeds here. How about presenting the air traffic control example in Haskell to contrast with the Ada? Real concurrency, real I/O, and real error cases.
  - cousin_it 7y ago
    I think real I/O and error handling will be about the same in any language. People fall in love with Haskell for other reasons: It's very nice for some algorithms. For example, see Appendix A of this paper: https://pdfs.semanticscholar.org/b47b/41a9b2dcf6b3ffe3ce7a04c49958122b2060.pdf https://pdfs.semanticscholar.org/b47b/41a9b2dcf6b3ffe3ce7a04... An implementation of red-black trees in only 60 lines, including deletion, which alone can take hundreds of lines in a curly brace language. It's also very nice for some APIs. For example, software transactional memory fits the Haskell type system very well, because it can ensure that data can't be modified outside a transaction and can be rolled back when needed. A team at Microsoft, including some well-known folks, tried to port it from Haskell to C# and failed due to the type system: https://www.infoq.com/news/2010/05/STM-Dropped/ https://www.infoq.com/news/2010/05/STM-Dropped/ Haskell has a bunch of non-mainstream features that work together unusually well. It enables programmers to think a certain kind of thoughts that wouldn't naturally arise in many other languages. It's like painting with oil when the rest of the world uses watercolor: in theory they can draw the same things, but in practice they'll guide your hand toward different things, so having both makes the world richer.
kreetx 7y ago
The factorial section he should have, yes, just left out because it makes no sense as an argument. The first two bullet points may have some truth to them, the rest seem like a result of using google search to find the "cons".
ainar-g 7y ago
> That's like looking at language that has both if/then/else statements and switch statements, and asking "do we really need both?". Not sure if that jab was intended or not, but Python, one of the most popular programming languages in the world, doesn't have a switch statement, probably for this exact reason. Python programmers use chains of if/elif*/else? statements.

by eapriv 7y ago

cousin_it 7y ago

Here's another list of factorial implementations in Haskell, which I think does say something about the language and its mindset. Be sure to scroll to the end: https://www.willamette.edu/~fruehr/haskell/evolution.html https://www.willamette.edu/~fruehr/haskell/evolution.html Here's another illustration. Since values in Haskell are immutable, implementing something like foo.bar.baz+=1 becomes a bit clunky, so they wrote a library to make it easier. Check it out, especially the diagram that says "simplified": http://hackage.haskell.org/package/lens http://hackage.haskell.org/package/lens So I agree with the article that Haskell can be dauntingly abstract. (Though you can write code that's perfectly straightforward if you want.)

kreetx 7y ago
Both field name overloading and deep updates have been problems and are worked on as we speak: https://github.com/ghc-proposals/ghc-proposals/pull/282 https://github.com/ghc-proposals/ghc-proposals/pull/282. And yes, that is what the lens library has been solving till now.
imglorp 7y ago
I would like to see a concerted effort from the Haskell community to set aside the self-gratifying maps and factorials, and show us real work. The OP article, too, focusing on reducing errors, went into the factorial weeds here. How about presenting the air traffic control example in Haskell to contrast with the Ada? Real concurrency, real I/O, and real error cases.
- cousin_it 7y ago
  I think real I/O and error handling will be about the same in any language. People fall in love with Haskell for other reasons: It's very nice for some algorithms. For example, see Appendix A of this paper: https://pdfs.semanticscholar.org/b47b/41a9b2dcf6b3ffe3ce7a04c49958122b2060.pdf https://pdfs.semanticscholar.org/b47b/41a9b2dcf6b3ffe3ce7a04... An implementation of red-black trees in only 60 lines, including deletion, which alone can take hundreds of lines in a curly brace language. It's also very nice for some APIs. For example, software transactional memory fits the Haskell type system very well, because it can ensure that data can't be modified outside a transaction and can be rolled back when needed. A team at Microsoft, including some well-known folks, tried to port it from Haskell to C# and failed due to the type system: https://www.infoq.com/news/2010/05/STM-Dropped/ https://www.infoq.com/news/2010/05/STM-Dropped/ Haskell has a bunch of non-mainstream features that work together unusually well. It enables programmers to think a certain kind of thoughts that wouldn't naturally arise in many other languages. It's like painting with oil when the rest of the world uses watercolor: in theory they can draw the same things, but in practice they'll guide your hand toward different things, so having both makes the world richer.

kreetx 7y ago

The factorial section he should have, yes, just left out because it makes no sense as an argument. The first two bullet points may have some truth to them, the rest seem like a result of using google search to find the "cons".

ainar-g 7y ago

> That's like looking at language that has both if/then/else statements and switch statements, and asking "do we really need both?". Not sure if that jab was intended or not, but Python, one of the most popular programming languages in the world, doesn't have a switch statement, probably for this exact reason. Python programmers use chains of if/elif*/else? statements.