Lambda the Ultimate

First glance at the paper, it looks like a satire or some kind of joke (yikes, my first read of ercatons was something naughty).

On closer inspection, it looks like they are serious, they are just coming from the buzzword heavy segment of industry. From what I can tell, this really isn't a language, but some kind of library that they've put together according to some borrowed metaphors that center around a "thing," if you can get any more vague than a thing...

I wonder what it means that 'ercatons' is 'snotacre' backwards...

The Ercato Manifesto of Thing-Oriented Programming:

1. The exception is the rule.
2. Our world is rich and complex rather than well-structured and simple.
3. Software must cover irregular, changing patterns rather than regular patterns.
4. A software system is an organic being rather than a set of mathematical algorithms.
5. Software components are an integral part of our rich world rather than entities at some meta level.
6. Software engineering evolves from small to large rather than from concrete to abstract.

While the first three points are widely accepted within the OO community, the latter three points may be what constitutes the essence of the emerging TP model.

They motivate this manifesto with anecdote of a construction company fitting 90% of a yard with regular factory tiles then using a saw to cut the remaining elements to fit the edges and corners. They conclude: "In the real world, we use square tiles and cut to fit. In the software world, we use tile factories which must be able to produce tiles of all shapes we analyzed beforehand to be required."

I tend to disfavor software designs based upon "real-world entities".

My own manifesto would be more along the lines of:

Objects and object identity don't exist in the real world - they're illusions we fool humans use to bundle spatial-temporal properties in our heads, and thus belong to a world-view rather than to the world itself. Software exists to support our interests and serve our goals. In large software systems, we must support diverse interests, diverse goals, and diverse world-views - all of which change over time. For diverse world-views to coexist, we must not model worlds by use of objects in software. Therefore, the only elements that should have 'identity' within software systems are representations of our interests and goals, in order that we can coordinate and maintain them over time.

I would say that multi-agent systems are a closer fit into my manifesto: Individual agents represent user and business interests, in addition to the sensors and end-effectors (and foreign services) from outside the software. Coordination between agents - protocols, maintenance of relationships, communication - is the basis for serving our goals.

Unfortunately, multi-agent systems by themselves don't support diverse world-views: you would be forced to create an intermediate 'agent' to represent a new view of the world, which would be a direct violation of my manifesto (that only the elements representing our interests and goals should have identity).

But consider: to usefully 'type' agents, we would do so in terms of their social-coordination protocols: grammars and handshakes, for example. Safety analysis would then ensure agents are well coordinated. These coordination types are not like 'objects' - it does not make sense to associate code directly with a coordination type: any such code is inherently distributed between the agents involved. But, supposing we wish to associate code with the relationships between components, there is a way to do so: we describe transformations in relationships, and associate code with those transformations. For example, we could easily write a function that adapts one handshake protocol to another.

Examples of 'protocol transformation' approaches already exist in such forms monad transforms, arrows, and reactive dataflow programming. Usefully, these transformations can also support flexible 'world-views', i.e. by transforming sensor input and effector output, treating one agent as many or many agents as one.

So one possible configuration my manifesto favors is a multi-agent system layered with a pure (stateless, identity-free) relationship-transform model.

My own realization of this is reactive demand programming (RDP) which uses a bi-directional reactive dataflow programming to transform relationships between agents - sort of a bi-directional functional reactive programming (FRP). All stable identities belong to agents representing user or business interests, whereas volatile identities are introduced for sensors, effectors, FFI capabilities.

Anyhow, OOP and TP do all this bass ackwards. They, by nature, give identity to a world-view and represent 'interests' only implicitly in the information and control flow between models. Interests and goals cannot be adjusted in OO without shotgun surgery. These are fundamentally ill-conceived paradigms because they confuse a world-view for a world and misrepresent the purpose of software.

Well, yes, I surely agree with that,

Therefore, the only elements that should have 'identity' within software systems are representations of our interests and goals, in order that we can coordinate and maintain them over time

and I'd just add:

if we'd still have to try to (grossly) represent, in software, abstract entities coming out of any of our "world views" (in the most commonly given sense by, say, OO, UML, or etc) those:

1. should be kept within the bounds of a fairly small minority (in number and extent of the software artifacts), instead of receiving the treatment of our design decision focus to make them a clumsily and artificially large majority — which, by the way, not only doesn't make sense anymore for at least a decade now, IMHO, but also still doesn't work in the large, because either: we just fail building useful tools out of them that way, or: when we do build them with our sweat and blood... they just don't scale — and yes, certainly for the reasons you mentioned: "[...]they're illusions we fool humans use to bundle spatial-temporal properties in our heads, and thus belong to a world-view rather than to the world itself".

2. instead, they should much better be replaced, every time our invention or innovation/consolidation capabilities allow (over the legacy and/or out of PLT), with software entities and constructions which focus only, faithfully on what really matters and that actually belongs to the correct, because relevant, ontology — (loud and low voice) "heh, software mind you!" — and that is, if one wants to break it down to a core, say, of only two "things", that'd be for example:

a) temporary or permanent serializations of computers' computation results, intermediary or definitive artifacts, be they thoroughly standardized or not, etc, you name it (wait... these exist and have a name already... byte streams and files!) and

b) composable Turing machine computations (wait... these exist and have a name already... programs in Turing-complete languages over hardware!)

There, the challenge is I think for us to be able to refocus, and actually succeed to some extent, on improving the scalability properties of software entities, first, before even attempting to have them serve our purposes and goals as we run them on tangible computers belonging to the same real-world as ours.

So, speaking of which, if one really insists to look for something more probably worth of the name of a "paradigm shift", then yes, I suppose the kind of proposals to consider is much more likely to be shaped after a reflection about how computation is made, precisely, like, e.g.:

* with the FRP you advocate,

* or by changing one's glasses (where I wrote about reifying "intent" and "purpose" in languages, btw — pretty close to your idea of not losing sight of "our interests and goals" as you've put it, I suppose...) thru which one looks at the nature of our ever-evolving languages to be involved and composed with each other in 2) above,

* or etc... (<insert your favorite out-of-box-thinking seed here> and don't forget to water regularly :)

In the J2EE context I found this quote from the slides linked above to be the most informative:

But why is the ercato programming model that powerful? Because it exactly starts from the simple idea we mentioned above: treat every XML document as being an object (and call it an ercaton). Inheritance, polymorphism, encapsulation, persistence, methods, appearance etc. may all be expressed at the declarative level of XML. This includes some properties of real-world objects which software objects usually do not posses. Additionally, the full procedural power of Java and J2EE is made available as well.

And the halls echoed with the cheers of J2EE developers. Because that's what they really need; *another* xml configuration file. Yes, that was sarcasm.