The C language is not designed for building huge programs by accretion of modules. The idea is that you build many independent programs, and then you glue them together using scripts.
> The idea is that you build many independent programs, and then you glue them together using scripts.
That doesn't exactly describe kernels or embedded systems, which are C's strongest bastions. Whether it's well designed for the purpose or not, whether modules are appropriate in that context or not, a significant majority of the C code out there (including most common web servers, databases, etc.) does not fit your description at all.
Building small programs and gluing together with scripts is great, but hardly relevant. You don't need includes or modules for that. What if you do need to build one large program, like those aforementioned web servers or databases, or (what I work on) a storage server? That's where the difference between textual inclusion and modules really comes into play, and modules are strictly better than includes in every way.
I think the problem here is that you're confusing modules with things built on top of modules - specifically package managers. A lot of the package managers out there are horrible and create more problems than they solve, but that has almost nothing to do with modules as a language construct.
>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).
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.
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.
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?
You use the MMU to create virtual address spaces and the kernel to provide a message passing interface. The MMU may cause you to incur some latency but in exchange you get some pretty good isolation between components of your system. Even more so if your kernel is proven using formal methods.
There's no need to get snarky. I've used similar parts before, for example TI's Hercules RM4 does not have an MMU either and so what I said wouldn't apply there. But that doesn't mean you would never have an MMU.
Indeed, my apologies. I actually quite like the idea. It reminds me a lot of Erlang, where you set up a bunch of small processes and if any of them die, you can a) try to recover quickly, or b) run in reduced functionality mode. I just haven't been fortunate enough to work with embedded processors where it'd be a good fit; they've either been on the small side (Cortex M, MSP430, AVR) or on the big side (iMX6, AM335x) and just run full-blown Linux.
That doesn't exactly describe kernels or embedded systems, which are C's strongest bastions. Whether it's well designed for the purpose or not, whether modules are appropriate in that context or not, a significant majority of the C code out there (including most common web servers, databases, etc.) does not fit your description at all.
Building small programs and gluing together with scripts is great, but hardly relevant. You don't need includes or modules for that. What if you do need to build one large program, like those aforementioned web servers or databases, or (what I work on) a storage server? That's where the difference between textual inclusion and modules really comes into play, and modules are strictly better than includes in every way.
I think the problem here is that you're confusing modules with things built on top of modules - specifically package managers. A lot of the package managers out there are horrible and create more problems than they solve, but that has almost nothing to do with modules as a language construct.