11–20 of 120 posts
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 Windows is pretty much impossible.
ReasonML is just an alternative syntax for OCaml. Often people use "ReasonML" shorthand for "ReasonML, converted to OCaml, compiled to Javascript with BuckleScript" and "OCaml" for "OCaml compiled natively" but it's perfectly possible (and actually really easy) to use OCaml with BuckleScript and Reason natively. Also note that despite the "O" in the name, OOP in OCaml is rare (for instance, there isn't any in the cod…
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.
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.
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.
I am confused by this article. It went an entirely different direction based on the question proposed. It was all entertaining, nonetheless, but besides some passing comments to Reason’s documentation being better, the question does not seem to be explored much by this article. It’s a good article and should be renamed to maybe “Getting started with OCaml and OpenGL”
The title ("Programming A Space Invader In OCaml and OpenGL: Lessons Learned") still fits with the content, don't you think?
The underlying OCaml naturally. 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.
So it's the Elixir to Ocaml's Erlang?
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.
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.
> 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…
I find OCaml really enjoyable once I got going, but I do think the initial setup is a major barrier to larger adoption. I think a post on howistart.org might be useful, but it'd probably be polarizing since most functions have two major ways of doing it (Jane Street vs. not, Lwt vs. Async, etc.).
Between reasonml and elm which one should I pick?
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.