Because sometimes the layer on top can express ideas more succinctly. A classic example is CoffeeScript's fat arrow syntax. It expressed a pattern in JavaScript we didn't, at the time, have a shorthand for. Example: https://coffeescript.org/#fat-arrow
In fairness, it's dead because it was shitty and made most things harder, and the things it did improve JS copied. If OCaml fixes its syntax, then we won't have any need for Reason.
As a guy who tried to get into OCaml development several times, the language is not the problem at all. It's the several different "standard" libraries, lack of good official agreed upon tutorials and guides, and the fact that it has a GIL and is essentially single-threaded.
If OCaml had Erlang's runtime (parallelism and concurrency via actors with message inboxes) it would likely be the most used language.
Its lack of adoption isn't at all related to syntax IMO. Programmers use all sorts of quirky syntaxes and the world hasn't ended yet.
> As a guy who tried to get into OCaml development several times, the language is not the problem at all. It's the several different "standard" libraries, lack of good official agreed upon tutorials and guides, and the fact that it has a GIL and is essentially single-threaded.
I agree that those things are pain points (I said as much upthread), but clearly the language is also part of the problem or else there would be no interest in Reason.
> As a guy who tried to get into OCaml development several times, the language is not the problem at all. It's the several different "standard" libraries, lack of good official agreed upon tutorials and guides, and the fact that it has a GIL and is essentially single-threaded.
A big reason Erlang is similarly unpopular is its syntax as well (many of the most popular languages are dynamically typed, so we know it's not the type system). This theory is supported by the relative popularity of Elixir, which shares Erlang's runtime and which has enjoyed a fair amount of popularity in a relatively short time despite introducing a number of syntax- and non-syntax-related quirks. OCaml on BEAM would certainly appeal to the intersection of FP and static-typing enthusiasts, but it would not remotely be popular.
> OCaml on BEAM would certainly appeal to the intersection of FP and static-typing enthusiasts, but it would not remotely be popular.
I realise what I said is not an undisputable truth and I wouldn't argue about it. I probably should have just said that I am observing an almost global strive for dev teams to be able to catch bugs earlier and to have a bit more guarantees by the mere virtue of the program successfully compiling. But it might be my filter bubble.
This is why I said an OCaml with the BEAM guarantees would likely rise very high; because my observations lead me to the belief that people want more compile-time guarantees. And yeah, that might be a skewed observation.
> I realise what I said is not an undisputable truth and I wouldn't argue about it. I probably should have just said that I am observing an almost global strive for dev teams to be able to catch bugs earlier and to have a bit more guarantees by the mere virtue of the program successfully compiling. But it might be my filter bubble.
I think this is a pretty broad pattern, but:
1. It's not happening in isolation; there's also a move toward greater development velocity
2. There's lots of low-hanging fruit to be had--lots of people can get tremendous safety benefits by moving from languages like JS and Python to Go or TypeScript or typed-Python even if they don't have as elegant a type system as OCaml (and those alternatives don't require the same tradeoffs as OCaml or even an OCaml on BEAM).
> This is why I said an OCaml with the BEAM guarantees would likely rise very high; because my observations lead me to the belief that people want more compile-time guarantees. And yeah, that might be a skewed observation.
Like I said, I don't think it's a skewed observation, it's just that there are other ways of getting most of those compile-time safety benefits with fewer tradeoffs. But I would be a huge fanboy of an OCaml-like type system on BEAM (especially if it can have Go- or Rust-like attentiveness to practical software engineering concerns).
On the other hand, if Reason were such a massive improvement to OCaml syntax, where are the people clamoring for F# to adopt more of Reason's ideas?
(Admittedly, F# already shares a couple Reason ideas like C-style comments instead of OCaml's traditional ones. So the waters are clearly muddy here to begin with, but a lot of the big things like let-binding scopes and ;; versus ; presumably would be big F# requests if Reason was so strongly superior to the inherited OCaml legacy.)
Maybe I just don't have enough experience, but I use classes in Javascript and TypeScript, as well as constructors, and they look virtually identical to me. What am I missing here?
It is, that's the point. Reason is, as was said upthread, a "veneer". It changes the syntax only, nothing else is different (you can convert back and forth between the syntaxes losslessly). TypeScript makes deep changes to the language by adding type safety.
I have no idea how you got that from my post. I don’t know whether type safety is “a fundamental part of a language” or not, but that’s irrelevant to my point. TS extends the JS syntax to support type safety. Reason changes OCaml’s syntax altogether because it’s broken. Big difference.
Except Fortran and Cobol are pretty much alive, with ISO still releasing languages updates, recently LLVM got a Fortran compiler, supported by the likes of ARM and NVidia.
They are just "dead" in that they are specialized programming languages with a domain of their own, that magpie developers don't find attractive to put on their CV.
CoffeeScript in 2020 is just legacy code that one wants to get rid of, because some juniors found it cool to smuggle into the IT infrastructure.
Opinions are fine, I don’t like CoffeeScript and never have.
It’s no justification to shame someone’s choices when perfectly well working code is usable via what appears to me to be a healthily maintained tool. Less popular? Sure. Would I reach for it to start a new project? no.
Calling it dead though and saying it’s only around because it’s “legacy” and only was used by “cool IT juniors” is shaming a legitimate choice without giving any context or data to back up the assertions
