4 ms·

You roll your own build system instead of using the built-in tools and you don't understand why people wouldn't want to do that? This isn't a typical situation

by jolux 5y ago

You roll your own build system instead of using the built-in tools and you don't understand why people wouldn't want to do that? This isn't a typical situation in Rust or even Haskell these days. Come on. Rarely are people arguing that a situation like this makes writing software impossible. The question is whether it adds friction, and in adding friction impedes adoption. I think it clearly does, and that tooling is one of the highest-impact features a language can prioritize to improve adoption. If the story for building and packaging OCaml software is "go make yourself proficient in the C build tooling ecosystem first," of course that makes it harder to adopt (and you're not the first person in the community to give this answer, either). This hostility to beginners is one of the major things that irks me about the OCaml community, and OCaml is probably my favorite language.

rwmj 5y ago
We have 6 lines of code that we copy and paste around projects: https://github.com/libguestfs/libguestfs/blob/d01ce082180c41801640bc233c5d6f3ad4195458/subdir-rules.mk#L85-L91 https://github.com/libguestfs/libguestfs/blob/d01ce082180c41... Now if you're saying that the autotools/make/cmake/meson tooling is hard, I sort of agree, but many people are familiar with C build tools already. I don't see how it's easier or harder than learning language-specific tools.
- jolux 5y ago
  >Now if you're saying that the autotools/make/cmake/meson tooling is hard, I sort of agree That's not really the main problem to me but it is a problem. >many people are familiar with C build tools already Maybe if they're C++ programmers. I don't know anyone outside of the C++ community who has ever used anything aside from Makefiles and language-specific tooling. >I don't see how it's easier or harder than learning language-specific tools. The language-specific tools are typically very well integrated with the default testing, packaging, and editor tools ecosystem. The C build tools are not going to be, at least not for OCaml. Language-specific tools show users the best experience a language can offer. More advanced users can always choose to use something else, but the advantages of the whole community using the same tool are hard to beat as well.
  - rwmj 5y ago
    I guess we know different developers. I work with Linux / C programmers, and everyone is familiar with the basic C build tools. C tools also deal with testing, and there's a very clear and well-travelled path from ./configure && make && make check && make DESTDIR=.. install to RPMs and Debian packaging.
    - jolux 5y ago
      That's the process for building and installing packages though. I'm talking about writing new ones, on a system with nothing else installed. I'm omnivorous but I get paid for web development and that's what most people I know are most interested in. And like I said, they understand Makefiles and make, but autotools and Meson are not "basic C build tools," they're both extremely complex and relatively niche. I'm not saying you shouldn't use the tools you use, but you should understand that they are not popular or well-understood outside of your niche of Linux programming with C. I'm sure these programmers could learn how to use them, but most are going to choose not to if it's the easiest way to use the language. They will pick something else.
    - brokencode 5y ago
      If you browse job listings, you might be surprised to find that the vast majority of jobs these days are not related to C or Linux development. Companies are mostly building web and mobile applications, along with the corresponding web servers on the backend. JavaScript, Swift, Go, Java, Python - these are the kinds of languages developers are working with, and none of those languages normally are used with C build tools.
- baby 5y ago
  The tools you’re citing are pretty much the worst dev experience around these days. Check cargo or go
rixed 5y ago
Is it "being hostile to beginners" to encourage them to learn simple universal tools to build any software in any environment? When i was a beginner, trying a new language was actually easier: you just installed a compiler. Now you need a "platform", for some even a special dedicated machine. I wonder who is benefiting this sillo-ing, but I doubt that's the beginners.
- jolux 5y ago
  I'm not talking about beginning programmers, I'm talking about people who are new to your language community. You can still just install and use ocamlc/ocamlopt, or rustc, or ghc, but the bar has been raised. People picking up a new language today for production use expect it to have a cohesive story for builds, packaging, tooling, and testing out of the box. >I wonder who is benefiting this sillo-ing, but I doubt that's the beginners. Everyone benefits from the better tooling we have now. The siloing is a problem that still has not seen a satisfactory solution. Regression in user experience is not acceptable.
  - rwmj 5y ago
    These language-specific toolchains are often not better. They're complex, opaque, stuff things in places in my home directory, don't work together, and don't work with system packages -- golang is actively hostile to being properly packaged, making it difficult to keep track of what's installed and security updates.
    - baby 5y ago
      Golang and cargo have the best dev stories out there. Period.
  - rixed 5y ago
    It baffles me how much younger devs seam to be unable or unwilling to consider anything else than "communities". I guess the latest 20 years of research in web marketing did that to us. Being part of a "language community" is not the only way to be a programmer. Not knowing your way outside of the opinionated built tool black box is indeed quite frankly the hallmark of being a beginner, if not a tech illiterate, in my book. When I originally asked what was the point of Dune, the answer I received from the people pushing that project at that time was that I shouldn't worry, it was just a tool to speed up getting a workable workflow when teaching 1st grade students. It made sense then, I though at some point beginners would naturally outgrow that walking aid. But look at what happened instead! Mind you, today's experience with ocamlc/ocamlopt for the seasoned programmer is not unchanged either. Because of that new "community first" principle, all the tools tend to work only withing the ecosystem at the expense of cooperating with the larger distribution. Again, younger devs or devs used to "lesser operating systems" never experienced life under a proper system-wide software distribution so they have no idea what they are missing. Of course opam looks great once Debian is broken (and until, let's hope, guix or nix takes over). An exemple of such a regression: querying the type of an ocaml expression from any editor used to be trivial from the easily parsable annotation file producer by the compiler. It's now been replaced by a memory dump that's easier for merlin. And merlin will not even be able to answer that simple query unless you provide it with a full blown configuration. Good luck setting that up without the assistance of the dune built tool. Good luck setting that up if your project involves anything else than plain and simple ocaml. Ach, I probably start to sound unfair. Indeed this tendency toward infantilism is in no way specific to ocaml, probably ocaml has been resisting it for longer even. And it's not specific to programming languages either, nor even to technology. Pardon my rant, grumpy old man can still feel passionate about computers at times; rest assured he is being transferred to another trade :)

