hyper.dev
well come

2026-11-01 · dx - 5 - code crafting codex

At the very core of programming, there is an obvious need for a divide and conquer strategy. And that is at the personal level of reflexion. Of course it happens to be true in other domains.

This idea is also expressed as Separation of Concerns which Wikipedia nails its value in the following wishful paragraph without mentioning its evil extrema:

The value of separation of concerns is simplifying development and
maintenance of computer programs. When concerns are well separated,
individual sections can be developed and updated independently. Of
special value is the ability to later improve or modify one section of
code without having to know the details of other sections, and without
having to make corresponding changes to those sections.

Otherwise said two components satisfy “separation of concerns” if their implementation details don’t leak.

Drawing lines is not easy, especially when you consider the infinite entangledments of human understandings.

I think that Zen of Python by Tim Peters provides useful abstract guiding principles:

• Beautiful is better than ugly.
• Explicit is better than implicit.
• Simple is better than complex.
• Complex is better than complicated.
• Flat is better than nested.
• Sparse is better than dense.
• Readability counts.
• Special cases aren’t special enough to break the rules.
• Although practicality beats purity.
• Errors should never pass silently.
• Unless explicitly silenced.
• In the face of ambiguity, refuse the temptation to guess.
• There should be one – and preferably only one – obvious way to do it.
• Although that way may not be obvious at first unless you’re Dutch.
• Now is better than never.
• Although never is often better than right now.
• If the implementation is hard to explain, it’s a bad idea.
• If the implementation is easy to explain, it may be a good idea.
• Namespaces are one honking great idea – let’s do more of those!

Those quotes are also helpful:

Simple things should be simple, complex things should be possible

– Alan Kay

In French you say:

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

– Antoine de Saint-Exupéry

Is that an event horizon:

To design something really well, you have to get it. You have to really grok what it’s all about. It takes a passionate commitment to really thoroughly understand something, chew it up, not just quickly swallow it. Most people don’t take the time to do that.

– Steve Jobs

Then:

Programs are meant to be read by humans and only incidentally for computers to execute

– Donald Knuth

The following quote must be studied in the light of broad sense that can take the word before the last:

There are only two hard things in Computer Science: cache invalidation and naming things.

– Phil Karlton

And this one provides more food for thought:

The Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free? The Web, in comparison, is a joke. The Web was done by amateurs.

– Alan Kay

John Nathan Shutt did not sleep on it either, at least as far language construction is concerned its guidelines in R-1RK written as “Principles of language design” are:

0.1 The design of Kernel

[…]

0.1.2 Principles of language design

Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.

R6RS

The above sentence declares the basic design philosophy of the Scheme programming language. It is also the starting point for the design of the Kernel programming language, which attempts to carry the philosophy further, creating a language still smaller, stronger, and more general than Scheme. This abstract strategy would be difficult to apply directly to specific tactical design decisions (as called for in §0.1.1), so Kernel refines it with more concrete guidelines.

• G1 [uniformity] Special cases should be eliminated from as many aspects of the language as the inherent semantics allow.

• G1a [object status] All manipulable entities should be first-class objects (see Appendix B).

• G1b [extensibility] Programmer-defined facilities should be able to duplicate all the capabilities and properties of built-in facilities.

• G2 [functionality] The language primitives should be capable of implementing all the advanced features of the R5RS (such as dynamic-wind , here in §7.2.5; or, for that matter, lambda , here in §5.3.2)

• G3 [usability] Dangerous computation behaviors (e.g., hygiene violations), while permitted on general principle, should be difficult to program by accident. Guideline G3 was formulated specifically to protect the ideal of ‘removing weaknesses and restrictions’ from devolving into mere amorphism. It has proven to be a particularly useful heuristic in practice, being explicitly invoked in the report more often (at last count) than all the other guidelines put together.

• G4 [encapsulation] The degree of encapsulation of a type should be at the discretion of its designer.

• G5 [efficiency] Efficient implementation should follow naturally from an elegant language design, without any compromise of elegance being made to achieve it.

Smalltalk ranks one criterion above all the others:

If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual. – “Design Principles Behind Smalltalk” (Dan Ingalls, Byte, 1981)

If sounds, grounds, ideas and understandings are echoing, don’t overestimate their infinite reflection that might be aiming an unforeseen dubious equilibrium, find your way out, escape the invisible tie knot, think on your own.

Ranking is editorial.

Originally published at hyperdev.fr, 2018 (archive). Added John Nathan Shutt’s Kernel programming language guidelines along Dan Ingalls quote