41–50 of 120 posts
Earlier quoted context omitted.
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.
There isn't anything to fix.
Earlier quoted context omitted.
Which begs the question why not learn the real deal, instead of adding another layer to debug. Programing isn't poetry.
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 manag…
Earlier quoted context omitted.
What's the state of using Reason natively? Last time I checked all the documentation and examples where towards the reason/js/react ecosystem. Are there any good native code projects written in Reason to look at for reference?
Check out Oni Vim 2: https://github.com/onivim/oni2/blob/master/README.md
> it is very complicated to install the base stack to develop in OCaml I'm not sure why the author decided to use such a complicated setup using Make and Docker. They could have just ran `opam switch create 4.09.0`, which would have created the compiler, then `opam install ...` for the dependencies. Still, an interesting article. I wouldn't recommending using OCaml/ReasonML for gamedev since getting it to work with W…
While I didn't try to use Docker (though we did use the same pxhere image :-p), I also struggled to get a productive setup of OCaml. Getting a switch running wasn't the hard part, it was making the environment suitable for real project work. I had a set of Make targets in mind (test, build, shell), some language dev features I wanted (jump to definition, type of expression under cursor), and some properties of the pr…
Earlier quoted context omitted.
> ReasonML seems to be just sugar coating That’s exactly what it is, no secret about that, that’s the goal of that project.
Which begs the question why not learn the real deal, instead of adding another layer to debug. Programing isn't poetry.
[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.
Earlier quoted context omitted.
While I didn't try to use Docker (though we did use the same pxhere image :-p), I also struggled to get a productive setup of OCaml. Getting a switch running wasn't the hard part, it was making the environment suitable for real project work. I had a set of Make targets in mind (test, build, shell), some language dev features I wanted (jump to definition, type of expression under cursor), and some properties of the pr…
I agree it's quite annoying to set up an OCaml project, and all the Jane Street stuff makes it even more confusing for newcomers. But to be fair, it may be the case with other languages as well. I recently tried to learn some Javascript, and I spent some time understanding the tooling and package management (npm/yarn, bundling, transpiling, node vs browser, difference between javascript versions).
Earlier quoted context omitted.
If you've not used an ML before, start with Elm. Once you feel you have that sussed - it shouldn't take too long - pull up ReasonML and give it a go. Use the Bucklscript-Tea library - the architecture will be familiar from Elm. Then give Reason-React a go. Once that itch has been scratched move on to PureScript for a whole new rabbit hole to fall down.
I mean I'm familiar with ml and haskell, I'm more interested in what's the best platform for building things. The language itself is only a part of the equation.
Reason still hasn't had its async story ironed out, and has poor support for Unicode[0]
[0] "ReasonML strings are encoded as UTF-8 and not compatible with JavaScript’s UTF-16 strings" (from https://2ality.com/2017/12/basic-types-reasonml.html)
Earlier quoted context omitted.
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
And now it is dead, leaving behind a pile of code to rewrite in next cool toy.
https://github.com/jashkenas/coffeescript/
Its not as popular to be certain, though.
Between reasonml and elm which one should I pick?