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

Frustrations with the OCaml ecosystem while developing a synthesizer library

gridbugs.org

Post reply on HN
Print view View original

11–20 of 28 posts

Re: Frustrations with the OCaml ecosystem while developing a synthesizer library

#11

Post by rwmj »

cdaringe wrote: post #10
rwmj wrote: post #7

I think the author's problem was using dune at all. It's a very weird and obscure tool, and not necessary, you can just run ocamlopt commands from existing build systems (like autotools, meson etc). I've used OCaml in production for 2 decades without ever needing to use dune, opam etc.

I cordially disagree. I do not find dune weird or obscure. It’s formally part of the OCaml platform: https://ocaml.org/platform , which I think negates at least the obscure bit. It was “new” to me for a hot moment, and it’s certainly a less common format for config files (s (expressions)). However, what I see is a tool that solves concrete problems that uses a declarative, structured format (not very weird). It also…

I have to deal with dune across all the Fedora OCaml packaging (something like 200 different upstreams) and it's quite difficult to deal with. Not the worst build system out there, but makes me a bit sad every time I have to modify something in a project.

Re: Frustrations with the OCaml ecosystem while developing a synthesizer library

#12

Post by aseipp »

Honestly using Rust recently has taught me that, the only reason C and C++ dependencies in Rust are remotely tolerable (unlike most other languages) is because Rust has an unusually high degree of talented developers, many former C/C++, who are able and willing to mercilessly bludgeon these libraries and their build systems into a square shape, then fit them in the circle-shaped hole we call "build.rs".

I guess my point is, yeah all of this sort of stuff sucks, and to the extent it sucks less elsewhere, it's mostly due to the sheer effort consumed by it.

Re: Frustrations with the OCaml ecosystem while developing a synthesizer library

#13

Post by jasperry »

rwmj wrote: post #7

I think the author's problem was using dune at all. It's a very weird and obscure tool, and not necessary, you can just run ocamlopt commands from existing build systems (like autotools, meson etc). I've used OCaml in production for 2 decades without ever needing to use dune, opam etc.

The black-boxiness of dune has frustrated me as well, but to its credit it does a lot of work for you. Its biggest problem might be documentation; at least the last time I looked at it, there were only very basic examples plus a listing of the keywords with terse descriptions.

The art of writing a reference manual that actually explains how the software works is almost lost, it seems.

Re: Frustrations with the OCaml ecosystem while developing a synthesizer library

#14

Post by qlfa102 »

jasperry wrote: post #13
rwmj wrote: post #7

I think the author's problem was using dune at all. It's a very weird and obscure tool, and not necessary, you can just run ocamlopt commands from existing build systems (like autotools, meson etc). I've used OCaml in production for 2 decades without ever needing to use dune, opam etc.

The black-boxiness of dune has frustrated me as well, but to its credit it does a lot of work for you. Its biggest problem might be documentation; at least the last time I looked at it, there were only very basic examples plus a listing of the keywords with terse descriptions. The art of writing a reference manual that actually explains how the software works is almost lost, it seems.

> The art of writing a reference manual that actually explains how the software works is almost lost, it seems.

The original INRIA docs are also better than the new things on ocaml.org. Literally the only issue with the "old" INRIA pages was the poor quality of the mailing list archive, the rest is great!

I want my tar archives and docs from INRIA. If I was rich, I'd pay for a grant to update the "old" documentation.

Re: Frustrations with the OCaml ecosystem while developing a synthesizer library

#15

Post by aseipp »

trpal wrote: post #9

OCaml itself is built with Makefiles, which just works. Coq has used various new tools over the years and at times has been more difficult to build than 15 years ago. With OCaml-5 the situation seems to have gotten better: At least the infamous caml4p problem was solved, and I "only" had to fix a wrong ocamlfind config file that was installed by default. ocamlbuild is generally good, but Dune and Opam are a black box…

Coq doesn't seem meaningfully harder to build than in the past but maybe I'm just not in touch. It was always the Gtk bits that added issues for me, not Dune or anything.

