5 ms·

"If you are not able to run a ./configure / make / make install & 3 apt-get properly." Nearly choked on my water reading this. Incredible how many developers a

"If you are not able to run a ./configure / make / make install & 3 apt-get properly." Nearly choked on my water reading this. Incredible how many developers are stockholme syndrome'd by their godawful tooling experience.

adev_ 6y ago
> Nearly choked on my water reading this. Incredible how many developers are stockholme syndrome'd by their godawful tooling experience. I tend to name a "magic bulshit bloat tool" that will makes me download 350MB of crap to compile an 'hello world' a "godawful tooling experience". We are all free to have our own definition.
- staticassertion 6y ago
  You can tell me that other build tools have problems, but the "You must know how to run some os/project-specific commands to write a program or you're a bad developer" is the funniest kind of gatekeeping to me. But keep calling people "script kiddies" that's cool.
  - adev_ 6y ago
    > commands to write a program or you're a bad developer" is the funniest kind of gatekeeping to me. I am curious of your notion of "gatekeeping", because you are the one being funny here. People have been able to understand Make, use it and compile C for 20 damn years: Are people being more stupid today ? ( Spoiler: No) If "today", with the unprecedent level of documentation you have on the Web, it is a problem for you to do so, then yes: you are indeed a bad developper. I am a strong believer of "the show me the code" approach. It is easy to call all the actual tooling a "dumpfire", then show me a better one, or at least document in details what "a better" one would be. Critics are easy and in this precise context, without arguments, they are just FUD or religious beliefs.
    - staticassertion 6y ago
      > I am curious of your notion of "gatekeeping" Repeatedly telling people that they're bad developers, should walk away from a computer, that they are "script kiddies", because they do not know or enjoy some arcane technical artifact. I call this gatekeeping.
      - adev_ 6y ago
        > enjoy some arcane technical artifacts Except that I do not think that you can call executing "make" and using your native package manager an "arcane", I am sorry. These are basic actions that are documented even from tutorials from the 90's. They are basic actions that are generally part of any first year study in computer sciences. That is not 'gatekeeping', there is no gate to keep here. I name more that fight laziness and understand your tooling.
        DagAgren 6y ago
        Speaking as a C developer of twenty or thirty years or so who's used make for all that time: Make is absolute, utter arcane bullshit. It is mad. It is complete nonsense.
        adev_ 6y ago
        > Make is absolute, utter arcane bullshit. It is mad. It is complete nonsense. Great. And you could be a developer for 40 years, if you do not precise why and how. This is your comment which is arcane bullshit and complete nonsense.
    - TheCoelacanth 6y ago
      Understanding make is the easy part. Manual dependency resolution is a tedious waste of time, no matter how well you understand what you are doing. It can and should be automated.
    - AlphaSite 6y ago
      I think there’s a difference between being able to use make and ending bale to understand make. My suspicion is that most people can’t understand the makefile for a project they didn’t write or spend significant time on. It’s nice that their is a stable convention, but it’s a shame that it’s so dated and is missing so many modern conveniences (mostly to do with dependency handling).
