←back to thread

306 points jameshh | 2 comments | | HN request time: 0.48s | source
Show context
behnamoh ◴[] No.44409423[source]
Haskell has an interesting syntax: it is intuitive after someone explains it to me, but not intuitive much before the explanation.

I don't think it's because I'm used to Algol-based languages (C, Python, etc.). Every Haskell code I've seen is plagued with a plethora of operators which aim to make the code concise but it's not obvious what they do just by looking at them: https://academy.fpblock.com/haskell/tutorial/operators/

replies(4): >>44410370 #>>44410421 #>>44410532 #>>44411932 #
tikhonj ◴[] No.44410532[source]
At some point, I did a rough count, and the number of operators you encounter in "normal" Haskell code—avoiding lens or domain-specific libraries—was pretty close to the number of operators you'd encounter in, say, JavaScript. This was a while ago and I don't want to redo the exercise now, but, even if we're being generous to JavaScript, practical Haskell needs on the order of 2x as many operators as practical JavaScript, not 10x.

Haskell has some up-front incidental complexity, but it's a difference of degree not kind from popular starting languages. It's easy to underestimate how much you had to learn about Algol-style languages that you've just internalized so well that you don't even realize. I've taught some complete programming beginners (high or middle schoolers) Java and Python and, especially one-on-one, I've seen how they get confused by things I did not even remember required explanation!

For example, in Python, people put : in the wrong place and don't understand how = works. "Basic" syntax like : and = are far more complex than we realize, we've just learned the basics so well that it's second nature. It's similar to how native English speakers don't even realize we have rules for adjective order ("big red ball" vs "red big ball"), while language learners run into it like a brick wall.

replies(4): >>44410542 #>>44410908 #>>44412356 #>>44413399 #
skybrian ◴[] No.44412356[source]
I think that’s true as far as it goes, but there are further reasons why Haskell is more difficult. Here is one:

In Haskell, the lack of parentheses for function calls plus currying means that to read a function call, you need to already know how many arguments the function takes, which I feel adds a new level of difficulty over languages where you can often guess what a function does based on its name, without looking it up.

As a result, often Haskell reads more like math, where without knowing each symbol’s definition, you’re lost.

I’ve seen cryptic JavaScript too, but less often.

replies(1): >>44412590 #
1. jameshh ◴[] No.44412590[source]
> the lack of parentheses for function calls plus currying means that to read a function call, you need to already know how many arguments the function takes

While I agree with the general sentiment of what you are saying, note that the syntax has nothing to do with it, it is purely about Haskell using currying excessively. The syntactic translation between Haskell and JS is straight-forward and 1-1:

    f x y z      ->  f(x)(y)(z)
    f x (y,z) w  ->  f(x)(y,z)(w)
I agree that excessive currying is not great, and generally push for non-curried arguments unless a curried form realy is used in practice. But for this to really be comfortable, and to still enjoy all the hgiher-order programming that's nice with Haskell, we would need good records (strucural, anonymous, extensible), which it doesn't really have right now, so we are stuck with currying.
replies(1): >>44413653 #
2. skybrian ◴[] No.44413653[source]
Yes, you could write the same thing, but defaults and language conventions matter. Writing curried functions in JavaScript is awkward enough that nobody does it by default. If you did, people would ask why in a review.