3 ms·

EDIT: I have removed what I said about what I think how usable the language is, because it's off-topic. I'm not sure it's the least over-engineered language.

EDIT: I have removed what I said about what I think how usable the language is, because it's off-topic. I'm not sure it's the least over-engineered language. What you say is like saying that C is simple because there is only memory and functions! Or, to take from for example https://argumate.tumblr.com/post/118013166244/python-what-if-everything-was-a-dict-java-what https://argumate.tumblr.com/post/118013166244/python-what-if... Python: What if everything was a dict? Java: What if everything was an object? JavaScript: What if everything was a dict *and* an object? C: What if everything was a pointer? APL: What if everything was an array? Tcl: What if everything was a string? Prolog: What if everything was a term? LISP: What if everything was a pair? Scheme: What if everything was a function? Haskell: What if everything was a monad? Assembly: What if everything was a register? But in any case, there are typically lots and lots of details (Haskell is no exception), and they matter. And also, it takes a lot of experience to get anything of quality done! I like what Jonathan Blow calls this pattern: "Big Agenda language". It might make a programmer's life harder if the language is so opinionated. (Start here: https://www.youtube.com/watch?v=TH9VCN6UkyQ https://www.youtube.com/watch?v=TH9VCN6UkyQ) He specifically named Haskell, Java, and a few others, as being guilty of that, and being less usable for sticking to ideological purity.

gizmo686 9y ago
I agree that Haskell is made more difficult than necessary by sticking to purity so tightly [0] Having said that, Haskell is very much not built around the question "what if everything was a monad". Monadic IO wasn't even a thing until Haskell 1.3 https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/history.pdf?from=http%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fum%2Fpeople%2Fsimonpj%2Fpapers%2Fhistory-of-haskell%2Fhistory.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... [0] Although this is, in large part, forced by its unfortunate choice of being lazy. It has also, arguably, forced advances in PL research that would have been avoided had Haskell added first class support for imperative programming.
- jstimpfle 9y ago
  I agree with you, and disagree with my quote! There are various of these types of lists on the web and I just picked the first I could find, arguably not the best.
- aninhumer 9y ago
  Indeed. I would argue that a better line for Haskell would be "What if everything was a value?" Basically the IO monad is a way to construct imperative programs by composing side-effect free values. And indeed, much of the subsequent work in Haskell has been materialising even more details to avoid the hidden side-effects that cause the IO monad abstraction to break down.
- alien_at_work 9y ago
  >forced by its unfortunate choice of being lazy Being lazy is what makes the language so elegant. Even a high level game developer (Carmack?) said, at one point, that his ideal language would be lazy by default.
  - aninhumer 9y ago
    My impression is that laziness forced people to invent new abstractions to deal with IO, because you can't rely on the easily predictable evaluation order of eager evaluation to provide a good enough solution. And it's those abstractions that make Haskell elegant. However now that we've invented them, while some things benefit from laziness, eager evaluation is probably a better default.
    - alien_at_work 9y ago
      I would disagree with your impression. Laziness made lots of things very elegant but things like IO initially very hard. Eventually elegant solutions were found for IO as well. An example of the elegance is a simple function that takes some type which can be ordered and picking the "largest" one: max :: Ord a => [a] -> a max = head . sort (<) The type declaration says the function "max" takes a list of some type a, which is Orderable and will return one. The implementation says first sort the list, then return the first entry of the sorted list. In a strict language this would be a lot of wasted effort but in a lazy language (depending on how "sort" is implemented) what ends up happening is basically the same steps you would have to do to pick a max value. The unnecassary sorting of the rest of the list cannot happen because that result is thrown away before it can be accessed. If you asked someone to describe how to get the largest entry in a list, the most consice way to describe it would be to sort the list and then take the first entry. In Haskell the most concise way to describe something is often the correct implementation as well, and that's what I call elegance.
tel 9y ago
Being pretty familiar with Haskell and programming in Scala nowadays, I think Haskell's dogmatic nature makes it much easier to program in! Consistency minimizes conceptual overhead when programming by a lot.

gizmo686 9y ago

I agree that Haskell is made more difficult than necessary by sticking to purity so tightly [0] Having said that, Haskell is very much not built around the question "what if everything was a monad". Monadic IO wasn't even a thing until Haskell 1.3 https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/history.pdf?from=http%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fum%2Fpeople%2Fsimonpj%2Fpapers%2Fhistory-of-haskell%2Fhistory.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... [0] Although this is, in large part, forced by its unfortunate choice of being lazy. It has also, arguably, forced advances in PL research that would have been avoided had Haskell added first class support for imperative programming.

jstimpfle 9y ago
I agree with you, and disagree with my quote! There are various of these types of lists on the web and I just picked the first I could find, arguably not the best.
aninhumer 9y ago
Indeed. I would argue that a better line for Haskell would be "What if everything was a value?" Basically the IO monad is a way to construct imperative programs by composing side-effect free values. And indeed, much of the subsequent work in Haskell has been materialising even more details to avoid the hidden side-effects that cause the IO monad abstraction to break down.
alien_at_work 9y ago
>forced by its unfortunate choice of being lazy Being lazy is what makes the language so elegant. Even a high level game developer (Carmack?) said, at one point, that his ideal language would be lazy by default.
- aninhumer 9y ago
  My impression is that laziness forced people to invent new abstractions to deal with IO, because you can't rely on the easily predictable evaluation order of eager evaluation to provide a good enough solution. And it's those abstractions that make Haskell elegant. However now that we've invented them, while some things benefit from laziness, eager evaluation is probably a better default.
  - alien_at_work 9y ago
    I would disagree with your impression. Laziness made lots of things very elegant but things like IO initially very hard. Eventually elegant solutions were found for IO as well. An example of the elegance is a simple function that takes some type which can be ordered and picking the "largest" one: max :: Ord a => [a] -> a max = head . sort (<) The type declaration says the function "max" takes a list of some type a, which is Orderable and will return one. The implementation says first sort the list, then return the first entry of the sorted list. In a strict language this would be a lot of wasted effort but in a lazy language (depending on how "sort" is implemented) what ends up happening is basically the same steps you would have to do to pick a max value. The unnecassary sorting of the rest of the list cannot happen because that result is thrown away before it can be accessed. If you asked someone to describe how to get the largest entry in a list, the most consice way to describe it would be to sort the list and then take the first entry. In Haskell the most concise way to describe something is often the correct implementation as well, and that's what I call elegance.

tel 9y ago

Being pretty familiar with Haskell and programming in Scala nowadays, I think Haskell's dogmatic nature makes it much easier to program in! Consistency minimizes conceptual overhead when programming by a lot.