The basic idea here is that complex data structures are usually easy to understand, while complex code isn't. This is one of the few fundamental insights about programming that withstood the test of time.
Note that while this all is not necessarily about types, this is about documenting the data structures - and good type systems enable you to do so in an unambiguous and even machine-checkable way.
1975: There's a famous quote in "The Mythical Man-Month" by Frederick Brooks:
Show me your flowcharts and conceal your tables,
and I shall continue to be mystified.
Show me your tables,
and I won’t usually need your flowcharts;
they’ll be obvious.
Note that this is old language from the 1970s, where "tables" roughly means "types definitions" (or comments describing the structure of input and output values, think of database table definitions) and flowcharts roughly means "function definitions" (think of hand-written flowcharts written next to low-level code to make all its GOTOs understandable).
1989: You can find a similar statement in "Notes on Programming in C" by Rob Pike:
Data dominates.
If you've chosen the right data structures and organized things well,
the algorithms will almost always be selfevident.
Data structures, not algorithms, are central to programming.
Note that Rob Pike refers directly to Frederick Brooks.
1995: Frederick Brooks reiterates this statement in the second edition of "The Mythical Man-Month" (20 years later).
2003: The same idea is also stated as one of the basic design rules in "The Art of Unix Programming" by Eric Raymond:
Rule of Representation:
Fold knowledge into data, so program logic can be stupid and robust.
Note that Eric Raymond refers directly to Rob Pike.
2006: Another quite famous quote from the Git mailing list by Linus Torvalds:
Bad programmers worry about the code.
Good programmers worry about data structures and their relationships.
And so on.
(BTW, does anyone know about a similar quote before 1975? Or a popular reformulation after 2006?)
I have found a lot of bang for the buck in software development comes from "the schema". I can use them to automatically enforce the runtime contracts between my code and my consumers'. As a communication mechanism between myself and other developers, the well-annotated schema builds an unambiguous picture for everyone of the entities, relationships w/ restrictions, and cardinalities in our systems.
At the boundaries of our microservices, we JSON Schema validate messages before they are sent on the service and upon receipt by the client (at least in the non-production environments.) We use the schema to guarantee the services and clients are always "speaking the same language" even when teams are releasing versions of their code at different times.
Note that while this all is not necessarily about types, this is about documenting the data structures - and good type systems enable you to do so in an unambiguous and even machine-checkable way.
1975: There's a famous quote in "The Mythical Man-Month" by Frederick Brooks:
Note that this is old language from the 1970s, where "tables" roughly means "types definitions" (or comments describing the structure of input and output values, think of database table definitions) and flowcharts roughly means "function definitions" (think of hand-written flowcharts written next to low-level code to make all its GOTOs understandable).1989: You can find a similar statement in "Notes on Programming in C" by Rob Pike:
Note that Rob Pike refers directly to Frederick Brooks.1995: Frederick Brooks reiterates this statement in the second edition of "The Mythical Man-Month" (20 years later).
2003: The same idea is also stated as one of the basic design rules in "The Art of Unix Programming" by Eric Raymond:
Note that Eric Raymond refers directly to Rob Pike.2006: Another quite famous quote from the Git mailing list by Linus Torvalds:
And so on.(BTW, does anyone know about a similar quote before 1975? Or a popular reformulation after 2006?)