Live data from Hacker News

Programming a space invader in OCaml and OpenGL: lessons learned

marmelab.com

111–120 of 120 posts

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

#111
post #108
post #50

Earlier quoted context omitted.

Does Purescript also come into the equation? :-)

Purescript isn't essentially for web (frontend)? In that case, it's like Elm

As far as I remember, Elm has a runtime that at the moment requires the browser api. Purescript just compiles to javascript. So you don’t have server-side Elm, but you do have server-side Purescript. Which probably makes it more like Reason than like Elm.

The main difference is, Elm is like a drastically simplified version of Haskell, while Purescript is essentially Haskell with benefits (row polymorphism).

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

#112
post #104
post #63

Earlier quoted context omitted.

Whereby you seem to be making the case for "dead" languages.

Except Fortran and Cobol are pretty much alive, with ISO still releasing languages updates, recently LLVM got a Fortran compiler, supported by the likes of ARM and NVidia. They are just "dead" in that they are specialized programming languages with a domain of their own, that magpie developers don't find attractive to put on their CV. CoffeeScript in 2020 is just legacy code that one wants to get rid of, because some…

Based on what data is that true exactly?

Opinions are fine, I don’t like CoffeeScript and never have.

It’s no justification to shame someone’s choices when perfectly well working code is usable via what appears to me to be a healthily maintained tool. Less popular? Sure. Would I reach for it to start a new project? no.

Calling it dead though and saying it’s only around because it’s “legacy” and only was used by “cool IT juniors” is shaming a legitimate choice without giving any context or data to back up the assertions

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

#113
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.

Jordan Walke, the creator of Reason (also the creator of React) said that syntax is unfortunately very important, because psychologically people want something familiar. I think syntax is totally superficial, but I’m also a human who interacts with other humans. And they do not think it’s superficial.

The talk where he says this: https://youtu.be/5fG_lyNuEAw

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

#114

Earlier quoted context omitted.

VS installation is also a PITA if you have your C:\ on an SSD. The installer doesn't give you choice of what partition to install to (for most of its huge disk space demands) so you need to fake it with a bunch of symlinks. The VS team recognizes this problem but doesn't do anything about it, as follows from the comments on https://developercommunity.visualstudio.com/content/problem/...

Or just buy a bigger SSD. Makes all kinds of things much nicer.

Difficult when I’m using Bootcamp on a MacBook Pro unfortunately

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

#115
post #70

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

Agreed, the choice to use obuild was also bizarre. Dune has been standard for the last ~2 years and before that Oasis was the most popular build tool I believe.

As someone who loves OCaml, the “churn” in build systems confused me too. I’m hoping dune remains the standard for the next 10 years!

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

#116
post #114

Earlier quoted context omitted.

Or just buy a bigger SSD. Makes all kinds of things much nicer.

Difficult when I’m using Bootcamp on a MacBook Pro unfortunately

Well there's your first mistake ;)

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

#117
post #81

Earlier quoted context omitted.

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.

> It is complicated to figure out a straightforward way to do builds in OCaml Sorry, what is not straightforward in building with `dune`?

Some things I ran into:

- How do I run tests? Oh, you can't really dune runtest on executables, only libraries. So how do I run tests on executables? Make a library with the core of the functionality and wrap it, I guess. Wasn't obvious.

- Tree-like heirarchy of dune files confused me since it wasn't really explained anywhere. I wanted my source files in a `src` directory; most of the examples assume your `dune` file is just hanging out with the source in the toplevel.

- Does `dune` handle dependencies (like I would declare them in a rebar.config, mix.exs, or a package.json)? Not really, it plays with opam, requiring one to read a bunch of docs for opam, and its files, and where they should go.

- The syntax of the dune files changed a bit from when I started the project (it was just moving from jbuilder -> dune). Less of an issue now, though I still question the use of s-expressions.

- Can I load an interactive shell with the definitions? There's a command in the documentation for it, but it didn't work quite right when I tried.

- If you look at other projects, you'll see they use opam files differently from one another.

- How do I add a dependency in my current switch (something like npm --save install ?) I tried `opam install --deps-only`, but it complained sometimes about the state of uncommitted files.

I understand why it's like this (trying to tie together a ton of use cases) and love developing in it after it's all said and done, but there are a lot of rakes to step on.

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

#118
post #81

Earlier quoted context omitted.

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.

> It is complicated to figure out a straightforward way to do builds in OCaml Sorry, what is not straightforward in building with `dune`?

When I was putting together the build about 2? years ago, dune was not the normative standard.

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

#119
post #86

Earlier quoted context omitted.

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

Opam has gotten quite good. When you set it up, you're being guided through all the steps. Works best on Mac, with Linux a close 2nd. Windoze may pose some extra challenges for setting up a working environment.

Good know, thank you.

Probably never going to use OCaml again (just for business reasons, nothing against it per se), but good info for other readers.

EDIT: I also hope some of the OCaml'ers did get some of use of the things I wrote. I'm not going to doxx myself by naming the exact things, but just wanted to say... I hope you took advantage of them because the stdlib was quite anemic, so you might want to extend it. They were just missing bits of the ecosystem that I wanted to be more convenient... and I implemented a data structure paper or two.

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

#120

Earlier quoted context omitted.

> It is complicated to figure out a straightforward way to do builds in OCaml Sorry, what is not straightforward in building with `dune`?

Some things I ran into: - How do I run tests? Oh, you can't really dune runtest on executables, only libraries. So how do I run tests on executables? Make a library with the core of the functionality and wrap it, I guess. Wasn't obvious. - Tree-like heirarchy of dune files confused me since it wasn't really explained anywhere. I wanted my source files in a `src` directory; most of the examples assume your `dune` file…

> Tree-like heirarchy of dune files confused me since it wasn't really explained anywhere.

It's explained in project layout [1]. And it's not a tree like, it's basically flat, since it doesn't matter how deep in the file system your dune file is buried.

It's like `meson` in its concept.

> Does `dune` handle dependencies

It doesn't, and so neither do `meson`, `cmake` and most other build systems. As you may want to use various ways of installing dependencies: native packages, manual compilation, opam, esy.

> Can I load an interactive shell with the definitions?

Yes, you can run `dune utop ./path`

> If you look at other projects, you'll see they use opam files differently from one another.

Dune is independent of opam, opam file is needed to publish your package to opam. You can specify packages with dune without creating an opam file, see [2]

> I tried `opam install --deps-only`, but it complained sometimes about the state of uncommitted files.

If you use opam, you can do `opam install --deps-only`, or `dune build @install`, which would suggest a command to install missing packages.

[1] https://dune.readthedocs.io/en/stable/overview.html#project-...

[2] https://dune.readthedocs.io/en/stable/concepts.html#package-...

Post reply on HN