3 ms·

> The point is the runtime dependencies are small. Is that the point? Because that makes absolutely no sense to me at all in a world of modern linkers, shared

by sramsay 13y ago

> The point is the runtime dependencies are small. Is that the point? Because that makes absolutely no sense to me at all in a world of modern linkers, shared libraries, etc. My assumption is that the OP was concerned about reducing the user's dependency list. And on that score, yes: I could have added a compiler to my list.

asveikau 13y ago
If "the user" is compiling code then yes, that is a dependency for them or their package manager/ports system to track. However many times the user installs a binary and never needs the source. The other thing, I think this highlights one difference between C programmers and others, and maybe explains our disagreement. People coding in C often care a lot about the object code. It's not all that uncommon to look at the assembly and question what your compiled has done and make tweaks to get the binary looking better. Hence the disconnect between me saying runtime dependencies are the most important thing and you saying you don't want to install autotools to build. To me the latter complaint comes from a completely different planet.
- sramsay 13y ago
  I think you're making it too complex (or else I am). I think the OP is making a kind of "batteries included" argument (a la Python) -- that is to say, "it's better when the language has everything built in, as opposed to farming things off to external, 3rd party libraries." All's I'm saying is that that seems to me pretty silly. It can't be about reducing the user's burden, because you're going to burden the user anyway with all kinds of toolchain dependencies. It can't be about the runtime, because the user will, except in rare circumstances, hardly notice; if they have autotools, they have glib. I can think of million reasons not to use C. But, "Well, I don't know. I'd have to use a third party library. . ." Really?

by sramsay 13y ago

asveikau 13y ago

If "the user" is compiling code then yes, that is a dependency for them or their package manager/ports system to track. However many times the user installs a binary and never needs the source. The other thing, I think this highlights one difference between C programmers and others, and maybe explains our disagreement. People coding in C often care a lot about the object code. It's not all that uncommon to look at the assembly and question what your compiled has done and make tweaks to get the binary looking better. Hence the disconnect between me saying runtime dependencies are the most important thing and you saying you don't want to install autotools to build. To me the latter complaint comes from a completely different planet.

sramsay 13y ago
I think you're making it too complex (or else I am). I think the OP is making a kind of "batteries included" argument (a la Python) -- that is to say, "it's better when the language has everything built in, as opposed to farming things off to external, 3rd party libraries." All's I'm saying is that that seems to me pretty silly. It can't be about reducing the user's burden, because you're going to burden the user anyway with all kinds of toolchain dependencies. It can't be about the runtime, because the user will, except in rare circumstances, hardly notice; if they have autotools, they have glib. I can think of million reasons not to use C. But, "Well, I don't know. I'd have to use a third party library. . ." Really?