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

81–90 of 120 posts

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

#81

Post by pnathan »

kingkonz1 wrote: post #11

> 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…

It is complicated to figure out a straightforward way to do builds in OCaml. If you're not tapped into the Current Way, you kind of have to read this blog, read that fragment, piece it together. I worked it through for a project of mine, and it was unusually unpleasant vs, say, Haskell.

Docker because, presumably, he didn't want to dink with installing it locally.

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

#82

Post by erichocean »

throwaway894345 wrote: post #53
erichocean wrote: post #45

Earlier quoted context omitted.

TypeScript says hi.

TypeScript extends the syntax to support type annotations; it's not trying to fundamentally fix JS syntax.

Now enforcing type safety isn't a fundamental part of a language? I get the impression that you'd dismiss Rust as "basically C".

    ¯\_(ツ)_/¯

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

#83

Post by iudqnolq »

yodsanklai wrote: post #44
srpablo wrote: post #19

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

What's the answer to the confusion around the Jane Street stuff? Do you recommend it for newbies?

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

#84

Post by baddox »

sweeneyrod wrote: post #23
elcapitan wrote: post #12

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?

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

Aren't the Ocaml and ReasonML syntaxes so similar that you can effectively convert both directions and still end up with clean idiomatic code? That has seemed to be the case when I've played around with the ReasonML, and if it's the case, then which one you choose to write is very much arbitrary. Heck, you could even write one syntax locally and then automatically convert to the repo's preferred syntax when you commit your code.

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

#85

Post by baddox »

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.

Neither one is more real than the other and you really shouldn't need to do any debugging unless there are bugs in the ReasonML parser (and you could just as easily run into a bug with the Ocaml parser, but I suspect both are very unlikely).

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

#86

Post by Quekid5 »

kingkonz1 wrote: post #11

> 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…

It's been a few years since I tried opam... When I did it just barfed out some obscure error message and I wasn't encouraged to try ever again. I realize that that's not really helpful towards improving the UX, but maybe it helps as a single data point?

(Just to avoid accusations of : I actually discovered FP through OCaml and wrote a few early-ish libraries in the ecosystem, but then discovered Haskell... and the rest is history.)

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

#87

Post by madhadron »

adamnemecek wrote: post #17

Between reasonml and elm which one should I pick?

If the goal is to learn something in the ML family, I'd start with Standard ML. Ullman wrote a great book on it.

If the goal is some kind of syntax on top of JavaScript, I have no opinion.

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

#88

Post by yawaramin »

azangru wrote: post #48
adamnemecek wrote: post #39

Earlier quoted context omitted.

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.

I believe Reason is more practical (easier FFI), but as for building things, at this point it's probably Typescript :-) 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 )

> Reason still hasn't had its async story ironed out,

Reason's async story is pretty simple: use promises until the let-syntax (like generalized do-notation) lands, then use that.

> "ReasonML strings are encoded as UTF-8 and not compatible with JavaScript’s UTF-16 strings"

Unfortunately this is inaccurate, and you left out a significant detail from the article. Let's go point by point here:

- Reason strings are not encoded as UTF-8, in fact they aren't encoded at all.

- But, when targeting JavaScript using the BuckleScript compiler, strings can contain Unicode characters and use the JavaScript runtime's support for Unicode.

- This is not a short-term workaround, but the intended solution.

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

#89

Post by moron4hire »

yodsanklai wrote: post #44
srpablo wrote: post #19

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

.NET you install either Visual Studio or just the SDK and everything just works. And it's not just the initial setup. It's the best debugging experience available. It has a robust extension system, though honestly, you don't need to engage it and you're still having an amazing experience.

For a while, I grumbled that it had spoiled me for other languages, the "fun" looking stuff that everyone talks about online. But as with all... rustic... experiences, it's only fun for the weekend. I wouldn't want to spend my entire life chopping wood for fuel, either. Even after spending 3 years fully in JavaScript land, getting very comfortable with all of the tools, it never really got "good enough". Years of effort and my dev experience was still worse than a default VS install. So I went back and have been loving life again.

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

#90

Post by yawaramin »

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?

There are two significant projects for native Reason:

- https://esy.sh/ - a package manager that offers a lockfile, aggressive build caching, and reproducible hermetic builds. So when you come back to a project a few months later, it still builds.

- https://reason-native.com/ - an umbrella for useful Reason-oriented native libraries

Post reply on HN