I've been thinking on similar lines for a while. It seems like the number one thing it comes down to is that more deep thought is required for a number of these

I've been thinking on similar lines for a while. It seems like the number one thing it comes down to is that more deep thought is required for a number of these 'obviously better' techniques (I think they generally come down to being more declarative than imperative, saying how the results should look instead of describing how to get them). So lots of people are inclined to say things like, "then don't be lazy, do the work and think deeply"—but for one thing, 'deep thought' should be considered as a conserved resource and you have to choose what to spend it on (it's not automatically better to always spend it); and for another, I think the actual depth required for perhaps the majority of real-life problem domains is impractical, or perhaps sometimes the domain is even fundamentally not amenable to an elegant mathematical solution. So you have to contort the 'better' language to do inelegant things it's not really suited for anyway. I think the constraints on the 'triples_from' structure from the article is a bit misleading and makes a good example of what I'm talking about. It looks super simple, but if you note how this constraint across tf.item as tp all tp.item.source = tf.cursor_index end is actually working, it's not so much that the language gives a particularly elegant/powerful means of specifying these constraints as it is that 'triples_from' was structured in such a way that it would be easy to specify the constraint. My feeling is that trying to do this for real-life things would rarely ever be so neat. If the domain you're modeling has mathematical elegance to begin with—absolutely, do the deep thought and uncover the invariants. But if it doesn't, then you'd be 'programming wrong' by trying to use such techniques. The alternative I've been thinking about is just developing far more powerful/pervasive visualization tools so that you can write relatively mindless imperative code and just see where things are going wrong more easily. (consider the author's example of multiple data structures which must be kept in sync, but it's hard to tell when they get out of sync). Not trying to self-promote too much but you can follow my profile to the project if you're curious.