3 ms·
There's some nuance to be had here. The important implications of a larger C standard library aren't technical, they're social--i.e. the implications of a large
by kerkeslager 7y ago
There's some nuance to be had here. The important implications of a larger C standard library aren't technical, they're social--i.e. the implications of a larger standard library for teams using C are negative. Let's look at two other languages: C++ and Python.
C++ has a large standard library. This ends up being one of C++'s biggest downfalls: the various libraries don't play nicely with each other, have many different ways of doing the same or similar things, each have complex gotchas--and it's impossible to know them all, so you never really know C++. It's full of dark corners, and the result is bugs, and difficult debugging, and teams that try to enforce only using subsets of the language (and inevitably fail a little). This problem is only getting worse over time. The reason C++'s new features haven't just been backported back into the C standard is that people saw this coming and didn't want it happening. C is already a complex language, but it's still simple enough that you can actually reasonably read the entire C standard library (I have; QED).
A large standard library doesn't have to be this way. Python has a large standard library--this is the "batteries included" of Python. The reason Python can get away with this is that they can deprecate their mistakes. And they are: quite a few modules in the standard library will disappear with the Python 2 sunset. But this is not without downsides--everyone who has been working on a major Python project in the past few years has felt the pain at some point. And C is not Python: it's the backbone of a lot of other applications, so breaking changes are far more costly for C than for Python. C is "once supported, always supported", and for very good reason, so we can't afford to introduce mistakes to the standard.
So, if you don't want the problems of all the cruft in C++'s standard library, and you don't want the deprecations of Python's standard library, your only remaining choice, by process of elimination, is to have a very slim standard library, and make VERY conservative choices about what to add to it.
I think that we should add a new string library to C when strings are a solved problem. But contrary to what people are saying, strings aren't a solved problem. We shouldn't add a string library that doesn't solve internationalization, for example. And in fact, with that problem, the fox is in charge of the henhouse, making the problem worse: we've got people in the Unicode team adding fsking emoji to the standard. Unfortunately, I think we're going to have to wait until Unicode collapses under its own bad decisions and is replaced by a better standard, and that standard becomes mature, before committing to that proven solution. Otherwise we end up with ICU-related crap into the "once supported, always supported" C standard library.
- einpoklum 7y ago> C++ has a large standard library. Is it that large? i.e. is it larger than, say, Java's ? > it's impossible to know them all, so you never really know C++ This is semantic quibbling. You know a language more if you know its commonly-used libraries better - whether they're in the standard or not. > the various libraries don't play nicely with each other They may not be in perfect synch, but they play ok-ish-ly with each other - as far as I can tell. However, not playing nice is much much more of a problem with non-standard libraries - in various languages. I'm sure C programmers have that experience with a vengeance... say, everybody using different implementations of basic data structures like queues and lists and hash tables and so on. > It's full of dark corners Yes, yes it is. And they're pretty scary... however, that's not really because of the library size. Also, those dark corners exist, unexplored, for C libraries; it is arguably better that they be mapped once and for all, at least some of them which are somewhat-frequently stumbled upon. ... More generally - the issue you're describing seems to be more with the combination of "iron-clad backwards compatibility" and a larger standard library: - C has the former, not the latter - Python has the latter, not the former C++ has the former (upto minor points like the `auto` keyword), as well as the latter, but with warts. The warts are there, that's true, but they're not so bad. And use of the standard library does pay off very nicely - often removing warts in your own code.
- kerkeslager 7y ago> Is it that large? i.e. is it larger than, say, Java's ? Large, yes. Larger than Java's? I don't know. It's larger than C's, that's for sure. > This is semantic quibbling. You know a language more if you know its commonly-used libraries better - whether they're in the standard or not. If it's in the standard library you better bet it gets used, even if only by your dependencies. > I'm sure C programmers have that experience with a vengeance... say, everybody using different implementations of basic data structures like queues and lists and hash tables and so on. Eh, it's not too bad in C. Libraries tend not to force you to use their data structures too much, and if they do, you just don't use that library. Some, you use their data structures because that's what you included the library to get. It's certainly a problem, but dependency management is easier than having dependencies you can't make go away. > The warts are there, that's true, but they're not so bad. And use of the standard library does pay off very nicely - often removing warts in your own code. So use C++, if you like it. My post wasn't an attack on C++. C++ has its upsides. I only described the downsides of C++ because I was explaining what C is trying to avoid.