- Reason, a different syntactic frontend for regular OCaml: https://reasonml.github.io/

- ReScript, a language with OCaml semantics that compiles into: JS https://rescript-lang.org/ (I suppose it's a reincarnation of js-of-ocaml).

I think you’re being generous. The example the author gave is awful because any language can be made illegible if you cram in complicated expressions with multiple levels of nesting into a single line. I’d say it’s outright flamebait.

Apparently, the author hasn't come around to understanding that functions are just another constant.

Xah Lee is not exactly known for moderation. If you’re not familiar, browsing the site may be worth your while. It’s full of inflammatory and sometimes bizarre takes, but I’d be hard pressed to argue that it’s ill informed.

Yes, it's clearly one of the syntax weak point. You can surround them with parentheses or begin ... end to make things explicit but the default is definitely error prone.

however, my university has a mandatory class taught in ocaml, which i've ta'd for a few times; this is the _number one_ "the undergrad ta couldn't figure out my syntax error" issue students have

The match terminator end thing made me sad when I first saw this in Ocaml. So many languages (C, bourne shell, etc etc) have this exact same problem and it completely sucks in all of them. It's more debilitating in a functional language specifically because matches are more useful than say C case statements so you want to use them much more extensively.

I frequently want to do a pattern match to unpack something and then a further pattern match to unpack further - a nested match is a very intuitive thing to want. Yes you can normally unnest such a match into more complicated matches at the parent level but this is usually much harder for humans to understand.

...and if you had a marker for ending match scopes you could always just reuse that to end let scopes as well if you wanted to although I've literally never a single time run into that as a practical problem (although I haven't written that much OCaml you'd think if it was a real issue I would have banged into it at least once because I found a fair few sharp edges in my time with the language).

Very often this leads to typing errors. Otherwise it's caught by autoformat (which everyone should be using). But even without that, this is one pitfall every OCaml developer is aware of.

I'm not arguing the syntax is perfect, but I wouldn't say it has a serious problem because of that. Never seen that being a problem.

I never really seen someone put that into words. I always feel a certain kind of weird when I look at a language with tons of punctuation (Typescript is good example).

    let x = 1
    and y = 2
    and z = 3 in
    x * y * z

I'm pretty sure it's "working on a codebase" that kills your soul, not the minutae of particular language choice.

Sometimes I wrote (haven't written OCaml for some time now..) functions like:

    let foo: int -> int = fun x ->
      ..

    val foo: int -> int

After reading OCaml From The Very Beginning my stance softened. Learning PURE OCaml is a must. (if you want to do AoC with it). You may find yourself bringing in Core or Base, after you've got a good idea of a solution.

It's definitely a fun language for doing AoC... but it can become extraordinarily frustrating when you hit a wall and all the StackOverflow answers assume Core.

That's an extremely good thing.

Unordered definitions and where are some of Haskell worst decisions with lazy by default, overuse of operators and a community which sadly think point-free is desirable.

That's the kind of choices which makes Ocaml a lot more readable.

I have seen many devs that prefer the Java imperative style over more functional chained style. Could be an outcome of leetcode style interviews or that most CS programs start with C/python/Java style languages but it's not uncommon to see that preference especially among junior devs

Rephrased: ocaml is so flexible that async can be implemented as a library with no special support from the language.

This is the beauty of ocaml (and strongly typed functional languages more broadly)

I found F# to be more pleasant to work with async than C# (which is already a breeze). It is true that you still have to define 'task' (or 'async' if you want to use Async CEs) but it is generally there for a reason. I don't think it's too much noise:

    let printAfter (s: float<second>) = task {
        let time = TimeSpan.FromSeconds (float s)
        do! Task.Delay time
        printfn $"Hello from F# after {s} seconds"
    }

   type 'a Tree = 
     | Node of ('a Tree, 'a Tree)
     | Leaf of 'a

Then when you concrete-ize it, you have an "int Tree" or a "string Tree".

This is a little clearer with thinking of the List datatype: this is a number list, that's a string list, that's a grocery list, this is a guest list...etc.

One nice thing in F# is that there's an ability to "standardize" how you write generics to look more like the (admittedly arbitrary) way that C# or Java or C++ write them:

    type Tree<'a> =
      | Node of (Tree<'a>, Tree<'a>)
      | Leaf of 'a

[1] https://ocaml.org/manual/5.2/bindingops.html

* An auto-formatter (ocamlformat integration in your editor, or ocaml-top) that shows how the actual nesting looks like

* You can add ;; at the end of a top-level function to get a syntax error at a better location

* Use the LSP integration of your editor which will show you where the error is as you type, so you catch the problem early

Help me out here, what's the threat model here while reading troll programming blogs?