This resonates deeply with me (and my research project). 1. Glue code and boilerplate waste Yes, yes and yes! Glue code is the dark matter of software [1]

This resonates deeply with me (and my research project). 1. Glue code and boilerplate waste Yes, yes and yes! Glue code is the dark matter of software [1] My hypothesis is that the reason we have to write so much glue code, and that it's always sufficiently different is that we don't have the right architectural abstractions. Specifically, our programming languages only support (essentially) procedural abstraction (procedures, functions, methods). With Objective-S [2][3], I've been introducing language support for other architectural styles. It's been a slog, but recently things are starting to really click together, particularly the combination of "stores and streams" is very powerful and eliminates tons of boilerplate, often reducing it to the "connection operator" → Which not only happens to be very brief, it's also generic/polymorphic. 3. Why don't frameworks work? Also really very perceptive observations. Frameworks sort of work, but they tend to be limited by having to represent their domain in terms of procedural abstractions. 4. Non-textual code/modeling I don't think this is the problem. Modeling is a problem, but a large part of that is because the systems/models we need to build are non-procedural, and so our textual code can only be a meta-program or meta-system that then constructs the actual system. Which is not visible/present in the code we write, but only exists in the running system and in our heads. If we close that semantic gap, having that model expressed textually shouldn't be a huge problem. The problem is not the text, it's the wrong abstractions that our text expresses. 5. Testing Not sure the idea of generic testing is that useful, because the key to testing (for me) is its concreteness. That said we can reduce test friction a lot, I think. [4] 6. UI construction You don't need UI mockups and prototypes - you just program the real thing, because it's that simple. If the user doesn't like it, you can completely restructure it easily. Yes. I've seen a lot of mockup tools, and it always seemed obvious that writing the real UI should be just as easy (or easier). With NeXT's Interface Builder, we had a large part of that, but sadly Apple has had it languish so horribly that nowadays even imperative code is often preferable, and the fluent APIs such as SwiftUI or React, Flutter etc. seem vastly preferable, despite their deep flaws. [1] https://blog.metaobject.com/2021/06/glue-dark-matter-of-software.html https://blog.metaobject.com/2021/06/glue-dark-matter-of-soft... [2] http://objective.st http://objective.st [3] https://news.ycombinator.com/item?id=32444300 https://news.ycombinator.com/item?id=32444300 [4] https://blog.metaobject.com/2020/05/mpwtest-reducing-test-friction-by-going.html https://blog.metaobject.com/2020/05/mpwtest-reducing-test-fr...