Comment by jamesblonde | Hacker News Reader

Comment by jamesblonde | Hacker News Reader

Parent Full thread

This was the paper that was the inspiration for my supervisor for my PhD topic at the end of the 1990s. That whole research direction - reflective programming languages - pretty much died on the evolutionary vine. Like AI at the time, the area was looking for use-cases.

One of the use cases for metaobject protocols was to make distributed objects look like normal objects by declaring them as such. You could write C++ classes and then annotate them (in the metadata layer) as distributed, and suddenly you had distribution transparency. Except, distribution transparency turned out not to be a good thing as it is a leaky abstraction. See the 10 fallacies of distributed systems for why this is so. EJB also killed the use case, as it was actually a solution for it. It did build on some principles from this research - enable pre- and post-method invocations to be pushed to application deployment time. EJB enabled methods to be "transactional" or "filtered" and so on. Aspect-oriented programming was a rebranding of metaobject protocols that also didn't have huge impact. As for me, i finished my PhD in the field and moved on to other research.

The idea did take off big-time, just not at the level of C++ compilers and in a more modest way than envisioned. Java and C# both provided reflection interfaces to implement many of the motivating examples for meta-object protocols. Qt (user interface) and Unreal Engine have elaborate semi-automated systems for gathering metadata about C++ objects in order to manipulate them reflectively.

The architects of these systems definitely took inspiration from these meta-object protocol papers and related LISP and Smalltalk efforts. Nobody quite took it all the way, and I suspect that's because the boundaries between compile-time reflection, use site checked macro programming, and declaration site checked type level programming are quite hard to pin down in such a general system.

And SOM, COM and CORBA.

Unfortunately to this day, COM tooling remains quite clunky, despite how much WinDev pushes it since Windows Vista as main API ABI.

Unreal Engine actually applied the idea to implement distributed objects transparently. It is decent enough to power most real time multi-player gaming scenarios.

There was also Adpative Programming by Karl Lieberherr at Northeastern University (https://www2.ccs.neu.edu/research/demeter/). He had both a C++ and a Java compiler to implement what he called traversals, features that would span many classes but you could implement in one traversal file. His tools were so powerful that in one of his classes I was able to add synchronization primitives to Java as a class project.

I did like Herb Sutter's relatively recent push for metaclasses though. He pointed out that people are already doing similar things in their codebases, just manually with text level preprocessors like QT uses.

https://herbsutter.com/2017/07/26/metaclasses-thoughts-on-ge...

What’s “distributed” mean here?

There are two meanings we meant: other computers, and other programs.

In 1995 most computers had a single CPU core, running at around 100mhz. Today each core is 10-30x higher frequency (though as always you cannot compare frequency directly it is still a sign of relative speed), and almost all computers have at least 4 cores. In 1995 you were doing good to get 8 MB of RAM, now we are looking at around 8GB. One way around the inherent slowness of computers is another one on the network to run some programs.

In 1995 there were cool demonstrations where a program could plugin others for some functions. So your word processor wouldn't have a spellcheck, it would just use a third party spell check of your choice. (we sort of do that with shared libraries, but the interface is different) Some of what was done then was better than anything we have today (but see the other replies, making distributed work transparently is not easy and so if we had made it work people would probably hate how often it failed)

How would that relate to CORBA and friends?

(I know I could google all this. It’s more fun to chat about it.)

(It was not fun times. It was "hey everyone, all our problems will be solved by adopting XXX" which inevitably introduced a new set of problems which could be solved by only adopting half of XXX and all of YYY, repeat. Now that I think about it, I don't think anything has really changed, except that now the XXX has mutated into a XYZZY, we call it technical debt and then we retire to leave it for the next lot.)

CORBA is a specification to make objects interact across processes and computers. Its main drawback is the complexity, as it has to adjust to the several use cases (local and remote processes/computers) and provide interfaces to all different languages that might want to use objects, all this in a transparent way. Having CORBA specifications working reliably was a big problem to solve, and it was never 100% done, as new problems and specifications would pop up as needed. Finally, web technology solved most (but not all) of these problems by skipping programming language level objects and moving to higher level interaction through HTML/XML interfaces.

All true, but the real differentiator that enabled SOAP to kill CORBA was the appearance of NATs and firewalls. CORBA assumed objects could talk directly via IP. But NATs appeared at the end of the 1990s when IP addresses were running out, suddenly CORBA wouldn't work in corporate environments. But SOAP could be made to work with http proxies. SOAP, of course, was superceded by REST, because it was too complex and REST was perceived as much simpler.

Well, I guess that with more specifications thrown in the mix this could be covered too. The problem, as I mentioned, is the incredible complexity of the whole thing. Web technology solves these issues in simpler ways that don't involve messing up with remote objects at the programming level.

CORBA was another attempt of much the same thing there are dozens at the time. Of course each had slightly different goals and variations, so you can't always compare directly. Some were more to one direction or the other.

Reply on news.ycombinator.com