5 ms·

To be honest, anyone who used Ocaml understands immediately that the author gave it no chance and went looking for problems. It’s obvious because the post linge

To be honest, anyone who used Ocaml understands immediately that the author gave it no chance and went looking for problems. It’s obvious because the post lingers a lot about things which are not actually issues like type conversion but don’t talk about the very real issues Ocaml has (opam is not great, dune is weird).

hardwaregeek 3y ago
Why are these things not issues? I think it's totally valid for someone who doesn't understand OCaml to raise issues of usability or documentation. It's not just the issues of experts that are a concern. And it's very demoralizing to get a "you're holding it wrong" response to a complaint.
- WastingMyTime89 3y ago
  Because they are not issues on a day to day basis when you use the language. I used Ocaml for a paid internship some years ago. I was very much a beginner. Do you know how many time I felt at loss or annoyed by type conversion or the precedence rules for various part of the syntax? I never did. The truth is you never encounter the precedence rules when writing Ocaml normally using parentheses like a normal human being and you don’t convert that much between exotic types. Most of the conversion you actually do are between the same types and most of the time you have to write converter anyway because there is logic involved. I worked professionally as a Java developer for a bit. I think I had to write more conversion code between weird classes then than I ever did in Ocaml. The issue is not telling people they are "holding it wrong". The issue is that this is not what’s going to annoy you as an Ocaml beginner. The author of this article is not even an Ocaml beginner by the way. That’s actually someone who used to work on the Haskell compiler.
  - ModernMech 3y ago
    > The issue is that this is not what’s going to annoy you as an Ocaml beginner. Sure, but tbf, the post is about what annoys the author, not what would annoy beginners. As you say, the author is not a beginner, and so their problems wouldn't be beginner problems.
    - WastingMyTime89 3y ago
      That’s not the point I was making. They are not expert problems either. How often as an expert do you think you encounter precedence issues you were not encountering as a beginner?
  - illiarian 3y ago
    > 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)
        3y ago
boxed 3y ago
It sounds like it's weird and annoying to convert a value to a string. That's pretty damning. Did I misunderstand?
- hajile 3y ago
  Primitive conversions are as simple as `<type>_of_<newType>(myValue)`. For example, `int_of_float(2.0)` will give you an integer. `string_of_int(123)` will return a string. Noting very surprising. If you want to do more complex conversions, you have to write those functions and call them. I don't much care for Ocaml syntax (StandardML is a better language in basically every way and ReasonML is Ocaml with better syntax), but this isn't a big deal.
  - boxed 3y ago
    That's terrible though. How can that possibly work if the type is not hardcoded? How can you write code that works on any type like that?
    - hajile 3y ago
      The type system will know if you don't handle a potential conversion. This restriction is better for pretty much every real-world use case anyway. If you don't know what you're converting, then you are almost guaranteed to be getting garbage out the other end. If you do know what you are converting, being explicit and covering all your options isn't a big deal. And of course, you can pack this all away in a module if you really want too. Modules are more flexible than typeclasses in a language like Haskell anyway (as you can't have multiple typeclass definitions in Haskell). In truth, I believe module typeclasses (typeclasses only definable in modules) would be a nice addition. It would allow flexibility while creating a pattern that actively discourages the abuse you see in Haskell where typeclasses quickly devolve into unreadable garbage.
- belmont_sup 3y ago
  If Ocaml fixes this and makes opam/dune play in the same field as cargo, life would be great as an ocaml programmer. Sometimes I go back to F# and sigh because I can just print any complex data structure. Sure, there’re limits, but it’s just one less pain. Regardless, really enjoy everything else. I cloned and built the Dune repo to try to help fix something. Compiled very quickly for its size.
GeorgeWBasic 3y ago
I've been using opam and dune for a few years now and they haven't annoyed me much since I got used to how to set up projects. What are the issues with them?

hardwaregeek 3y ago

Why are these things not issues? I think it's totally valid for someone who doesn't understand OCaml to raise issues of usability or documentation. It's not just the issues of experts that are a concern. And it's very demoralizing to get a "you're holding it wrong" response to a complaint.

WastingMyTime89 3y ago
Because they are not issues on a day to day basis when you use the language. I used Ocaml for a paid internship some years ago. I was very much a beginner. Do you know how many time I felt at loss or annoyed by type conversion or the precedence rules for various part of the syntax? I never did. The truth is you never encounter the precedence rules when writing Ocaml normally using parentheses like a normal human being and you don’t convert that much between exotic types. Most of the conversion you actually do are between the same types and most of the time you have to write converter anyway because there is logic involved. I worked professionally as a Java developer for a bit. I think I had to write more conversion code between weird classes then than I ever did in Ocaml. The issue is not telling people they are "holding it wrong". The issue is that this is not what’s going to annoy you as an Ocaml beginner. The author of this article is not even an Ocaml beginner by the way. That’s actually someone who used to work on the Haskell compiler.
- ModernMech 3y ago
  > The issue is that this is not what’s going to annoy you as an Ocaml beginner. Sure, but tbf, the post is about what annoys the author, not what would annoy beginners. As you say, the author is not a beginner, and so their problems wouldn't be beginner problems.
  - WastingMyTime89 3y ago
    That’s not the point I was making. They are not expert problems either. How often as an expert do you think you encounter precedence issues you were not encountering as a beginner?
- illiarian 3y ago
  > 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)
      - 3y ago

boxed 3y ago

It sounds like it's weird and annoying to convert a value to a string. That's pretty damning. Did I misunderstand?

hajile 3y ago
Primitive conversions are as simple as `<type>_of_<newType>(myValue)`. For example, `int_of_float(2.0)` will give you an integer. `string_of_int(123)` will return a string. Noting very surprising. If you want to do more complex conversions, you have to write those functions and call them. I don't much care for Ocaml syntax (StandardML is a better language in basically every way and ReasonML is Ocaml with better syntax), but this isn't a big deal.
- boxed 3y ago
  That's terrible though. How can that possibly work if the type is not hardcoded? How can you write code that works on any type like that?
  - hajile 3y ago
    The type system will know if you don't handle a potential conversion. This restriction is better for pretty much every real-world use case anyway. If you don't know what you're converting, then you are almost guaranteed to be getting garbage out the other end. If you do know what you are converting, being explicit and covering all your options isn't a big deal. And of course, you can pack this all away in a module if you really want too. Modules are more flexible than typeclasses in a language like Haskell anyway (as you can't have multiple typeclass definitions in Haskell). In truth, I believe module typeclasses (typeclasses only definable in modules) would be a nice addition. It would allow flexibility while creating a pattern that actively discourages the abuse you see in Haskell where typeclasses quickly devolve into unreadable garbage.
belmont_sup 3y ago
If Ocaml fixes this and makes opam/dune play in the same field as cargo, life would be great as an ocaml programmer. Sometimes I go back to F# and sigh because I can just print any complex data structure. Sure, there’re limits, but it’s just one less pain. Regardless, really enjoy everything else. I cloned and built the Dune repo to try to help fix something. Compiled very quickly for its size.

GeorgeWBasic 3y ago

I've been using opam and dune for a few years now and they haven't annoyed me much since I got used to how to set up projects. What are the issues with them?