Lambda the Ultimate

> They still stay in OO paradigm,

That is not true. Software architecture generalises from other paradigms to components (state and computation) and connectors (communication). If you check the software architecture literature, you will see that this is all-encompassing.

Current "general purpose" programming languages are anything but general purpose, they are DSLs for the domain of algorithms. See also: ALGOL.

> but allow additional mechanisms

Again, no. The mechanisms are not "additional", as in "bolted on". Instead, once you generalise to components and connectors, you can specialise to lots of different architectural styles by selecting and adapting the components and connectors you need.

> of lower abstraction tier,

Whatever "lower abstraction tier" actually means. In general you want the least abstract mechanism that will do the job. See the Rule of Least Power and the Principle of Least Expressiveness.

Making the language flexible enough to allow different architectural styles means that you can express yourself directly, rather than having to wrap them in adapters to fit the architectural style of your language, which is often arduous enough that instead an inappropriate architectural style is chosen.

> so there is no abstraction tier advancement.

While I find the abstraction tier model somewhat dubious, Objective-S actually fits right in and provides a significant advancement. The Black Box tier is one that is typically occupied by black box frameworks. Black box frameworks tend to have a "grammar" for how those black box objects can be composed, and so the framework is equivalent to a DSL, and is in fact, sometimes accompanied by such a DSL, because configuring correct compositions into systems is otherwise very arduous.

The DSLs, however, come with their own problems, in that you need new syntax, semantics, tooling etc. which is significant effort. In addition, if every framework comes with its own DSL, that leads to a proliferation of incompatible DSLs that have to somehow integrate and communicate with each other and the base language. A mess (talked about at length in the paper and the Nierstrasz paper referenced).

What's more these DSLs are usually quite similar, so you have significant duplication. Objective-S is a generic "DSL language for black box frameworks", and it shows this by treating the language implementation itself as a framework for which it provides a thin linguistic wrapper. Naked objects but for the linguistic UI rather than the graphical UI.

> For UI they want to configure streams.

No. The UI connection shown in the paper is dataflow constraints. These have some similarities to streams but are not the same. Furthermore, it is not what Objective-S "wants", but simply a demonstration of how the call/return architectural style (or Algorithm DSL) breaks down when dealing with something that is not an algorithm, such the communication patterns between GUI and model.

> But this is lower-level abstraction than reactive UI (react, angular).

No. "Reactive UI" is an attempt to pretend that a UI is a pure function of the model. This isn't actually true, but convenient because functions/procedures are the only thing we can actually write down directly in our Algorithm-DSLs. Everything else requires indirection. Alas, the fiction that it is a function breaks down quickly, hence the amazing churn in those frameworks.

> Configuring connections in UI much more complex than reactive approach

That turns out not to be the case. So-called "Reactive" UIs are ok-ish for trivial UIs, they break down quickly due to the inherent contradictions of the approach. Connecting things up is trivial with the right abstractions and actually models what is happening, rather than pretending that things are completely different from what they are.

> these mechanisms do not scale well on the scale of cognitive complexity.

The opposite is true. Software architecture is how you describe the largest grain of your large systems. Objective-S scales this down so it also works for programming-in-the-small, and in fact eliminates the distinction.

> higher abstraction tiers (dependency injection, ...)

Dependency injection is...well once you get beyond the fact that it's just adding parameters to methods and consider what it is trying to achieve...just an ad-hoc, not-entirely thought-through variant of system definition in software architecture.

> (reactive systems)

Once again, pretending that UIs are functions is not a "higher abstraction tier", no matter what definition of abstraction tiers you use. In the hierarchy of programming paradigms as presented in Concepts, Techniques, and Models of Computer Programming, functional programming is a lower-level abstraction than, for example OO. And that is good, because you want the lowest level you can get away with that leads to a natural program.

And so the reactive frameworks are to be applauded for trying to get by with a lower-level of abstraction, this is a good thing if it actually works. However, I don't think it has worked, the resulting programs are not natural except for the simplest examples.