> so you know all this complexity by heart?

No. It's that you've built up a personal database of libraries, best-practices, idioms, et al. over decades.

When you move on to a new project, this personal database comes with you. You don't need to wonder if version X of Y framework or library has suddenly changed and then spend a ton of time studying its differences.

Of course, the response to this is: "You can do this in any language!"

And you'd be right, but after 20 years straight of working in C alongside teams working in Java, Perl, Python, Scheme, OCaml, and more, I've only ever seen experienced C programmers hold on to this kind of digital scrapbook.

I don't see how this can work.

You have your personal string library.. and you move to a new project, and it has it's own string library (it's pretty much given, because stdlib C library sucks). So what next? Do you rewrite the entire project into _your_ string library, and enjoy familiar environment, until the next "experienced C programmer" comes along? Or do you give up on your own string library and start learning whatever project uses?

And this applies to basically everything. The "personal database" becomes pretty useless the moment the second person with such database joins the project.

(This is a big part of Python's popularity, IMHO. Maybe "str" and "logger" are not the best string and logger classes in the world, but they are good enough and in stdlib, so you never have to learn them when you start a new project)

It's not the "string library" that's important, but standardized interface types - so that different libraries can pass strings to each other while still being able to select the best string library that matches the project's requirements.

In C this standardized string interface type happens to the poiinter to a zero-terminated bag of bytes, not exactly perfect in hindsight, but as long as everybody agrees to that standard, the actual code working on strings can be replaced with another implementation just fine.

E.g. a minimal stdlib should mostly be concerned about standardized interface types, not about the implementation behind those types.

Are you saying that if you join existing project which uses acuozzo_strzcpy, and you need to do some string copying, instead of using the same functions that everyone already uses, you'll bring your own library and start using flohofwoe_strjcpy in all code _you_ write? (Assuming both of those work on char* types, that is)?

This.. does not seem like a very good idea if you want your contributions to be received well.

I mean, it depends? The fact that it's possible doesn't mean it's a good idea, but at least it's possible. Maybe flohofwoe_strjcpy has a slight performance advantage in an extremely esoteric edge case but extremely hot loop that wasn't considered by acuozzo_strzcpy.

(Not a GP) I think you can see how poorly the string abstraction argument looks in context of a team-based project. Instead of dismissing it completely I would like to provide an example of a context where C is perfectly fine now.

Consider data compression library like Oodle. Even with closed source and use of dangerous things like multiple threads it is perfectly reasonable deal if game project's budget has money to be spent on performance.

The thing is if game project have money it is not likely to be interested in written in C game engines or core middleware libraries (like physics, sound or occlusion culling). Because after buying a license your team is still expected to work in that code even if official support is very active.

Disclaimer, I work in gamedev and never needed to touch C code.

> neither receiving not sharing the source code with others, treating third-party libraries as blackboxes.

Tbh, this is an intriguing idea. Determine the size of a library (or module in a bigger system) by what one programmer can manage to build and maintain. Let the public interface be the defining feature of a library, not its implementation.