by jolux 5y ago

rwmj 5y ago

We have 6 lines of code that we copy and paste around projects: https://github.com/libguestfs/libguestfs/blob/d01ce082180c41801640bc233c5d6f3ad4195458/subdir-rules.mk#L85-L91 https://github.com/libguestfs/libguestfs/blob/d01ce082180c41... Now if you're saying that the autotools/make/cmake/meson tooling is hard, I sort of agree, but many people are familiar with C build tools already. I don't see how it's easier or harder than learning language-specific tools.

jolux 5y ago
>Now if you're saying that the autotools/make/cmake/meson tooling is hard, I sort of agree That's not really the main problem to me but it is a problem. >many people are familiar with C build tools already Maybe if they're C++ programmers. I don't know anyone outside of the C++ community who has ever used anything aside from Makefiles and language-specific tooling. >I don't see how it's easier or harder than learning language-specific tools. The language-specific tools are typically very well integrated with the default testing, packaging, and editor tools ecosystem. The C build tools are not going to be, at least not for OCaml. Language-specific tools show users the best experience a language can offer. More advanced users can always choose to use something else, but the advantages of the whole community using the same tool are hard to beat as well.
- rwmj 5y ago
  I guess we know different developers. I work with Linux / C programmers, and everyone is familiar with the basic C build tools. C tools also deal with testing, and there's a very clear and well-travelled path from ./configure && make && make check && make DESTDIR=.. install to RPMs and Debian packaging.
  - jolux 5y ago
    That's the process for building and installing packages though. I'm talking about writing new ones, on a system with nothing else installed. I'm omnivorous but I get paid for web development and that's what most people I know are most interested in. And like I said, they understand Makefiles and make, but autotools and Meson are not "basic C build tools," they're both extremely complex and relatively niche. I'm not saying you shouldn't use the tools you use, but you should understand that they are not popular or well-understood outside of your niche of Linux programming with C. I'm sure these programmers could learn how to use them, but most are going to choose not to if it's the easiest way to use the language. They will pick something else.
  - brokencode 5y ago
    If you browse job listings, you might be surprised to find that the vast majority of jobs these days are not related to C or Linux development. Companies are mostly building web and mobile applications, along with the corresponding web servers on the backend. JavaScript, Swift, Go, Java, Python - these are the kinds of languages developers are working with, and none of those languages normally are used with C build tools.
baby 5y ago
The tools you’re citing are pretty much the worst dev experience around these days. Check cargo or go

rixed 5y ago

Is it "being hostile to beginners" to encourage them to learn simple universal tools to build any software in any environment? When i was a beginner, trying a new language was actually easier: you just installed a compiler. Now you need a "platform", for some even a special dedicated machine. I wonder who is benefiting this sillo-ing, but I doubt that's the beginners.

jolux 5y ago
I'm not talking about beginning programmers, I'm talking about people who are new to your language community. You can still just install and use ocamlc/ocamlopt, or rustc, or ghc, but the bar has been raised. People picking up a new language today for production use expect it to have a cohesive story for builds, packaging, tooling, and testing out of the box. >I wonder who is benefiting this sillo-ing, but I doubt that's the beginners. Everyone benefits from the better tooling we have now. The siloing is a problem that still has not seen a satisfactory solution. Regression in user experience is not acceptable.
- rwmj 5y ago
  These language-specific toolchains are often not better. They're complex, opaque, stuff things in places in my home directory, don't work together, and don't work with system packages -- golang is actively hostile to being properly packaged, making it difficult to keep track of what's installed and security updates.
  - baby 5y ago
    Golang and cargo have the best dev stories out there. Period.
- rixed 5y ago
  It baffles me how much younger devs seam to be unable or unwilling to consider anything else than "communities". I guess the latest 20 years of research in web marketing did that to us. Being part of a "language community" is not the only way to be a programmer. Not knowing your way outside of the opinionated built tool black box is indeed quite frankly the hallmark of being a beginner, if not a tech illiterate, in my book. When I originally asked what was the point of Dune, the answer I received from the people pushing that project at that time was that I shouldn't worry, it was just a tool to speed up getting a workable workflow when teaching 1st grade students. It made sense then, I though at some point beginners would naturally outgrow that walking aid. But look at what happened instead! Mind you, today's experience with ocamlc/ocamlopt for the seasoned programmer is not unchanged either. Because of that new "community first" principle, all the tools tend to work only withing the ecosystem at the expense of cooperating with the larger distribution. Again, younger devs or devs used to "lesser operating systems" never experienced life under a proper system-wide software distribution so they have no idea what they are missing. Of course opam looks great once Debian is broken (and until, let's hope, guix or nix takes over). An exemple of such a regression: querying the type of an ocaml expression from any editor used to be trivial from the easily parsable annotation file producer by the compiler. It's now been replaced by a memory dump that's easier for merlin. And merlin will not even be able to answer that simple query unless you provide it with a full blown configuration. Good luck setting that up without the assistance of the dune built tool. Good luck setting that up if your project involves anything else than plain and simple ocaml. Ach, I probably start to sound unfair. Indeed this tendency toward infantilism is in no way specific to ocaml, probably ocaml has been resisting it for longer even. And it's not specific to programming languages either, nor even to technology. Pardon my rant, grumpy old man can still feel passionate about computers at times; rest assured he is being transferred to another trade :)