Complexity

Since the 70s it has been understood that the key to actually manage complexity is to use abstract interfaces, as parts of Abstract Data Types definitions, which, in turn, are implemented within corresponding modules.

So, not just modularity, but clear, well-defined, non-leaking actual abstraction boundaries is the key concept (and therefore the basis of all methodologies) in programming, both in the small and at a scale.

It is no surprise or a coincidence that well-researched and pragmatic languages emphasize and focus on exported interfaces.

Abstract interfaces should be “first-class entities”, so to speak, and modern Ocaml (and F#), as well as the classic Standard ML are those which made modules (conceptually - named sets of public interfaces) “first class”.

Having a separate, clear, well-defined and type-checked module signature is crucial for understanding of both the abstraction which is being to captured and its boundaries, which clearly separate use from implementation, which is the principle behind ADTs. Whether it is an OO class or a FP module is irrelevant.

One absolutely should not be forced to read the module to extract its public interface. It must already be summarized in one place, and must be mechanically checked and verified. There is no substitute for this.

“Designers” of idiotic amateur languages do not even understand this need. And no, having commentaries and auto-generated documentation is not enough.

The whole point is to have type-signatures and module-signatures to be the only mechanically checked and formally verified documentation that is required - no need to say anything twice. No need to read comments (and auto-generated “docs”) and believe they are true and not out of sync.

The closer we are to Sets and Logic - the better.

In future, the assertions of “laws” and invariants (currently pushed away into the tests) must be the part of definitions, residing in a special clauses, which may refer to external files.