Comment on Which programming language is hard to understand?

noproblemmy@programming.dev ⁨8⁩ ⁨months⁩ ago

• dneaves@lemmy.world ⁨8⁩ ⁨months⁩ ago

  Haskell for sure has a very sloped learning curve. The functional style, different syntax, a myriad of symbols and pragmas, as well as the tooling around it.

  The only reason I was able to pick it up as quick as I did was because I was used to Elm due to my job. Then it was just learning about the IO type (and how to use it), cabal, stack, built-in symbols, and the most common pragmas.

  But the symbols part is especially harsh, since symbols only hold meaning if they’re universally understood. Sure, the base- language ones are kinda adopted at this point, so they’ll stay, but the fact that external modules can also make symbols (sometimes without actually-named counterparts) adds some confusion. Like, would you just know what .: is supposed to mean off the top of your head?

  source

  • marcos@lemmy.world ⁨8⁩ ⁨months⁩ ago

    Like, would you just know what .: is supposed to mean off the top of your head?

    Yeah, it’s point-free shenanigans people use for code-golf and satisfying the linter.

    If you caught yourself using it, you should probably reevaluate.

    source
• FizzyOrange@programming.dev ⁨8⁩ ⁨months⁩ ago

  I agree. OCaml too. I think there are several factors that lead to it being very difficult to read other people’s code:

  • Currying and lack of syntax in general means you have to be a human parser for basic things like “which part of the text is a function name? which bits are arguments?”. Often it’s impossible to tell without looking up the function definitions.
  • The functional style - while generally great - also makes it very tempting for people to write enormous heavily nested functions where the control flow is hard to follow. You sometimes get assignment expressions that are hundreds of lines long.
  • Haskel & OCaml feature global type inference. Programmers often omit explicit type annotations which very often means that function types are inferred as generic. This means you lose several huge benefits from static types. For example you can no longer look up the types that will actually be passed into the function, and inferring the authors intent is much harder. It also makes error messages way more confusing.
  • I don’t know why but Haskel and OCaml programmers love stupidly short identifiers.
  • They also abhor comments.

  source
• JackbyDev@programming.dev ⁨8⁩ ⁨months⁩ ago

  Same here. The syntax is just different enough from the C family for it to totally scramble my brain.

  source
• Chobbes@lemmy.world ⁨8⁩ ⁨months⁩ ago

  I like Haskell, but the syntax is probably the worst part about it. The ability to define your own infix operators with arbitrary precedence / associativity is really cool and useful, but can make it a complete mess to read because then you have no idea how any of the operators combine. I vaguely like the syntax, there’s something kind of clean about it, but frankly if it was just a lisp it would be so much easier for people to pick up (aside from the fact that nobody would because it would look like lisp).

  source
• Knusper@feddit.de ⁨8⁩ ⁨months⁩ ago

  I write tons of functional code and am still no fan of Haskell’s syntactical choices.

  It’s trying to look like basic English or maths equations, when programming is not that. Programming has more concepts. And those concepts deserve being denoted by punctuation.

  source