Skip to content

Comment on Pain Points of OCamlparent

Comments

I stopped fighting this battle a long time ago. I think Ocaml just doesn't spoon feed people enough. They would have to actually read the documentation to understand and that's simply too hard nowadays so you end up which this kind of articles about "pain points" which are basically "I don't know what I'm doing and making a lot of mistakes, let me blame my tool".

The learning process for me has been as follows:

1. Make an error somewhere, maybe due to a misunderstanding

2. Error message makes no sense, or I don't know enough OCaml

3. Re-read the relevant portion of the documentation and examples

4. Hope that I can find the right way to do this somewhere

Compare this to Rust, which treats us quite nicely with descriptive errors that complement a vast and comprehensive reference manual. I do RTFM but a programming language is too big to learn all at once by reading a book before starting programming.

Basically, when someone complaining starts by "I don't like the Algol-like syntax", obviously without saying it's Algol-like because that would require they actually know what Algol is, the rest is probably going to be extremely poor at best.

I am vaguely familiar with ALGOL but have never used it before. Do I need to put down OCaml and learn ALGOL first in order for my syntax complaints to be well-justified?

And here, it doesn't disappoint. Point 2, "I don't like type inference, it's too clever". Or you could just put type annotations at every declarations like every pieces of documentation ever produced on the language invite you to.

I am doing this now, as I stated in the article. Compare against Rust's strictness, where bad ideas like not annotating function signatures are not allowed.

The type paragraph and the mentions of shadowing actually shows the author doesn't know how to use the Ocaml module system. For the neophytes here, it's the main standout feature of Ocaml. It's a bit like talking about C without knowing how to use pointers. I have seen people do that actually so I probably shouldn't be too surprised.

I said in the article that:

Enumerated types also dump all of their variants into the module scope

Is it wrong to say that they dump their types into the module scope? You have to put enum types in separate modules otherwise they will step on each other. (Is this understanding incorrect?) Maybe I will come to appreciate this as I learn more OCaml, but right now it seems like an unnecessary footgun.

Menhir and ocamllex syntaxes are just slight twists on the actual syntaxes of yacc and lex. Nothing surprising for someone who knows both tools but I guess it's becoming a rarity nowadays.

Yes, I know this. The part that I don't understand is why OCaml wants to be like C with these tools in the first place. These tools exist in C because C doesn't have match statements, but OCaml does. What gives?

For printing, they quote "#[derive(Debug)]" in Rust but apparently they never reached ppx_deriving in Ocaml. It's a shame because it does exactly the same thing.

ppx_show is an external library. Imagine having such a cucked stdlib that you have to call to an external library to print

I think a significant part of why Ocaml is nice is that it is not appealing to many developers.

Clearly, that’s why people made a better syntax frontend for OCaml

You don't need an external library to print in OCaml. You just need it if you want to automate deriving a conversion function. OCaml erases types at compile time so the runtime doesn't know anything about types or how to print them. It's just how it works.

Re: better syntax frontend for OCaml. People really tried to, for many years. But it didn't work, there was never much adoption. And the funny thing was that as soon as people got comfortable with it they switched to the standard OCaml syntax because they understood it better and started preferring it. Ironic!

I am vaguely familiar with ALGOL but have never used it before. Do I need to put down OCaml and learn ALGOL first in order for my syntax complaints to be well-justified?

Your syntax complaints will never be well-justified. It’s just a syntax family you are unfamiliar with, not an actual downside. You can either put up with it or change language. The syntax is however in no way inferior to C style syntax because that’s what you are used to.

I am doing this now, as I stated in the article. Compare against Rust's strictness, where bad ideas like not annotating function signatures are not allowed.

There is no point in forcing you. The language doesn’t need to be strict. You can do whatever you want with your type annotation. It works just fine when you do annotate but no one is putting a gun to your head to do so if you just need a quick script. Best of both worlds.

You have to put enum types in separate modules otherwise they will step on each other.

You do but it’s entirely normal and expected to define a new module inside your file in Ocaml and "let open" or assigning module is a common construct. It’s expected that you will not dump everything directly in scope.

The part that I don't understand is why OCaml wants to be like C with these tools in the first place. These tools exist in C because C doesn't have match statements, but OCaml does. What gives?

They exist because generating parsers and lexers are nice and no one wants to learn a new language when they already know yacc and lex.

ppx_show is an external library. Imagine having such a cucked stdlib that you have to call to an external library to print

No need to be vulgar. Ocaml has a lean standard library. That’s how the language is. You want macro and derivations you import them. They exist. Everybody uses them. The comment is a bit rich coming from someone who likes Rust.

Your syntax complaints will never be well-justified. It’s just a syntax family you are unfamiliar with, not an actual downside. You can either put up with it or change language. The syntax is however in no way inferior to C style syntax because that’s what you are used to.

I think match statements should have an explicit `end` terminator or something so that you can nest them naturally. I think errors from accidental partial function application could be clearer. I think those two are pretty objective.

In terms of my subjective opinion the punctuation of C-style makes code hierarchy more clear, but at the cost of making it read less fluidly. I also think that `let...in` is weird and that Rust straddles a nice middle ground here by not having it but still having everything be an expression.

I like strict languages, and I like Rust for its strictness and robustness. I don’t like its standard library though, I wish it was more batteries included.

I think match statements should have an explicit `end` terminator or something so that you can nest them naturally.

It’s unneeded.

You can explicitly delimit any expression in Ocaml by using begin … end or parentheses. It works for everything including match statements which are expressions. So you are already free to use an explicit end statement if you are so inclined.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.