yet another paradigm

The first part of the abstract from a paper on the matter:

Thing-oriented programming (TP) is an emerging programming model which
overcomes some of the limitations of current practice in software development in general and
of object-oriented programming (OOP) in particular. Ercatons provide an implementation of
the model. TP does not describe a new programming language. The so-called “ercato virtual
machine” or “ercato engine” implements the ideas discussed and has been used to validate the
concepts described here.

That quote is pretty bland. I'm re/reading the paper and on the whole it reminds me of things like actors, and templates (in the html, not c++, sense), and maybe 'rolons' (?!).

From some slides on the java implementation:

ercatoJ uses bright ideas from several ancestors.
It uses XML to represent and persist rich structures, XSLT may express business logic and views.
It uses SQL as an accelerator for unsacrificed performance. Even inner and outer joins are available. However, SQL as a language is considered deprecated.
It uses and complements J2EE, e.g., transactions, sessions, authentication.
It uses an extended Unix file system semantics (incl. x- and s-bits) to express rôle-based permissions by instance, not by class. As a consequence, protection ensures that two different rôles may see different data from the same SQL query.
It uses Java and its object-oriented model. Business logic may be expressed in arbitrary Java.
It uses the Unix philosophy of many small building blocks which cooperate towards a whole which is more than the sum of its parts. ercatons are the parts, the J2EE application is the whole. The concept of several users conributing parts in a secure manner is implemented, too.
It uses the concept of prototype-based languages such as ‘Self’ where objects are created without a class.

Comment viewing options

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

First glance at the paper,

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 confess I looked for a April 1st somewhere, too

I confess I looked for a April 1st somewhere, too.

First glance at the paper, it looks like a satire or some kind of joke[...]On closer inspection, it looks like they are serious

Yes, they seem to be. And indeed I wouldn't call this a language (since they borrow from/basically stack up a quite impressive bunch of them, actually — Java, XML, XSLT, the Unix shell, ... <insert more at will here>), and even much less a paradigm:

maybe it's just me, but I really perceived it, rather, as an adhoc accumulation ("pudding"?) of, yes, more-or-less buzzwordy names and jargon that were maybe still en vogue in 2003/2004 for some people.

Anyway, six years after this so-called "Thing-oriented Programming" ideas' inception, and given the pretty strong statement of expectations given in the paper's abstract —

well, just quoting:

"[...]TP should then be able to provide the means to make
software development achieve what other engineering disciplines have achieved a long time
ago: that projects are deterministic (completed in time and effort scales sub-linearly with size)[...]

(if these are not high expectations in the single solution — or "Thing" they're thinking of — they propose to this problem space, I don't know what is!)

— if this "paradigm" was as powerful as what's announced, I'd expect them to have already come up with something (somewhere... links, someone?) of a tooling much more significant than what seems to be still at the stage of very early prototypes/PoCs, no?

Maybe that works great, but, er... where can one find online a hyper-cool, blindingly demonstrative demo, then?

(And no, I don't even mean to throw sarcasm or be condescending... but just: really, where seriously?)

ercatons : snotacre

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

Dlihc Renni

It means you are in very good contact with your inner child.

Ercato Manifesto and an Anti-manifesto

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

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

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.