[coldtea]

>The C language is not designed for building huge programs by accretion of modules.

Can you give a single concrete example of a problem, because the above are all noops semantically speaking...

>The idea is that you build many independent programs, and then you glue them together using scripts.

This is a non-starter for most use cases outside pipeable shell commands (which are not the only kind of programs people want to write).

People need, and write, and have written for decades, large programs in C, and programs in C which have from 10s to 100s of headers files included (including recursively from included libs).

[dTal]

People need it, yes. And they use C to do it. But C wasn't designed for it. C was designed to write programs for Unix, which fit this description.

[coldtea]

Like the etymology of a word doesn't necessarily convey its meaning, the "original intent" of something is often meaningless as to its actual practical use.

The idea you mention is valid, and is part of the Unix philosophy.

But it was never the idea that C should be used JUST for that.

In fact the first use of C was to write a whole operating system.

[jschwartzi]

Well the systems I'm developing now consist off small interlocking C++ processes which use UNIX IPC to communicate across address spaces. It's not what most people are used to but it works very well in this case. The aren't shell commands like you're thinking of but they are discrete programs.

[romeisendcoming]

Oh, I don't know. Gluing the programs together using RPC and REST seems to be working so well for everyone else. Why do you even need a shell or unix style pipelines, right?