Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programming a space invader in OCaml and OpenGL: lessons learned

marmelab.com

Post reply on HN
Print view View original

21–30 of 120 posts

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

#21

Post by sshine »

Gene_Parmesan wrote: post #14
toolz wrote: post #10

Earlier quoted context omitted.

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.

> code is for and by humans 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/…

> 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':

https://stackoverflow.com/questions/37694313/make-ocaml-func...

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.

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

#22

Post by alharith »

juliendemangeon wrote: post #15
alharith wrote: post #9

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”

You're absolutely right. I wanted to justify my exploration by way of comparison between ReasonML and Ocaml. The title ("Programming A Space Invader In OCaml and OpenGL: Lessons Learned") still fits with the content, don't you think?

I see that now, yes I do. I think maybe the headings and subheadings are also throwing me off as well. I wasn't sure if I was reading one of those types of blogs that have a continuous feed of articles on one page.

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

#23

Post by sweeneyrod »

elcapitan wrote: post #12
sweeneyrod wrote: post #4

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?

People don't do it much, but if you're using the most popular build system (dune) you can replace your .ml files with .re ones and it will Just Work. So you can use OCaml projects for reference (I think anyone who's doing Reason should have a vague grasp of OCaml syntax, it's not really that different).

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

#24

Post by pcvonz »

elcapitan wrote: post #12
sweeneyrod wrote: post #4

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?

Check out Oni Vim 2: https://github.com/onivim/oni2/blob/master/README.md

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

#25

Post by hajile »

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 implementations.

Ocaml requires different operators for float and integer arithmetic. SML assumes an integer type unless you include a decimal. Both need to be replaced with module typeclasses (and both are working in that direction). For SML though, your existing code can continue to just work as it did before while Ocaml will be left with lots of `+.` or `*.` operators everywhere.

Another mistake that bleeds through is mutable strings. This is an outgrowth of all arrays being mutable. Immutable strings allow efficient representation as ropes instead of normal arrays (along with other optimizations that are good for GC'd languages). SML has immutable strings and vectors along with arrays (which you can still use as mutable strings of characters if you need them).

For their React-like goal though, Ocaml's lack of anonymous record types is the absolute worst. In SML, I can just type up a record and pass it in (no type definitions required). When passing in stuff to a component, you have to have all these named arguments. In SML, I'd just pass an anonymous record and destructure it in the function -- Just like in Javascript, but with types behind the scenes to keep everything straight.

Writing a custom parser for Babel like typescript or coffeescript have done would have been better for the language design and independence.

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

#26

Post by hajile »

pjmlp wrote: post #6
hellofunk wrote: post #3

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.

The "real deal" here is Ocaml. It's not the most complex syntax in existence, but I'd say it's easily the most complex ML language in existence.

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

#28

Post by lindig »

hajile wrote: 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…

> Another mistake that bleeds through is mutable strings.

OCaml strings are immutable by default since OCaml 4.06.

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

#29

Post by Kmaschta »

cpursley wrote: post #27

Marmelab makes the pretty awesome react-admin library for autogenerating admin interfaces: https://github.com/marmelab/react-admin I'd love to see an official Marmelab adapter so I can build my admin interfaces with ReasonML.

We already have hard time migrating it to TypeScript :p How such an adapter might work?

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

#30

Post by pjmlp »

jherdman wrote: post #8
pjmlp wrote: 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 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.
Post reply on HN