These are valid questions, Steven. The thread topic is supposed to be “code is read much more than it is written” (I tried to edit the title and original post to clarify this but the edit period has lapsed) but I think your questions, rhetorical though they may have been intended, more than deserve to be honored with an answer.
What exactly is the difference between complex and complicated?
Complex: made up of many simple elements, as in a readily-evident compound structure or system.
Complicated: a relationship of parts that interact and affect each other in elaborate, often obscure ways.
Though these two terms, complex and complicated, are easily intermingled, the difference is the clarity versus obscurity of the relationships between the elements of a multi-part system.
Is flat really better than nested?
Since the context is programming, one might consider the difference between a routine with many nested levels (indents) versus using a function call. Code folding also creates “flatness”; I put a fair amount of thought into structuring commented lines to create convenient “creases” in VS Code and other auto-folding IDE’s. This routinely involves blatant violation of the 4-space indent, but it’s a very limited exception, improves readability and assimilation tremendously, and is a net gain. Another example of flatness in practice would be a short IF:
clause that integrates better as a single line rather than LF+indent. This effect is exponential when you can use multiple consecutive one-line IF:
clauses.
how do you know if your code is beautiful or ugly?
Excellent question, and this illustrates the philosophical and sometimes subjective nature of the pyZen principles. Nevertheless, we can delineate some fundamental concepts and pierce the darkness. To wit:
Some levels in the aesthetic scale might be…
- Beautiful
- Elegant
- Workable
- Crude (but effective)
- Sloppy
- Ugly
- Painful, Torturous, Evil, etc.
“Beautiful” and “ugly” are subjective by definition, so a subsequent programmer’s experience defines where on the scale any given code might be–for them–which means that the skill, experience, and depth of knowledge of that follow-on programmer is a major factor in the achievement of beauty. An example: Someone unfamiliar with matrix math won’t perceive the beauty of solving simultaneous quadratic equations with code. I initially studied matrices in high school and again while getting an engineering degree but they didn’t make sense and even seemed a bit pointless. In graduate school I finally had someone explain it properly (or perhaps I had cleared up some underlying confusion) and was stunned by the simplicity and beauty of matrices.
The final analysis: You know where on the scale you and your code are by how pleasurable it is to create the code or work with it afterward.
It seems that the Beauty statement is largely aspirational, particularly when a deadline looms, but most programmers who code as a hobby have experienced elegance and beauty in coding. Sometimes the experience is best described as ecstasy. Taking a slightly different tack on it: Simplicity is genius (git is an example) and benevolent demonstrations of genius are extremely pleasurable and therefore almost always beautiful.
Speaking of git, that’s also an excellent example of complexity versus complication.
Closing thought: Evidently the pyZen principia would act as koen by encouraging the reader to more deeply consider the meanings of the words it contains. I find most of them to express fundamentals that I’ve arrived at over the many decades. (The decades since my dad brought home a hot-rod Tandy TRS-80 with an external 128K memory expansion unit. The memory expansion “appliance” was a good bit larger than a modern laptop.) For some time now, all of my protégés receive an orientation on complex versus complicated and the “junk food” of shortcuts and clever solutions–that usually create problems later–versus the genius and beauty of complete and well-considered solutions.