I would also be skeptical of an "all-dancing" connector.

Fortunately, this isn't one of those.

The concept of "connector" is not something I came up with, it's a core concept of the field of software architecture and has been for at least 30 years.

This is the paper that the title riffs off:

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

https://insights.sei.cmu.edu/library/procedure-calls-are-the...

So if you're going to argue that the concept of connector is ill-founded, well good luck with that.

The taxonomy is also not mine:

Towards a taxonomy of software connectors

https://dl.acm.org/doi/10.1145/337180.337201

282 citations so far, so probably not total BS. So basically these connectors exist in real software, and though the list may not be complete, it is pretty comprehensive. And there's the taxonomy.

My key insight is that "first class" is the wrong layer for connectors. They belong at the "meta class layer", basically in the language.

Which is where they actually have been all along. Procedure call is a connector (type), and general-purpose languages tend to have support for some form of procedure call. Data access is also a connector (type), and most languages have some way to access data.

But they tend to be monomorphic, to have support for exactly one way of accessing data, for exactly one kind of procedure call. If you want something different: good luck!

Another option would be what you describe, some really general mechanism, but with that approach you get into the problem you describe of "one size fits all" connectors: they just don't work.

So instead you define a metaobject protocol for each of the various connector types and allow many different implementations of the basic connector types that were identified by the taxonomists.

At the same time, architectural concepts really help out metaprogramming:

"I would suggest that more progress could be made if the smart and talented Squeak list would think more about what the next step in metaprogramming should be -- how can we get great power, parsimony, AND security of meaning?"

https://lists.squeakfoundation.org/pipermail/squeak-dev/1998...

Things that implement one of the metaobject protocols can then be used (and sometimes defined) using a convenient and common syntax. So I don't just "loosen the definition" of a function call, though I do that as well, I also topple the dominant position of function calling. It's a lot looser than what you propose. Which makes it sometimes difficult to get your head around.

But then you get to model systems with any of the supported connectors (and that is open-ended) using appropriate linguistic tools.

If something is appropriately modeled as a dataflow system, you can conveniently express a dataflow system, without having the shoehorn that into the syntax and semantics of function calling.

If something is appropriately modeled as data access, you can conveniently express a data access system, without having the shoehorn that into the syntax and semantics of function calling.

You can combine these.

The common metaobject protocol means that any abstraction that you can make fit one of the provided protocols gets to participate, gets the convenient syntax.

Steve Sinowsky wrote: "Does developer convenience really trump correctness, scalability, performance, separation of concerns, extensibility, and accidental complexity?"

https://darkcoding.net/research/IEEE-Convenience_Over_Correc...

Turns out that in many if not most cases, it empirically does. How about we don't have to choose?

In addition, when you adhere to these metaobject protocols, you also get syntactic composability. The interfaces are compatible, so you can plug them together. It does not guarantee semantic compatibility, just like the fact that you can plug any Unix filters together does not guarantee that they do something useful together. But you can plug them together without additional glue code (just the pipe operator | )

> start building real programs and seeing how they do in the field.

Been there, done that, bought the T-Shirt. That's why this has been a very long time coming: you need the meta-abstraction, with which you build abstractions, with which you build actual frameworks/libraries/systems.

And you don't know what the right meta-abstraction is at the start.

This has been a LOT of work.