This is a great achievement for OCaml, but does anyone have an explanation on why it was so difficult to implement for them?
He stated that albeit he spent years working with Lisps (CL and Racket mostly) or Haskell he stated that jumping on projects in those languages instantly requires you pay the price of having to learn the abstractions and DSLs that the users wrote for the project before being able to understand anything.
He compared it with C or Go, where he realized that it was easier to him to read kernel code without any context, because there is no abstraction price to pay. What you see is what there is to understand.
He basically says that those languages (MLs, Lisps) are great for personal projects or very small teams but they don't scale well, this also reflects on open source where many will build their libraries and programs, but very few get into collaborating in those communities.
To paraphrase: The idea being that a well designed library api gets you 90% of the benefits of a richer language’s features, but without exactly that penalty that Carmac calls out.
I don't get it. In C you're programming with structures, data types and functions. In ML and Lisp, you're programming with structures, data types and functions. Lisp lets you muck with syntactic forms so maybe that has some obscuring effect, but I expect most programs are written in fairly direct style. Where people do add abstractions, it's to reuse code so there's ostensibly less code to understand overall.
It does create dialects and potential silo effect. I never worked in real CL projects but books and articles mention to not abuse macros and DSLs because of that, old lispers are also often very educated .. and they rarely do things for trivial reasons. I'm regularly surprised by how well thought out things are.
IMO, OCaml is significantly easier to ramp up on than Haskell. The object model and the fact that the language allows you to ramp up on imperative code let you write working code and the language is feature rich enough you're not generally writing a DSL. Granted, I think it is still harder to ramp up programmers than in JS, Python, Java, or Go.
I think OCaml's biggest problem has been one of timing and value proposition. The language matured to some level of production readiness in the mid 2000s at which point multicore started to become important.
If you wanted extreme performance, OCaml increasingly couldn't compete with C++ or Java. Most shops don't the robustness the superior type system could provide and the other downsides of an unpopular language always loomed large when adoption was being considered.
I still think OCaml or something OCaml-like might become popular with time, but it will require the kind of improvements the multicore project is hinting at providing and more.
In F#, even for some DSLs, there's not much funny business at all. You have types and functions. I'm not as familiar with OCaml, but in F#, the only really confusing thing along the lines of DSLs or macros are computation expressions. But for the most part, you don't need them aside from the built-in `async` one.
For industrial applications in most deployment environments Haskell is a much more practical language than OCaml, due to having many more modern runtime features (green threads, STM, etc., that for many years have made the lack of multicore support in OCaml seem embarrassing). It's not really that that gap has been caught up to now either, OCaml is still many years behind Haskell in basic runtime features.
F# obviously has a practically useful and featureful runtime, but has a scheduler that makes it easy to get thread exhaustion, whereas Haskell has a preemptive one that will make that a non-issue.
I find that the "practical language" argument is usually used by people who have never used either OCaml or Haskell for solving real world problems. In practice OCaml is a did-not-finish versus the comparatively (to most other languages, notably losing to the BEAM languages) excellent finishing time of Haskell.
Also, to elaborate on my reply to Carmack, I think he is grossly underestimating the prevalence of esoteric implementations and DSLs in C, C++, and their ilk.
And yes, Elixir and Erlang, especially Elixir, are very practical languages. I'm hard pressed these days to look any further than F# or Elixir for projects because they effectively cover all bases from soft real-time embedded and up.
The language is a mess. The compiler is slow. Performance is poor. The community is insufferable.
I think that what is meant by practical.
But the rest of this is nonsense. The compiler is a flat out miracle, a monument to human understanding, and produces unbelievably fast programs given the weird and wonderful abstract material one hands to it.
There may be different constraints for other runtimes.