Having learned ML via Objective Caml's predecessor, Caml Light, ReasonML seems to be just sugar coating for those with aversion to ML classical syntax.
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
If it works properly there isn't another layer to debug (and anyway, one has to debug OCaml's syntax as it is, so it's more like trading one debug layer for another). I've never had to debug into assembly before, for example. And while syntax is normally just superficial, OCaml goes out of its way to be obscure and I don't have time for that. Especially with all of its other warts (stdlib issues, crappy package management, crappy build tooling, still no multithreading, etc). I eventually just gave up. Which is too bad because the type system (absent the OO stuff) could be useful.
I disagree, code is for and by humans. There are likely very real runtime consequences to having code that is "ugly", because the next human to touch it will value it less and do a suboptimal job.
Of course all of this is highly subjective, but my understanding is that it's important to consider if you want highly successful projects.
I think this is very much domain dependent. Generally the more important efficiency is, the less I find this to be true. And really, code is always for the machine at the end of the day.
Additionally, if an added code layer makes the code more difficult to debug, that's also making the code worse for humans. Note I'm not arguing for or against whether that's happening in the case of OCaml/ReasonML, just making the point.
> code is always for the machine at the end of the day
On the other hand, code is read much more than it is written.
You may also regard efficiency as a necessary evil if the cost is readability.
Ultimately the winning strategy in this regard is achieving "free abstraction", making code that is both readable and efficient. Different languages aim at this. C++ has been best at this for most of history. Haskell and Rust are competing at this now as well.
OCaml isn't exactly efficient because of free abstraction, but because of its extremely simple translation strategies. OCaml's "flambda" compiler extension wasn't released as stable until 4.03 (2016), which means that before that, very little high-level transformation was happening.
My experience is that OCaml programmers care about low-level optimization, for good and for bad.
For example, in this StackOverflow response there are two examples of a function 'partialsums':
The one that Jeffrey Scofield provides is essentially more efficient because the accumulated value is a list, just like the end result, whereas my solution accumulates a tuple, which means every iteration of the fold involves boxing and unboxing that tuple. An optimizing compiler working at a higher level of abstraction might figure that out and re-use the memory of the tuple, but no sir.
You could say the same thing about Erlang and Elixir.
Or Java and Kotlin / Scala.
Depending on how well an alternative syntax is requested and adopted by the existing ecosystem surrounding the particular VM, YMMV. Without knowing, I think you get quite different answers in each case.
Jordan Walke, the creator of Reason (also the creator of React) said that syntax is unfortunately very important, because psychologically people want something familiar. I think syntax is totally superficial, but I’m also a human who interacts with other humans. And they do not think it’s superficial.
Maybe if Go didn't start as a hobby project inside Google, then they /might/ even have seen some opportunity in Ocaml / Standard ML, but now that Go exists, and has a quite good toolchain, the incentive is low. Go and its foundations are radically different from a FP language like OCaml though.
Programming is expressing programmer intent to the greatest extent possible given technological constraints. Sometimes, that's moving from machine code to assembly language[1]; sometimes, that's building a declarative language to express some specific logic. Finding new ways to preserve programmer intent in machine-checkable ways (that is, not just by adding comments) is one of the consistent goals of programming language design.
[1] Yes, humans used to write machine code. By hand. Computers were for serious work, not mere clerical tasks such as translating mnemonic order codes to binary and doing address arithmetic.
Neither one is more real than the other and you really shouldn't need to do any debugging unless there are bugs in the ReasonML parser (and you could just as easily run into a bug with the Ocaml parser, but I suspect both are very unlikely).
reason isn't another layer, it's an alternate syntax. it doesn't compile via translation to ocaml code; both reason syntax and ocaml syntax compile to the same thing.
Elixir is a different language for the Erlang VM, but Reason is just a different syntax for the OCaml language. There's a 1:1 correspondence between their ASTs, and even a tool to convert between them.
That's one of the main ideas, certainly. The thesis is that there are a ton of people who would take one look at the ML syntax and go back to their Java/C#/JavaScript, not realizing there's more to it. But with Reason syntax (which btw was designed by the creator of Merlin), they would take another deeper look.
For people like you and me, we like the ML syntax and don't have too much need for a new one. But for many others, this may be the only way they will ever even decide to look at an ML. And hey–if after that they decide that they actually like the ML syntax better–well that's one of the 'secret' goals of Reason.
Having learned ML via Objective Caml's predecessor, Caml Light, ReasonML seems to be just sugar coating for those with aversion to ML classical syntax.