4 ms·

> Because they are not issues on a day to day basis when you use the language. They still are. You just internalize them. Progammers are the world's greatest m

> Because they are not issues on a day to day basis when you use the language. They still are. You just internalize them. Progammers are the world's greatest masochists with the world's biggest Stockholm syndromes, and we don't like to admit it. For example, his pain points about syntax ambiguity are absolutely valid, and true. However, when you "use the language every day" you learn to avoid those constructs and extract them into separate functions for example because "that's how it's always done, and it's a nice little quirk of the language".

WastingMyTime89 3y ago
No, the syntax parts he criticises are not this kind (they are not ambiguous by the way). What’s in the article is very unidiomatic OCaml incorrectly intended purposefully to make it look like it’s doing something else than what it does. You don’t write tuples without parentheses because it’s weird, harder to read and no one does it. Same for the precedence rules of expression. You just use begin and end for blocks like you would use braces in C because you actually want to write a block. No one is just randomly writing nested code without them because well it doesn’t work. It’s not a quirk. The author is just complaining that you have to mark blocks like in every language. That’s a weird thing to complain about. I agree that the lack of as-hoc polymorphism is a downside (I don’t agree with how the article presents it but the article is disingenuous from the start anyway). Everyone would like to have modular implicit.
- illiarian 3y ago
  > unidiomatic OCaml > You don’t write tuples without parentheses > Same for the precedence rules of expression. You just use begin and end for blocks This is exactly what I wrote, but in a Stockholm-syndrome-y way. > The author is just complaining that you have to mark blocks like in every language. He points out a real ambiguity in the syntax where the parser literally parses the same-looking and same-behaving statements completely differently. Sure it's solved by "you just write begin-end" workaround that you internalise. Or it could be solved at the syntax level (like erlang and elixir)
  - WastingMyTime89 3y ago
    > This is exactly what I wrote, but in a Stockholm-syndrome-y way. Do you complain about having to put braces around C expressions to not get unexpected behaviour from the compiler? > He points out a real ambiguity in the syntax where the parser literally parses the same-looking and same-behaving statements completely differently. No, he doesn’t. If that what you got from the article, you were bamboozled. He points out that match, try and (;) have different precedence which is not ambiguous. Writing begin and end is not a workaround. That’s how you mark blocks which is what he should have done because, well, he wants a block. Erlang has exactly the same issue if you write unidiomatic code by the way. That’s unsurprising because "don’t write code implicitly relying on precedence behaviour" is taught to virtually all beginners in most programming languages.
    - lmm 3y ago
      If you shouldn't write code that way then it should be a compilation error (or at the very least a warning) to write code that way.
      - WastingMyTime89 3y ago
        I’m not sure I agree. It’s perfectly legitimate code and working code. It’s just hard to read. Should language prevents you from writing hard to read code if it means making trade off? I personally think that’s what linters are for but you are free to disagree. I’m going to bed and don’t think I will revisit this comment thread. It’s probably the longest discussion I ever had about syntax points you don’t even encounter while using the language. I have fond memory of writing OCaml. It’s nice to use. It gets out of your way. The compiler is quick. It gives nice error message. The syntax and semantics are flexible enough and elegant enough than you don’t feel like your fighting the language and your code feels nice. That’s what matters to me at the end of the day.
      - hajile 3y ago
        Is there ANY common language without TONS of ways to write bad code? Is there ANY such language at all regardless of popularity?

WastingMyTime89 3y ago

No, the syntax parts he criticises are not this kind (they are not ambiguous by the way). What’s in the article is very unidiomatic OCaml incorrectly intended purposefully to make it look like it’s doing something else than what it does. You don’t write tuples without parentheses because it’s weird, harder to read and no one does it. Same for the precedence rules of expression. You just use begin and end for blocks like you would use braces in C because you actually want to write a block. No one is just randomly writing nested code without them because well it doesn’t work. It’s not a quirk. The author is just complaining that you have to mark blocks like in every language. That’s a weird thing to complain about. I agree that the lack of as-hoc polymorphism is a downside (I don’t agree with how the article presents it but the article is disingenuous from the start anyway). Everyone would like to have modular implicit.

illiarian 3y ago
> unidiomatic OCaml > You don’t write tuples without parentheses > Same for the precedence rules of expression. You just use begin and end for blocks This is exactly what I wrote, but in a Stockholm-syndrome-y way. > The author is just complaining that you have to mark blocks like in every language. He points out a real ambiguity in the syntax where the parser literally parses the same-looking and same-behaving statements completely differently. Sure it's solved by "you just write begin-end" workaround that you internalise. Or it could be solved at the syntax level (like erlang and elixir)
- WastingMyTime89 3y ago
  > This is exactly what I wrote, but in a Stockholm-syndrome-y way. Do you complain about having to put braces around C expressions to not get unexpected behaviour from the compiler? > He points out a real ambiguity in the syntax where the parser literally parses the same-looking and same-behaving statements completely differently. No, he doesn’t. If that what you got from the article, you were bamboozled. He points out that match, try and (;) have different precedence which is not ambiguous. Writing begin and end is not a workaround. That’s how you mark blocks which is what he should have done because, well, he wants a block. Erlang has exactly the same issue if you write unidiomatic code by the way. That’s unsurprising because "don’t write code implicitly relying on precedence behaviour" is taught to virtually all beginners in most programming languages.
  - lmm 3y ago
    If you shouldn't write code that way then it should be a compilation error (or at the very least a warning) to write code that way.
    - WastingMyTime89 3y ago
      I’m not sure I agree. It’s perfectly legitimate code and working code. It’s just hard to read. Should language prevents you from writing hard to read code if it means making trade off? I personally think that’s what linters are for but you are free to disagree. I’m going to bed and don’t think I will revisit this comment thread. It’s probably the longest discussion I ever had about syntax points you don’t even encounter while using the language. I have fond memory of writing OCaml. It’s nice to use. It gets out of your way. The compiler is quick. It gives nice error message. The syntax and semantics are flexible enough and elegant enough than you don’t feel like your fighting the language and your code feels nice. That’s what matters to me at the end of the day.
    - hajile 3y ago
      Is there ANY common language without TONS of ways to write bad code? Is there ANY such language at all regardless of popularity?