Don’t create generators with side effects:
import contextlib @contextlib.contextmanager def my_nice_context(): try:
Interfaces naturally emerge as software gets broken down into parts communicating with one another. The larger and more deliberate structures emerge from a deliberate attempt to organize the development process itself. [fn:Liskov2008] Structure often emerge directly from division of labor: as teams take on independent tasks, interfaces are established betweeen domains they become responsible for. (Conway’s Law)
Software developers are responsible for systems built out of very small atoms while ultimately performing tasks for their users of a much greater magnitude. Dijkstra showed this by computing the ratio between grains of time at the lowest and largest atoms of the system (from say, CPU instructions to a human interaction with the system) The span was already quite large by Dijkstra’s time, of about 10^9. Today this ratio would be at least above 10^12 (see grain ratios)
This large span has to be manage
Note: a lot of programmers talk about UI without mentionning the user even once, as if it was entirely a programming problem. I wonder what we’re leaving off the table when we do that.
Sophistication in programming languages has diminishing returns.
I treat programming language features like I treat drugs. They come with side-effects, which I want to be aware off before even thinking of putting them into use. And if in doubt, I’d rather not use them.
For an alternative take, legions of programmers write online about the features they want to have in their language. Is it based on actual experience rather than wishful thinking? Is it based on their own introspection of what’s producing defects or harming progress?
I find that certain problems attract the creation of many solutions. We are overwhelmed with slightly similar yet incompatible and potentially incomplete solutions.
Why is that so? Which domains show this pattern?
My hypothesis is that these problems seem easy to approach from one idiosyncratic perspective while at the same time being hard to complete. Therefore no-one’s satisfied or able to judge existing solutions and end up creating yet another one.
In certain domains, incumbent solutions also may appear bloated, and therefore it’s easy to think one can do better, because the 50% solution appears leaner. Problem is, the remaining 50% is where the necessary risk mitigation, adaptation is. An example of that is the appearance of poorly made (but lean) databases in the age of NoSQL, which claimed to be leaner just because they did not discover yet all the things their historical competitors had discovered they had to do.
|// Depth first traversal algorithm.|
|// (credit to Alexander Stepanov in Elements Of Programming)|
|// One of the benefits is that the visitor can implement pre or post traversal algorithms, and combine them in one single piece.|
|// @generic in T, the node value type|
|func traverse_children_recursively(tree_root: T*, step_visitor: func(step: TraversalStep, node: T*))|