busterarm 6y ago
Considering the staggering number of languages out there that have implemented their own worse-version of make, or even those that haven't and the language-agnostic tooling systems that are implementing make instead... I hate to say this but Bazel is probably the first time we have a tool that's better than make. It took over 40 years to get here. And it's still a pain in the ass.
- throwaway894345 6y ago
  > Considering the staggering number of languages out there that have implemented their own worse-version of make, or even those that haven't and the language-agnostic tooling systems that are implementing make instead... The language-specific build tools tend to be good, at least for mainstream languages introduced in the last 20 years. Certainly better than make. Bazel and especially Nix are really interesting and directionally correct, but like you mention, they are pains in the ass. Fortunately, their issues aren’t fundamental to the category of general purpose reproducible build tools. They’re just issues of execution. And arguably Nix isn’t even trying to be a build tool as much as a packaging tool (subtle but manifestly important difference), which is a damn shame.
  - adev_ 6y ago
    > The language-specific build tools tend to be good, at least for mainstream languages introduced in the last 20 years. Certainly better than make. They are good for 'quick & dirty' dev usage. And terrible for everything else. Specially integration. If they were perfect, you would not see things like lerna in JS (https://github.com/lerna/lerna https://github.com/lerna/lerna) or Conda in python (https://docs.conda.io/en/latest/ https://docs.conda.io/en/latest/) to go around them. > And arguably Nix isn’t even trying to be a build tool as much as a packaging tool (subtle but manifestly important difference), which is a damn shame. And they are right to be so. Build system and Package manager should be separated, or at least should be usable independently. If your environment is multi-languages or system oriented, there is no possible practical way you can get a tool that reliably do both and scale. It would imply to rewrite every the language specific builder of every language. I would say that in an ideal world, we would have language specific build system and one generic & portable set of dependency resolution tools (package managers). In our current world, every language is its own isolated island and making them interoperate is a mess.

adev_ 6y ago

> Nearly choked on my water reading this. Incredible how many developers are stockholme syndrome'd by their godawful tooling experience. I tend to name a "magic bulshit bloat tool" that will makes me download 350MB of crap to compile an 'hello world' a "godawful tooling experience". We are all free to have our own definition.

staticassertion 6y ago
You can tell me that other build tools have problems, but the "You must know how to run some os/project-specific commands to write a program or you're a bad developer" is the funniest kind of gatekeeping to me. But keep calling people "script kiddies" that's cool.
- adev_ 6y ago
  > commands to write a program or you're a bad developer" is the funniest kind of gatekeeping to me. I am curious of your notion of "gatekeeping", because you are the one being funny here. People have been able to understand Make, use it and compile C for 20 damn years: Are people being more stupid today ? ( Spoiler: No) If "today", with the unprecedent level of documentation you have on the Web, it is a problem for you to do so, then yes: you are indeed a bad developper. I am a strong believer of "the show me the code" approach. It is easy to call all the actual tooling a "dumpfire", then show me a better one, or at least document in details what "a better" one would be. Critics are easy and in this precise context, without arguments, they are just FUD or religious beliefs.
  - staticassertion 6y ago
    > I am curious of your notion of "gatekeeping" Repeatedly telling people that they're bad developers, should walk away from a computer, that they are "script kiddies", because they do not know or enjoy some arcane technical artifact. I call this gatekeeping.
    - adev_ 6y ago
      > enjoy some arcane technical artifacts Except that I do not think that you can call executing "make" and using your native package manager an "arcane", I am sorry. These are basic actions that are documented even from tutorials from the 90's. They are basic actions that are generally part of any first year study in computer sciences. That is not 'gatekeeping', there is no gate to keep here. I name more that fight laziness and understand your tooling.
      - DagAgren 6y ago
        Speaking as a C developer of twenty or thirty years or so who's used make for all that time: Make is absolute, utter arcane bullshit. It is mad. It is complete nonsense.
        adev_ 6y ago
        > Make is absolute, utter arcane bullshit. It is mad. It is complete nonsense. Great. And you could be a developer for 40 years, if you do not precise why and how. This is your comment which is arcane bullshit and complete nonsense.
  - TheCoelacanth 6y ago
    Understanding make is the easy part. Manual dependency resolution is a tedious waste of time, no matter how well you understand what you are doing. It can and should be automated.
  - AlphaSite 6y ago
    I think there’s a difference between being able to use make and ending bale to understand make. My suspicion is that most people can’t understand the makefile for a project they didn’t write or spend significant time on. It’s nice that their is a stable convention, but it’s a shame that it’s so dated and is missing so many modern conveniences (mostly to do with dependency handling).

busterarm 6y ago

Considering the staggering number of languages out there that have implemented their own worse-version of make, or even those that haven't and the language-agnostic tooling systems that are implementing make instead... I hate to say this but Bazel is probably the first time we have a tool that's better than make. It took over 40 years to get here. And it's still a pain in the ass.

throwaway894345 6y ago
> Considering the staggering number of languages out there that have implemented their own worse-version of make, or even those that haven't and the language-agnostic tooling systems that are implementing make instead... The language-specific build tools tend to be good, at least for mainstream languages introduced in the last 20 years. Certainly better than make. Bazel and especially Nix are really interesting and directionally correct, but like you mention, they are pains in the ass. Fortunately, their issues aren’t fundamental to the category of general purpose reproducible build tools. They’re just issues of execution. And arguably Nix isn’t even trying to be a build tool as much as a packaging tool (subtle but manifestly important difference), which is a damn shame.
- adev_ 6y ago
  > The language-specific build tools tend to be good, at least for mainstream languages introduced in the last 20 years. Certainly better than make. They are good for 'quick & dirty' dev usage. And terrible for everything else. Specially integration. If they were perfect, you would not see things like lerna in JS (https://github.com/lerna/lerna https://github.com/lerna/lerna) or Conda in python (https://docs.conda.io/en/latest/ https://docs.conda.io/en/latest/) to go around them. > And arguably Nix isn’t even trying to be a build tool as much as a packaging tool (subtle but manifestly important difference), which is a damn shame. And they are right to be so. Build system and Package manager should be separated, or at least should be usable independently. If your environment is multi-languages or system oriented, there is no possible practical way you can get a tool that reliably do both and scale. It would imply to rewrite every the language specific builder of every language. I would say that in an ideal world, we would have language specific build system and one generic & portable set of dependency resolution tools (package managers). In our current world, every language is its own isolated island and making them interoperate is a mess.