Programming a space invader in OCaml and OpenGL: lessons learned
1–10 of 120 posts
Re: Programming a space invader in OCaml and OpenGL: lessons learned
#2The 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.
Re: Programming a space invader in OCaml and OpenGL: lessons learned
#3The 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.
> ReasonML seems to be just sugar coating
That’s exactly what it is, no secret about that, that’s the goal of that project.
Re: Programming a space invader in OCaml and OpenGL: lessons learned
#4ReasonML 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 code in the article).
Re: Programming a space invader in OCaml and OpenGL: lessons learned
#5ReasonML 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…
You're right! The toolbox is far better too
Re: Programming a space invader in OCaml and OpenGL: lessons learned
#6The 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.
> 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.
Re: Programming a space invader in OCaml and OpenGL: lessons learned
#7Earlier 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.
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.
Re: Programming a space invader in OCaml and OpenGL: lessons learned
#8Earlier 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.
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
Re: Programming a space invader in OCaml and OpenGL: lessons learned
#9I 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”
Re: Programming a space invader in OCaml and OpenGL: lessons learned
#10Earlier 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.
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.