Live data from Hacker News

Programming a space invader in OCaml and OpenGL: lessons learned

marmelab.com

31–40 of 120 posts

Re: Programming a space invader in OCaml and OpenGL: lessons learned

#31
post #25

ReasonML is adversely affected by it's Ocaml base if anything. StandardML would have been a much better base (they went with Ocaml because it was a lower-effort to implement and Facebook has a lot of Ocaml devs). The first bad part is that Ocaml does not have a language spec. The implementation is the spec. This puts them at the whim of the Ocaml devs with no other options. SML is a standard with several good impleme…

FYI strings are now immutable in OCaml. It was a compiler option starting with 4.02 and it has become enabled by default since 4.06.

Re: Programming a space invader in OCaml and OpenGL: lessons learned

#32
post #7
post #6

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.

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.

I not only could, I say so.

Focus on platform languages and you always win long term.

Re: Programming a space invader in OCaml and OpenGL: lessons learned

#33
post #6

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.

Because people who know other programming languages, but not ML, might want to read your code, and it's nice if it looks familiar to them.

That is how languages like Go get designed, pour souls not able to spend some time learning.

Re: Programming a space invader in OCaml and OpenGL: lessons learned

#34
post #6

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.

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.

Re: Programming a space invader in OCaml and OpenGL: lessons learned

#35

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…

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?

Reprocessing is a rewrite of Processing in Reason.

Runs with WebGL and OpenGL.

https://github.com/Schmavery/reprocessing

Re: Programming a space invader in OCaml and OpenGL: lessons learned

#36
This article title and conclusions are misleading. It shows how to write a simple game in OCaml and then proceeds to conclude that ReasonML is better. I would expect the author to have the same game implemented in ReasonML for comparison to show us why. Otherwise, it is not very convincing.

Re: Programming a space invader in OCaml and OpenGL: lessons learned

#37
post #30
post #8

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.

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.

Re: Programming a space invader in OCaml and OpenGL: lessons learned

#39
post #20

Between reasonml and elm which one should I pick?

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.

Re: Programming a space invader in OCaml and OpenGL: lessons learned

#40
post #30

Earlier quoted context omitted.

And now it is dead, leaving behind a pile of code to rewrite in next cool toy.

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.
Post reply on HN