← Back to context

Comment by qsera

11 hours ago

> It's important to emphasize that a particular group of "words" constitutes a function call, or a variable definition, or a type definition -- whatever the language has to offer.

Syntax highlighting? Please take a look at https://play.haskell.org/

I am completely baffled by this comment. Are you missing the parenthesized function calls by any chance? If so then I can relate a bit.

No, it's not syntax highlighting.

For background: my first time in college, I was studying typography. An integral part of this trade is figuring out what is easier for people to read by answering questions s.a. what is the best line length, what number of columns per page is the best, what number of ascent elements per font face is the best, considering letter frequencies and coincidence and so on.

It also comes with the editing part, as in the trade of taking a manuscript (a text intended to be published) and making sure that the text meets certain reader expectations in terms of consistency, clarity, structure. This, obviously, includes the use of punctuation, but it's more about the language structure, things like adjectives order or anaphora usage etc.

Programming languages can be judged using the same rules, because, in the end of the day, we read them and need to interpret them. People have particular strengths and weaknesses when it comes to reading: we can remember the anaphora's anchor for only so long, we can hold only so many "variables" in fast-to-access memory, we only can do so many levels of adverb phrase nesting and so on.

Haskell was designed by someone completely oblivious to human abilities to read. It's very demanding and straining when it comes to extracting structure from text in the same way how, in English, you'd struggle to extract structure from so-called "garden path" sentences, because it's intentionally obfuscated. I don't believe Haskell is intentionally obfuscated, instead, I attribute the poor performance to the lack of awareness on the part of the author.

To convey the same point by means of example: Haskell is almost uniquely bad in that given a program

    A B C

the programmer can't tell if the program is actually A(B, C), or B(A, C), or C(A, B), or A(B(C)), or A(C(B)), or (A(B))(C), or (B(C))(A), or (B(A))(C), or (C(B))(A).

There's absolutely no reason a language should offer these kinds of puzzles, especially in a very large quantity as Haskell does. Removing this "feature" would make the language a lot easier to work with.

  • In Haskell it's only ever one of (A(B)(C) or (B(A)(C), and you can tell which based on which characters B is made up of. If B starts with one of !#$%&*+./<=>?@\^|-~` it's the second situation, otherwise it's the first.[0] All functions are unary in Haskell so A(B, C), B(A, C) and C(A, B) can never actually happen. The cases where it looks like A(B(C)), etc. are happening are actually cases of (B(A)(C), e.g. f $ g is a (B(A)(C) case where B=$. So the basic syntax of Haskell is actually very simple and consistent, but due to lazy evaluation the functions can affect control flow much more than in other languages.

    0: OK, there are some additional non-ASCII Unicode symbols, but everything but string literals should be kept ASCII IMO.

  • > the programmer can't tell if the program is actually

    What do you mean, "can't tell"? If I see this in Python

        (A)(B)(C)
    

    how do I know which of your 9 it means? Well, I'm a Python programmer so I know that it means

        A(B)(C)
    

    which is the function A applied to B, which returns a function that gets applied to C. If you're a Haskell programmer you know that it means the same thing.

    I grant you that it is odd to those who are unfamiliar and it took me quite a while to get used to it, but it's much better to write that way in Haskell when writing programs that use higher-order functions.

  • Mmm.I think I understand where you are coming from. You can write incomprehensible code in Haskell very easily and I agree that some people tend to write Haskell in a way that is easy when writing but very hard during reading.

    But that is a choice. I prefer not using complex function compositions and the lenses due to this, split complex expressions into a bunch of let bindings etc..

    So you also can write very readable code in Haskell.