4 ms·

I feel a bit like there is some kind of programming totalitarian personality that wants there ever to always to be one thing. There are so many build systems i

I feel a bit like there is some kind of programming totalitarian personality that wants there ever to always to be one thing. There are so many build systems in C and C++ because for each of those, someone finds something to be inadequate and has something else that works for them. Just like there is no standard for sizeof(int) or whatever, because it started with one size on one CPU and somebody brought it to a different CPU where another size made better sense. Today you can usually guess that it's 32 bits, but there are domains where it's not. These languages are meant to not impose a lot on the implementer or practitioner. Having the standard specify that every build needs to potentially pull down a bunch of crap from github or wherever else is going to be really annoying to a lot of people. It is a misguided suggestion. I think it mostly comes from people not working in the language, or unfamiliar with code bases that are working well as-is.

antoineMoPa 7y ago
I said there should be a standard package manager, this does not mean that it has to be the only one. It would just be easier for everyone if there was a widely adopted way to package, install and update stuff, like most modern languages.
- fit2rule 7y ago
  There is such a thing for C/C++ devs: Git. This works so well you may have hardly even noticed its so widespread as a solution to the problems you describe.
msla 7y ago
> Just like there is no standard for sizeof(int) or whatever, because it started with one size on one CPU and somebody brought it to a different CPU where another size made better sense. Today you can usually guess that it's 32 bits, but there are domains where it's not. This is different: C has to be implemented efficiently on a wide range of hardware, almost without regard for how good of a fit that hardware is for C or any modern language. Machines with 36-bit integers and 18-bit pointers? They got C compilers. Machines with no native notion of byte addressability? Plenty of C compilers for those things. Machines with application-visible segmentation? Of course! Those machines were quite popular for a while. Therefore, the C programming language has to at least try to make it possible for portable programs to exist. That's the implied contract of the C standard: Code to the standard, and your programs will be compilable and runnable on every platform targeted by a conformant C compiler. So, since int is going to be a size adapted to the hardware, as required for efficiency, the programs have to know how big an int is, as required for portability. > Having the standard specify that every build needs to potentially pull down a bunch of crap from github or wherever else is going to be really annoying to a lot of people. No language standard specifies that, I'm pretty sure. The ES6 standard doesn't specify left_pad and the C++ standard doesn't specify Boost. However, the standards also don't specify things which could replace those external libraries in a portable fashion which is guaranteed to always be there. If you take something out of the standard library, it has to go somewhere; people aren't going to stop doing that thing just because the standard no longer mentions it.
Volt 7y ago
>There are so many build systems in C and C++ because for each of those, someone finds something to be inadequate and has something else that works for them. Makes me wonder why Lisp is cursed[1] but C++ isn't. [1]: http://www.winestockwebdesign.com/Essays/Lisp_Curse.html http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
- pjmlp 7y ago
  C++ has OS vendors backing it, while Lisp OS vendors lost the war. Never underestimate the power to use the OS SDK to sell a programming language.

antoineMoPa 7y ago

I said there should be a standard package manager, this does not mean that it has to be the only one. It would just be easier for everyone if there was a widely adopted way to package, install and update stuff, like most modern languages.

fit2rule 7y ago
There is such a thing for C/C++ devs: Git. This works so well you may have hardly even noticed its so widespread as a solution to the problems you describe.

msla 7y ago

> Just like there is no standard for sizeof(int) or whatever, because it started with one size on one CPU and somebody brought it to a different CPU where another size made better sense. Today you can usually guess that it's 32 bits, but there are domains where it's not. This is different: C has to be implemented efficiently on a wide range of hardware, almost without regard for how good of a fit that hardware is for C or any modern language. Machines with 36-bit integers and 18-bit pointers? They got C compilers. Machines with no native notion of byte addressability? Plenty of C compilers for those things. Machines with application-visible segmentation? Of course! Those machines were quite popular for a while. Therefore, the C programming language has to at least try to make it possible for portable programs to exist. That's the implied contract of the C standard: Code to the standard, and your programs will be compilable and runnable on every platform targeted by a conformant C compiler. So, since int is going to be a size adapted to the hardware, as required for efficiency, the programs have to know how big an int is, as required for portability. > Having the standard specify that every build needs to potentially pull down a bunch of crap from github or wherever else is going to be really annoying to a lot of people. No language standard specifies that, I'm pretty sure. The ES6 standard doesn't specify left_pad and the C++ standard doesn't specify Boost. However, the standards also don't specify things which could replace those external libraries in a portable fashion which is guaranteed to always be there. If you take something out of the standard library, it has to go somewhere; people aren't going to stop doing that thing just because the standard no longer mentions it.

Volt 7y ago

>There are so many build systems in C and C++ because for each of those, someone finds something to be inadequate and has something else that works for them. Makes me wonder why Lisp is cursed[1] but C++ isn't. [1]: http://www.winestockwebdesign.com/Essays/Lisp_Curse.html http://www.winestockwebdesign.com/Essays/Lisp_Curse.html

pjmlp 7y ago
C++ has OS vendors backing it, while Lisp OS vendors lost the war. Never underestimate the power to use the OS SDK to sell a programming language.