Morally kinda similar to ArchJava, apparently.

Objective-S is an architecture-oriented programming language based loosely on Smalltalk and Objective-C. It currently runs on macOS, iOS and Linux, the latter using GNUstep. By allowing general architectures, Objective-S is the first general purpose programming language. What we currently call general purpose languages are actually domain specific languages for the domain of algorithms. Objective-S includes an Objective-C compatible runtime model, but using a much simpler and consistent Smalltalk-based syntax. Unlike Smalltalk, Objective-S has syntax for defining classes and so can be file-based and is "vi-hackable".

Paper: Tyranny of call-return

Paper: Procedure Calls Are the Assembly Language of Software Interconnection: Connectors Deserve First-Class Status

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Some comments

From the point of view of abstraction tiers model:

1. They still stay in OO paradigm, but allow additional mechanisms of lower abstraction tier, so there is no abstraction tier advancement.

2. For UI they want to configure streams. But this is lower-level abstraction than reactive UI (react, angular). So, there is no advancement in usability either. Configuring connections in UI much more complex than reactive approach (reactive system of components). The reactive UI is on initial phases the tier 5 approach, but Objective-S is trying to do the best that it can in the tier 2 (flat patterns). Usability difference are quite large.

Doing the lower tier mechanism usable is useful, but these mechanisms do not scape well on the scale of cognitive complexity. So, they applicable only for organizing small isolated pieces of the code. The mechanism could be still useful as lower-level implementation approach, but why it is not a significant language advancement.

On other side they naturally feel pressure from OO complexity, but they are seeking solution on lower abstraction tiers, when the solution is actually on higher abstraction tiers (dependency injection, reactive systems, etc.). Lower abstraction tiers provide lower cognitive load for individual element, but they have higher total cost when number of elements grows (bad cognitive scaling).

The good experiment would have been is implementation of some complex UI with reactive UI approach and their framework. Email client or pet shop would work. Their example is too small to see cognitive complexity scaling problems.