> which despite all the hate for them are always the most reliable build way.

Based on the amount of totally broken Makefiles I find on a regular basis as a package maintainer (logic bugs, recursive make, invalid deps = no parallel builds) suggests to me this is not the case at all. Doesn't even touch on how awful these things are often written, even if they work reliably enough. Insane idioms in the name of one-liners, implicit dependencies on GNU specific features, incredibly inefficient shell pipeline commands, overly large rules that mean many intermediate steps aren't cached, subtly broken rules and invocations based on spaces or non-utf8 chars, etc.

I worked on the Glasgow Haskell Compiler and the truth is that the Make-based build process was only reliable because a massive amount of effort was spent on it. I suspect it's probably the same with OCaml, and not because Makefiles are special. There are degrees to it all, but they certainly don't have good syntax (too terse), aren't easy to read (batshit insane escape rules that were fixed by Plan 9 mk in 1991), and make expressing many types of dependencies really awkward by design (I want a dependency on an environment variable?) They're just really easy to get started with and you can write something broken that looks like it works zero effort, honestly.

Re: Frustrations with the OCaml ecosystem while developing a synthesizer library

#16

Post by c-cube »

trpal wrote: post #9

OCaml itself is built with Makefiles, which just works. Coq has used various new tools over the years and at times has been more difficult to build than 15 years ago. With OCaml-5 the situation seems to have gotten better: At least the infamous caml4p problem was solved, and I "only" had to fix a wrong ocamlfind config file that was installed by default. ocamlbuild is generally good, but Dune and Opam are a black box…

OCaml might be built with makefiles, but it's also not an easy path at all. Adding a module to the compiler or stdlib is really not straightforward compared to what it'd be with dune (you have to list your new file somewhere, regenerate dependencies, order matters in obscure ways, etc.). To be clear, OCaml is a special project since it also has to solve bootstrapping issues, but still, it's not an argument for "makefiles just work". Dune works extremely well for pure OCaml projects.

Re: Frustrations with the OCaml ecosystem while developing a synthesizer library

#17

Post by RandomThoughts3 »

cdaringe wrote: post #10
rwmj wrote: post #7

I think the author's problem was using dune at all. It's a very weird and obscure tool, and not necessary, you can just run ocamlopt commands from existing build systems (like autotools, meson etc). I've used OCaml in production for 2 decades without ever needing to use dune, opam etc.

I cordially disagree. I do not find dune weird or obscure. It’s formally part of the OCaml platform: https://ocaml.org/platform , which I think negates at least the obscure bit. It was “new” to me for a hot moment, and it’s certainly a less common format for config files (s (expressions)). However, what I see is a tool that solves concrete problems that uses a declarative, structured format (not very weird). It also…

Dune is part of the platform mostly because it was there and was the tool used and developed by Ocaml biggest corporate user but it’s hard to disagree with it’s weird (s-expressions in a non LISP, really?) and a bit obscure. Esy seems to solve most of these issues at the costs of a tie-in to npm.

Re: Frustrations with the OCaml ecosystem while developing a synthesizer library

#19

Post by yawaramin »

rwmj wrote: post #7

I think the author's problem was using dune at all. It's a very weird and obscure tool, and not necessary, you can just run ocamlopt commands from existing build systems (like autotools, meson etc). I've used OCaml in production for 2 decades without ever needing to use dune, opam etc.

Yeah but you've been using OCaml packages by wrapping them up as rpms (I assume). This is not very scalable ;-)

Re: Frustrations with the OCaml ecosystem while developing a synthesizer library

#20

Post by bmitc »

trpal wrote: post #9

OCaml itself is built with Makefiles, which just works. Coq has used various new tools over the years and at times has been more difficult to build than 15 years ago. With OCaml-5 the situation seems to have gotten better: At least the infamous caml4p problem was solved, and I "only" had to fix a wrong ocamlfind config file that was installed by default. ocamlbuild is generally good, but Dune and Opam are a black box…

> Makefiles, which just works

It should be a crime to mention "Make" and "just works" in a single sentence.

Post reply on HN