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

101–110 of 120 posts

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

#101

Post by ernst_klim »

pnathan wrote: post #81
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.

> It is complicated to figure out a straightforward way to do builds in OCaml

Sorry, what is not straightforward in building with `dune`?

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

#102

Post by ernst_klim »

> I choose a more undisclosed tool (obuild) because of its simplicity and its brief documentation

> And although some tools exist to make our life easier, they are poorly documented

Seems like author choose something poorly documented. Dune build system [1], opam [2] and esy [3] package managers are very well documented.

[1] https://dune.readthedocs.io/en/stable/

[2] https://opam.ocaml.org/doc/

[3] https://esy.sh/docs/en/what-why.html

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

#103

Post by throwaway894345 »

erichocean wrote: post #82
throwaway894345 wrote: post #53

Earlier quoted context omitted.

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". ¯\_(ツ)_/¯

I have no idea how you got that from my post. I don’t know whether type safety is “a fundamental part of a language” or not, but that’s irrelevant to my point. TS extends the JS syntax to support type safety. Reason changes OCaml’s syntax altogether because it’s broken. Big difference.

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

#104

Post by pjmlp »

blunte wrote: post #63
pjmlp wrote: post #58

Earlier quoted context omitted.

I bet Fortran and Cobol are getting more jobs offers than CoffeeScript.

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 juniors found it cool to smuggle into the IT infrastructure.

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

#105

Post by weavie »

adamnemecek wrote: post #39
weavie wrote: post #20

Earlier quoted context omitted.

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.

Elm is made for one thing - web apps. It does it well, but it's probably not the only language you would ever use.

ReasonML/Ocaml is a general language. You can use whatever framework and platform you like. There is an Elm framework for Elm like development, there is a React layer for coding against react. But you can also write server apps, command line apps, GTK etc..

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

#106

Post by moron4hire »

LessDmesg wrote: post #100
moron4hire wrote: post #89

Earlier quoted context omitted.

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

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.

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

#107

Post by fhcoso »

Interesting but why talking at the end about F#, Scala and not Haskell (general-purpose, statically typed, purely functional programming language with type inference and lazy evaluation) wish is more old and mature than OCaml and F#: - Haskell: 1990 - F#: 2005 - Scala: 2004

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

#109

Post by terminaljunkid »

pcwalton wrote: post #57
pjmlp wrote: post #33

Earlier quoted context omitted.

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

I wish Go had been a reskin of OCaml.

That is nowhere near their goals.

Maybe if Go didn't start as a hobby project inside Google, then they /might/ even have seen some opportunity in Ocaml / Standard ML, but now that Go exists, and has a quite good toolchain, the incentive is low. Go and its foundations are radically different from a FP language like OCaml though.

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

#110

Post by pjmlp »

msla wrote: post #46
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.

Programming is expressing programmer intent to the greatest extent possible given technological constraints. Sometimes, that's moving from machine code to assembly language[1]; sometimes, that's building a declarative language to express some specific logic. Finding new ways to preserve programmer intent in machine-checkable ways (that is, not just by adding comments) is one of the consistent goals of programming lan…

Programming is delivering a solution that solves someone needs, typing +. or + makes zero difference solving their needs.
Post reply on HN