Objective-S: architecture-oriented language based on Smalltalk and Objective-C

  id foo = [@"foo" cat:@"bar"];

  - (id)cat:(id)arg { return [self stringByAppendingString:arg]; }

ObjC is one of the most readable languages around. That's mostly because of the param:value syntax, which is much better than C-like syntax because you can see the parameter names. But the long method names aren't a problem once you have autocompletion. They also make it clearer what the best name for a method is - if you call something fmt() you start needing to make up equally clever short names for everything else, and it becomes less principled.

For algorithmic string building, I'm not sure how often you want + (aka appendString:), appendFormat: or componentsJoinedByString: are more flexible.

Just like Smalltalk does with, say collections: most languages have/had built-in support for one type of collection (or maybe two), typically arrays of a homogenous type. If you wanted to build your own collection, you could, but were limited with functional call syntax fora accessing that collection.

With Smalltalk, collections yourself create are on an equal footing with collections that are in the base library. And that's an idea that has slowly percolated through the PL community and to practice.

But not with architectural styles. Our mainstream programming languages typically support exactly one architectural style: call/return. That's the only one that allows abstraction. If you want a different one, you can build it, but you cannot express it. And that's a huge problem, as any non-default architectural style gets a huge expressiveness penalty.

Previous languages that support alternative architectural styles usually have exactly the problem you've described: they offer exactly one implementation of that architectural style baked into the language, and that's it (Go channels are an example). And if you need something even slightly different, you're back in implementing + expressing with call/return, because that's the only style that allows abstraction. Sigh.

With Objective-S, the idea is that you get to implement whatever you want in terms of architectural styles (connectors, components) and then get to surface it with syntax appropriate for architectural connection. And the implementation will usually also be call/return based, because that's what we currently have. Although I am starting to see places where I can actually implement a connector in terms of other connectors directly without mediating via procedure calls.

(The one-way dataflow connector |= can be built from a storage combinator and a notification mechanism, and these can be pluggable. Very neat, particularly because building dataflow constraints naturally was one of my goals and this exceeds that goal).

Of course there's a bit of a chicken/egg problem, in two variations: first, I must provide some "built-in" components and connectors that go outside the default set, otherwise the whole thing is useless. And there it turned out that the initial set (polymorphic write streams, storage combinators, dataflow constraints) turned out so useful and general that they sort of become "the thing", even though they aren't. The second, related chicken/egg problem is that both conceptually and from an implementation POV, we have to start somewhere concrete, because this is an abstraction mechanism that doesn't exist yet and thus nobody really has a clue how it should work. So things aren't as abstract/general yet as they should be.

Page http://objective.st/Language/:

* the "Object templates" sample code ends outside the code box. * Section "Messages": this whole sentence is basically a typo:

- expressions are handlde by message conneectors, and again like Smalltalk, Objective-S distinguishes three kinds of messaege... - Objective-S has two mechanisms for chaining muliple messages

What text editor is the author using? Virtually every editor nowadays supports spellchecking.