The author talks about conventions for C libraries in general. Among other things, it advocates not reinventing the wheel.

All fine things. The author has some good points on C library design. I have no problem with C (which I use heavily in both my startups), or with C libraries (which I've published, see my github), nor do I need a lecture on the benefits of reuse. Your imagination seems to be running wild here.

My problem is with the author's notion of reuse. Specifically, his lack of appreciation for the flipside: dependencies. We are told to write C libraries that in turn depend on GLib, GTK+, APR, and the like. As a consumer of C libraries, there is no way I'm going to be happy about pulling in GTK+ just to use a library that does Unicode manipulation. (His example, I'm not even making this up.)

That's what I meant by "middleware libraries" in my original comment. I like C libraries that do one thing and do it well, without adding unnecessary transitive dependencies. So, using C at the "lowest layer" of the dependency graph? Absolutely, all for it.

I'm still not seeing a reasoned explanation of why you should be forced to re-implement linked lists, hash tables, red-black trees, etc.

You shouldn't re-implement them. Use C++. STL has had fast, stable implementations of these for years. Destructors + exceptions (the only really useful parts of C++ imho) save you boatloads of nasty C code of the form:

int foo()
{
hashtable *h = hashtable_new();
...
if (err1) {
hashtable_free(h);
return err1;
}
...
if (err2) {
hashtable_free(h);
return err2;
}
...
if (h) hashtable_free(h);
return 0;
}

Or the almost equally repulsive

int foo()
{
hashtable *h = hashtable_new();
...
if (err = error1) goto error;
...
if (err = error2) goto error;
...
error:
if (h) hashtable_free(h);
return err;
}

Any large, layered C program using dynamic data structures inevitably fills up with this (error prone!) junk.

Don't like C++? Need a special data structure not in STL? Fine, use C. Hell, I've forked and contributed to a trie implementation in C [1] because I needed it in one project, and there were no quality implementations in C++. It worked out nicely because the program was small and the error prone junk (above) was minimal.

Another option is to write your app in a high level interpreted language to begin with, using whatever data structures they provide, and rewrite the critical path in C. I've been doing this like crazy recently [2] [3] [4].

Furthermore, you completely disregard anyone who either 1) is unable to use something besides C, and 2) people who chose to use C because they enjoy it.

I enjoy C as much as the next person, I hope I've clarified that. I also work in embedded contexts where C is the only option -- in one case, an AVR microcontroller with 8K of program memory. Do I still sometimes wish it was possible to program it in lisp or some other higher level language, like the JPL guys did when they debugged a space probe 100 million miles away [5]? Hell yeah I do.

[1] https://github.com/acg/critbit

[2] https://github.com/acg/lwpb

[3] https://github.com/acg/python-percentcoding

[4] https://github.com/acg/python-flattery

[5] http://www.flownet.com/gat/jpl-lisp.html