[DalekBaldwin]

It's difficult to relate this to modern perspectives on software design and architecture because the running example is hard to comprehend. It seems to be an interface to a data structure that may have been useful in certain applications in the context of hardware constraints 50 years ago. It would be great if somebody published an implementation of this example with the variations in C for illustration.

[AugustoCAS]

I disagree, I just left a company in which most teams 'modularized' their code in the way Parnas describes as not ideal. What Parnas describes are low level modules that are now mostly provided by languages, but the same applies to 'business' modules. In the org I left, minor changes in a microservice had wildly unexpected consequences due to a mix of lack of information hiding coupled with large data objects. One example: storing a debit in an account would become a credit when loaded back under some circumstances.

The mentality of most developers there was: How can I make the change described in the ticket by touching as little existing code as possible?

[pjmlp]

Except C is quite a poor example for how to use modules.

TU with opaque pointers can be used for such purposes, and they are, but still fail short of Modula-2, Mesa, CLU and UCSD Pascal, to cite contemporary examples.

[rewmie]

> Except C is quite a poor example for how to use modules.

How come? C makes it trivial to create self-contained modules.

[pjmlp]

C makes it trivial to create poor man's modules.

It lacks almost everything that a programming language with modules offers on its type system, and compiler toolchain.

Proper public/private types, module initialization/shutdown, linking with type checking, namespaces.

One can fake modules with void pointers, static types on translation units, prefixes that hopefully no one else is using, and that is about it.

[rewmie]

> Proper public/private types,

Modules either have types as part of their interface, or haven't. I C, the declarations shipped in the interface header represent the interface, and the types declared in it are public types.

C also supports symbols with internal linkage.

What exactly is missing?

> module initialization/shutdown,

What's wrong with initializing objects? Languages such as Rust also rely on factory methods to instantiate objects.

> linking with type checking,

The interface headers define the symbols, which must correspond to the symbols handled by the linker. What's missing?

> namespaces.

That definitely C doesn't support as a first class citizen, but this is nothing that symbol prefixes don't handle.

What's missing, then?

[michaelfeathers]

To me, the most amazing thing is that he says that it is a problem that would take the average programmer a week back then, but today it could probably be coded in 5 minutes in AWK or Perl.