7 ms·

> I still don't understand Haskell It's not you. Haskell has very bad syntax. It's not hard to understand it, it you rewrite the same things in something san

> I still don't understand Haskell It's not you. Haskell has very bad syntax. It's not hard to understand it, it you rewrite the same things in something saner. Haskell was developed by people who enjoy one-liners and don't really need to write practical programs. Another aspect of Haskell is that it was written by people who were so misguided as to think that mathematical formulas are somehow superior to typical imperative languages, with meaningful variable names, predictable interpretations of sequences of instructions etc. They, instead, made it all bespoke. Every operation has its own syntax, variables are typically named as they would in math formulas (eg. X and X'). This makes no sense, and is, in fact, very harmful when writing real-world programs, but because, by and large, Haskell never raises to the task of writing real-world programs, it doesn't deter the adepts from using it.

tome 2y ago
That's what (some) other people do. None of that stops you writing Haskell in whatever style you want, with meaningful variable names, curly braces and semicolons!
- crabbone 2y ago
  Unfortunately, writing isn't even half the battle. Before you start writing, you need to read a lot. And Haskell code is, in general, atrocious. It always feels like there was a normal way to do something, but the author decided to chose the most convoluted way they can imagine to accomplish the same thing for the sake of a bizarre fashion sense.
agentultra 2y ago
You knew Paul Hudak, Simon Peyton Jones, Phil Wadler, etc? Were they thinking about the benefits of mathematical formulas over program counters and procedural keywords when designing Haskell? I was under the impression from the History of Haskell [0] that they were interested in unifying research into lazy evaluation of functional programming languages. > This makes no sense, and is, in fact, very harmful when writing real-world programs, Gosh, what am I doing with my life? I must have made up all those programs I wrote on my stream, the ones I use to maintain my website, and all the boring line-of-business code I write at work. /s In all seriousness, Haskell has its warts, but being impractical isn't one of them. To some purists the committee has been overly pragmatic with the design of the language. As far as functional programming languages go it's pretty hairy. You have "pure" functions in the base libraries that can throw runtime exceptions when given the wrong values for their arguments (ie: the infamous head function). Bottom, a special kind of null value, is a member of every type. There exist functions to escape the type system entirely that are used with some frequency to make things work. The committee has gone back more than once to reshape the type-class hierarchy much to the chagrin of the community of maintainers who had to manually patch old code or risk having it not longer compile on new versions of the base libraries. These are all hairy, pragmatic trade-offs the language and ecosystem designers and maintainers have had to make... because people write software using this language to solve problems they have and they have to maintain these systems. [0] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/history.pdf?from=https://research.microsoft.com/~simonpj/papers/history-of-haskell/history.pdf&type=exact https://www.microsoft.com/en-us/research/wp-content/uploads/...
- crabbone 2y ago
  You don't need to know the author personally to appreciate the result of their work... > Gosh, what am I doing with my life? I would ask the same question, but unironically. No, you didn't make up those programs of course. I didn't claim that real-world programs are impossible to write in Haskell. I claimed that Haskell is a bad tool for writing real-world programs. People make sub-optimal decisions all the time. That's just human nature... choosing Haskell for any program that would require debugging, long-term maintenance, cross-platform UI, or plenty of other desirable properties is just a very bad choice. But people like you do it anyways! Why? -- there are plenty of possible answers. If I wanted to look for the flattering answers, I'd say that a lot of experienced and talented programmers like Haskell. So, choosing to write in Haskell for that reason isn't such a bad idea. But, if I wanted to judge Haskell on its engineering rather than social merits: it has very little to bring to the table.
  - tome 2y ago
    Strange. In my experience Haskell is the best language for long-term maintainability! I can actually come back to code I've written years ago and understand what it does. I've never experience that with another language.
    - crabbone 2y ago
      This is not really what maintainability means to me. To me, it just means you have a good memory. To be able to maintain something you need to be able to transfer the ownership of the piece of code to someone else. You need to be able to amend the code easily to extend or to remove functionality. It means that the code can be easily split into pieces that can be given to multiple developers to work simultaneously towards a common goal. Haskell scores poorly on any of those points. It's very hard to transfer ownership because Haskell programs have too much bespoke syntax that anyone but the original author will not be familiar with. Haskell programs are very hard to understand by executing them because there's no chance of a good step debugger due to the language being "lazy". Haskell programs are always "full of surprises" because they allow a lot of flexibility in the interpretation of the same symbols. The problems C++ programmers complain about when faced with operators overloading are the kind of things Haskell programmers call "Tuesday". "Pure" functions are a lot harder to modify to add functionality. Typically, such modifications would require swiping changes across the entire codebase. One may argue that this preserves "single responsibility" constraint, but in practice it means a lot more work. Objects and modules were advertised as a solution to code modularity -- another necessary quality for maintainability. While Haskell has modules, it doesn't really have smaller units of encapsulation other than functions. If two programmers are tasked to work on the same module, they aren't going to have a good time.
jiiam 2y ago
Just to give a different pov I find Haskell very intuitive, and particularly I find that code written by other people is very easy to understand (compared to Java or TypeScript at least). And by the way x and x' are totally fine names for a value of a very generic type (or even a very specific type depending on the circumstances), as long as the types and the functions are decently named. I mean, how else would you call the arguments of splitAt :: Eq a => a -> [a] -> [[a]] ? There is no need for anything more complex than splitAt x xs = ...
- whytevuhuni 2y ago
  > I mean, how else would you call the arguments of > splitAt :: Eq a => a -> [a] -> [[a]] Those don't seem to be names of parameters, but rather of types. It's missing parameter names entirely. I spent a good 2 minutes looking at that signature trying to figure it out (and I've read some Haskell tutorials so I'm at least familiar with the syntax). This would've helped: def split_by<T>(separator: T, list: List[T]) -> List[List[T]] `sep`, `separator`, `delim`, `delimiter` would've been good names.
  - jiiam 2y ago
    > Those don't seem to be names of parameters, but rather of types. It's missing parameter names entirely. The rest of the definition is at the end, to see it as a whole: splitAt :: Eq a => a -> [a] -> [[a]] splitAt x xs = ... To clarify, I assumed that by using the constraint `Eq a` and the name splitAt there was no need for extra clarification in the names of the parameters but apparently I was wrong.
    - gmfawcett 2y ago
      I think some of the confusion is because you're referring to the type variables as parameters. Parameters and type variables are not the same thing. A is a type variable, X is a parameter in your example.
    - theCodeStig 2y ago
      No, you're right. It is perfectly clear from the type signature

tome 2y ago

That's what (some) other people do. None of that stops you writing Haskell in whatever style you want, with meaningful variable names, curly braces and semicolons!

crabbone 2y ago
Unfortunately, writing isn't even half the battle. Before you start writing, you need to read a lot. And Haskell code is, in general, atrocious. It always feels like there was a normal way to do something, but the author decided to chose the most convoluted way they can imagine to accomplish the same thing for the sake of a bizarre fashion sense.

agentultra 2y ago

You knew Paul Hudak, Simon Peyton Jones, Phil Wadler, etc? Were they thinking about the benefits of mathematical formulas over program counters and procedural keywords when designing Haskell? I was under the impression from the History of Haskell [0] that they were interested in unifying research into lazy evaluation of functional programming languages. > This makes no sense, and is, in fact, very harmful when writing real-world programs, Gosh, what am I doing with my life? I must have made up all those programs I wrote on my stream, the ones I use to maintain my website, and all the boring line-of-business code I write at work. /s In all seriousness, Haskell has its warts, but being impractical isn't one of them. To some purists the committee has been overly pragmatic with the design of the language. As far as functional programming languages go it's pretty hairy. You have "pure" functions in the base libraries that can throw runtime exceptions when given the wrong values for their arguments (ie: the infamous head function). Bottom, a special kind of null value, is a member of every type. There exist functions to escape the type system entirely that are used with some frequency to make things work. The committee has gone back more than once to reshape the type-class hierarchy much to the chagrin of the community of maintainers who had to manually patch old code or risk having it not longer compile on new versions of the base libraries. These are all hairy, pragmatic trade-offs the language and ecosystem designers and maintainers have had to make... because people write software using this language to solve problems they have and they have to maintain these systems. [0] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/history.pdf?from=https://research.microsoft.com/~simonpj/papers/history-of-haskell/history.pdf&type=exact https://www.microsoft.com/en-us/research/wp-content/uploads/...

crabbone 2y ago
You don't need to know the author personally to appreciate the result of their work... > Gosh, what am I doing with my life? I would ask the same question, but unironically. No, you didn't make up those programs of course. I didn't claim that real-world programs are impossible to write in Haskell. I claimed that Haskell is a bad tool for writing real-world programs. People make sub-optimal decisions all the time. That's just human nature... choosing Haskell for any program that would require debugging, long-term maintenance, cross-platform UI, or plenty of other desirable properties is just a very bad choice. But people like you do it anyways! Why? -- there are plenty of possible answers. If I wanted to look for the flattering answers, I'd say that a lot of experienced and talented programmers like Haskell. So, choosing to write in Haskell for that reason isn't such a bad idea. But, if I wanted to judge Haskell on its engineering rather than social merits: it has very little to bring to the table.
- tome 2y ago
  Strange. In my experience Haskell is the best language for long-term maintainability! I can actually come back to code I've written years ago and understand what it does. I've never experience that with another language.
  - crabbone 2y ago
    This is not really what maintainability means to me. To me, it just means you have a good memory. To be able to maintain something you need to be able to transfer the ownership of the piece of code to someone else. You need to be able to amend the code easily to extend or to remove functionality. It means that the code can be easily split into pieces that can be given to multiple developers to work simultaneously towards a common goal. Haskell scores poorly on any of those points. It's very hard to transfer ownership because Haskell programs have too much bespoke syntax that anyone but the original author will not be familiar with. Haskell programs are very hard to understand by executing them because there's no chance of a good step debugger due to the language being "lazy". Haskell programs are always "full of surprises" because they allow a lot of flexibility in the interpretation of the same symbols. The problems C++ programmers complain about when faced with operators overloading are the kind of things Haskell programmers call "Tuesday". "Pure" functions are a lot harder to modify to add functionality. Typically, such modifications would require swiping changes across the entire codebase. One may argue that this preserves "single responsibility" constraint, but in practice it means a lot more work. Objects and modules were advertised as a solution to code modularity -- another necessary quality for maintainability. While Haskell has modules, it doesn't really have smaller units of encapsulation other than functions. If two programmers are tasked to work on the same module, they aren't going to have a good time.

jiiam 2y ago

Just to give a different pov I find Haskell very intuitive, and particularly I find that code written by other people is very easy to understand (compared to Java or TypeScript at least). And by the way x and x' are totally fine names for a value of a very generic type (or even a very specific type depending on the circumstances), as long as the types and the functions are decently named. I mean, how else would you call the arguments of splitAt :: Eq a => a -> [a] -> [[a]] ? There is no need for anything more complex than splitAt x xs = ...

whytevuhuni 2y ago
> I mean, how else would you call the arguments of > splitAt :: Eq a => a -> [a] -> [[a]] Those don't seem to be names of parameters, but rather of types. It's missing parameter names entirely. I spent a good 2 minutes looking at that signature trying to figure it out (and I've read some Haskell tutorials so I'm at least familiar with the syntax). This would've helped: def split_by<T>(separator: T, list: List[T]) -> List[List[T]] `sep`, `separator`, `delim`, `delimiter` would've been good names.
- jiiam 2y ago
  > Those don't seem to be names of parameters, but rather of types. It's missing parameter names entirely. The rest of the definition is at the end, to see it as a whole: splitAt :: Eq a => a -> [a] -> [[a]] splitAt x xs = ... To clarify, I assumed that by using the constraint `Eq a` and the name splitAt there was no need for extra clarification in the names of the parameters but apparently I was wrong.
  - gmfawcett 2y ago
    I think some of the confusion is because you're referring to the type variables as parameters. Parameters and type variables are not the same thing. A is a type variable, X is a parameter in your example.
  - theCodeStig 2y ago
    No, you're right. It is perfectly clear from the type signature