[BirAdam]

By “reinvent everything,” I believe you mean to say that you have to make your own linked-lists to have adjustable strings, and you have to create structs with function pointers to have objects…

The simplicity is either in the language and tooling around the language, or it is in the code you read and write in that language. C chose to be simple in the language itself and not in the code.

The single greatest praise that I will give to C is that the entirety of the language can be held in the mind of the programmer using it, with zero need for reference. This is impossible in most other languages.

[gk1256]

> By “reinvent everything,” I believe you mean to say that you have to make your own linked-lists to have adjustable strings, and you have to create structs with function pointers to have objects…

Spot on.

> C chose to be simple in the language itself and not in the code.

But it market itself being simple so people even newcomers think that C is simple in every regard. Only few people rarely acknowledge this fact.

> The single greatest praise that I will give to C is that the entirety of the language can be held in the mind of the programmer using it, with zero need for reference. This is impossible in most other languages.

In other languages, which parts you are unable to held in your mind?

The only instance where I need references in C++ is STD library features. But if we measure, it take less time than if we were to reinvent it on C.

[notacoward]

What I think a lot of detractors miss is that this reinvention need not be done by every single C programmer. In any significantly large and/or old C codebase, there will be local data structures, functions, macros, and idioms to solve the kinds of problems specific to that domain in a way suitable for that domain. For example, in my own domain of servers for distributed filesystems and similar things, the codebases I worked on had sophisticated ways of dealing with memory lifetimes across "discontinuous" control flows because of queuing, RPC, and so on. Those ways worked. I saw similar things in kernels, databases, etc. When I started working on a C++ codebase for yet another distributed storage system, every programmer seemed to be fighting to make C++/STL do the right thing in a memory-lifetime milieu that the language and library designers had apparently never contemplated. Worse, each programmer seemed to be solving those problems in different ways, leading to a proliferation of approaches which sometimes weren't even compatible with each other. That code had far more copies and memory leaks than the C code I'd worked on previously, despite the previous code having been worked on mostly by programmers with a significantly lower skill/experience level. Ironically, there was more wheel-reinvention in the C++ code than in C.

I'm not saying C is the right choice for every project. C++ isn't either. C++ might be a pretty good language for doing the sorts of mid-level things that the people on the C++ language committee like to do (surprise surprise) but there are many broad domains at both higher and lower semantic levels for which it can be a poor fit. For a lot of low-level stuff a language that lets people define their own domain-specific abstractions will beat an "every bell and whistle and all wrong for what we're doing" language every time.

[BenjiWiebe]

Why would you put function pointers in structs? The function still needs to be handed the struct when called (no 'this'), and every time you instantiate the struct you need to set the function pointers to the correct thing again.

It gains you approximately nothing, as far as I can tell.