Comparing Objective Caml and Standard ML

Hum, panic as in stop all work ?

I like that in Java, units of work can continue after an unhandled exception because you know, sometimes, your software is used by many people in many input variants and say, if you re doing a trading backend, it's bad that you cant fill an order because of a silly parsing bug, but it d be way worse if you had to stop for the day until a dev wakes up and fix it.

Log it, and while you fix it the thing still runs for 99% of inputs. Maybe that s what you call "handling" the error ? But it's cool to bubble up the exception because you can share the handler amongst all your downstreams: you may dislike having to do the same exact semi-complex log building everywhere and having it just capture exception at the top most unit of work dispatcher to catch if one threw something to then log and alert your support team in one place, might make sense.

Ofc return types can do all that but you contaminate your whole program with handling for bugs you cant well predict the nature off... the only certain thing is that if your program is old and big enough, you'll screw up in innovative ways a general catch will allow to recover from, because you just dismiss the whole input and move to the next.

This is exactly the Cocoa exception model: Exceptions are treated as assertions, while errors represent things the program or user should be able to act on and recover from. Swift reifies this by not having exceptions at all, just fatal assertions like precondition() and fatalError(), while using try/throw/do/catch for propagation of errors (and making handling them non-optional).

I view checked exceptions as syntactic sugar on what could be implemented as result types (as in “Either” result types) behind the scenes. It’s not how they are implemented in Java, but potentially they could. When used in that fashion, they are certainly more ergonomic than explicit result types. Being (type-)checked is crucial for that, of course.

Exceptions will come back, but in the form of algebraic effects. All of the work that goes into error handling, asynchrony, mutable state, and IO will be generalized by effects.

I would argue that panicking very much makes it somebody else's immediate problem.

By this logic, it kind of seems like no function should ever return errors at all -- handle the situation or panic, right?

Sure, kicking the ball up the chain out of laziness is, well, laziness. But plenty of times, it's done out of the knowledge (or at least hope) that somebody up the chain has a better idea of how to handle the situation than you do.

Sometimes a nonlocal goto is exactly what you want.

Consider some kind of validator/parser class/function, with a public entrypoint and a bunch of private subroutines that can fail when they hit invalid input:

    public parse() {
      try {
        this.parseX();
        this.parseY();
        this.parseFoo();
        ...
      } catch (e) {
        throw new Error(...)
      }
    }
    private parseY() {
      this.y = this.input.y.map(a => {
        if (bad data) throw new Error("corrupt data");
        ...
      })
    }

It's common in such situations to want to have one central point to collect errors in order to produce a single error type result.

It is possible to manually thread Results all the way through your logic, but that clutters the code with error handling. Rust's Try operator makes it easier but it's still awkward.

Exceptions allow us to concentrate on the two most important parts: where the exceptions are generated, and where they are handled (in this case, the root of the public interface).

I definitely agree that exceptions are not perfect. They have their own flaws, especially for public interfaces. But as control flow they are useful in many cases.

I'm holding out for the wave of logic / declarative / relational programming. That's my nerd preference.

I am highly bullish on systems programming. As high performance computing becomes more important, so esoteric hardware will. I work in embedded and see some of this, as have my friends in the ML space.

We’ll see the Zigs, Nims and Rusts of the world mature along with special languages for things like tensor processing units. AI will make it much easier for humans to work using those languages.

I tried to take up Haskell some years after playing with SML/NJ and OCaml, and I just found it ... so hard to read. Not enough syntactic sugar or hints? I wanted to fall for it, but couldn't.

That and the community around it was so enamoured with Deep Intellectual Ponderings and Very Novel Arcanities. That was good, sure, but ... hard.

MLTon has an LLVM backend which you can choose by passing a CLI flag. As always though, using LLVM makes the compilation slower.

I mean zero to one is still "more" right?

Anyway thanks idk shit about type theory and I didn't go to college I just write code for money.