#11 "balance" is laughable based on the preceding ten.
Some things missing include:
* properties (glaringly so)
* meta classes
* dynamic code generation / data as code
* emulating various types and the rest of __methods__
* know thy standard lib
* distribution setup tools, et al
* documentation epydoc, sphinx, docutils, et al
* profiling and performance
"... Python class. Claim it could be "better" implemented as a dictionary plus some functions"
Um, that is almost all a Python Class is.
The subject was getting to Guru "level". If you don't understand those (and when to use them, i.e. almost never) then you are not a Python Guru.
"... Programming commentary. Protagonist proudly advocates against something he feels he's moved far beyond in favour of a solution which is exactly that thing in more obtuse terms."
Um, that is almost all a humorous instance of dramatic irony is.
It seems to me that we're at a place with software where we were with, say, civil engineering in roughly 2000 BC or something. This date is horribly wrong, but what I mean is that we're building basic structures, and we're okay at it, but when we try to do anything larger, we're failing.
At some point, we'll be able to make larger buildings, bridges, and roads... but we're not there yet. It seems like the best path forward is to follow is to do exactly what early engineers did: an apprenticeship model. Yes, software is based in math, but so are bridges. We've got a better grip on the math now, and it does help us build modern bridges, but at first, we had to schlep along.
I'm starting to ramble slightly, so I'll cut this off. And as I said, this is only a half-baked thought... but I think this 'apprentice -> journeyman -> master' path is an intriguing way to move forward with software.
It's just that in most cases, no-one cares enough to pay what it costs. You either have to be extremely high profile (e.g. the Space Shuttle) or doing huge volume (think of a CPU as simply a Verilog program) to make it worthwhile. Would you pay 10x as much for a word processor or web browser that never, ever crashed? Would you pay 100x?
And you're right, it is incredibly expensive... but even in my example, that just moves us forward to the Roman Empire, or something. People know how to build an aquaduct, but only the most excessive society on the face of the planet can afford it.
Using mathematics (or say arithmetic in particular) may be closer to engineering. But we have no reliable and routine method for finding interesting statements and their proofs.
(note: not that I think normal construction is comparable to software development. In a nutshell any computer system has an orders of magnitude more 'moving parts' (even if they only exist in the abstract) than any normal object or machine. Most programs are built on layer upon layer of supporting frameworks right down to the hardware. When you're at the top, things are inherently unstable)
Also, the survival rates of older buildings has to do with a zillion different factors -- from changes in taste (and ideology) to fate (wars and natural disasters) to the simple economic happenstance of the particular plot of land these structures were located on.
That is, the vast majority of buildings are torn down deliberately, to replace them with something bigger or different; to purge a neighborhood of undesirable residents; or to purge collective memory of an unfashionable sense of design, or of place -- rather than because they run into disrepair (or get burned down).
That said, I'm off to the library to borrow a copy of Real World Haskell.
For me at least, the balance lies more in the use of state (easy in python) or the cost of abstraction (no inling and TCO).
(I know what he's talking about with Haskell-in-Python, though. I did that. Briefly.)
We learn new tricks just to make our code simpler and prettier. As a side effect, we code faster and with less bugs.