My advice on implementing stuff in C:

> The type system is generally a mess, as early C didn't have a cast
> operator and therefore needed all kinds of crazy implicit conversions

C has a few implicit conversions that might be confusing to novices. That hardly qualifies it as "a mess." I think C's type system is fine for low-level programming, where you're playing with bits and bytes.

> There is no module system.

In C and C++, functions and variables that are declared "file static" can't be referenced outside that file. If you combine that with a sane policy about how to split up functionality between multiple files, it does of the things that module systems do in other languages.

C also has a built-in way of loading code at runtime in the form of shared libraries. C even has the ability to run code when a shared library is loaded, and when it is unloaded.

As Rusty would no doubt say: modularity isn't a programming language feature. It's a programmer feature.

> The preprocessor is a sucky workaround used to emulate features that ought
> to be in the language proper (genericity and modules), and it makes it
> much harder to build good tools for the C language.

Any language that doesn't have eval() probably needs a macro system.

Look at what happened with Java. In their arrogance, the designers believed that they were beyond the need for a macro system. But the language wasn't expressive enough to describe a lot of the things that people needed to do. The result was that an ugly mass of automatic code generators got written to do the things that a macro system would have done. Now, in addition to learning the core language, you have to read huge tomes describing these automatic code generators. Usually they come with clunky XML interfaces and specialized tools.

> There is no support for generic programming (read: type-safe container
> classes).

Ok, I agree with you here. Generic programming support would be a big improvement. Templates are probably C++'s best feature.