Live data from Hacker News

The Rise and Fall of CORBA (2006)

queue.acm.org

151–156 of 156 posts

Re: The Rise and Fall of CORBA (2006)

#151
post #2

The Wikipedia page says the most recent version of the standard is 3.4, published in 2021: https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A... In my 25+ year career I haven't seen it in use anywhere. I only ever encountered it while getting my CS degree.

Gnome used CORBA in the form of Bonobo and KDE reinvented the wheel with DCOP.

KDE originally used CORBA, but dropped it for KDE 2.0 when it was found to be heavy for local use in a DE.

https://www.linuxjournal.com/magazine/kdemdashthe-next-gener...

Re: The Rise and Fall of CORBA (2006)

#152

I remember how CORBA was all going to be the future. I wrote dozens of programs in C++ and Python using IDL. Funny, though, that we now find ourselves doing the exact same thing but it is "an API", has no type-checking, no error handling, requires more work, is limited to particular languages and is slower. Distributed objects were ahead of their time by maybe 15 years. Now we're stuck in async API-over-JSON hell for…

On the one hand the failure is legit, success foiled by rampant vendorization & byzantine inscrutable tooling pumping out forsaken impossible to introspect generated code.

But also CORBA was maybe as far as I can tell the first programming tech to ever get canceled. That everyone went Vampire Castle on & decided collectively to crap on & lambast. What before CORBA had such a loyal hate club, was so bandwagon to disdain? It was a boogeyman tale, one we collectively whispered ourselves away from, even though most people had little sense.

It'd be interesting to try to dig up some of the old GNOME 2 efforts that did have Corba stuff in various apps & systems. Try to find some authors to say how they felt at the time. Go look at the code & see how it was.

The idea of having objects that can connect acriss boundaries is indeed super interesting. I love webdev & it's great, but we have noticeably not gotten very far in 20 years. GraphQL was one would be normalizing upstart, and ideas like resolvers have some merit, but it's still chiefly a state transfer system (which also has real time. Subscribe mode). It's still not really a well paved way to connect systems.

Even if we don't have distributed objects, just expanding the range of normative things we can do with resources on the web feels like it hasn't greatly expanded. Our efforts are still artisinal, handcraft by each team. We need to start figuring out, even if not distributed objects per se, how to grow the capabilities of online/connected systems pervasively.

Re: The Rise and Fall of CORBA (2006)

#153

Earlier quoted context omitted.

Surely anything over a network is async? Unless you block on every call, which REST doesn't stop you doing.

> Surely anything over a network is async? Yes, but not everything should be . Synchronous RPC works better than async RPC with fewer failure points simply because there's only single line that is the point of call. Async RPC quickly devolves into a hairy mess. > Unless you block on every call, which REST doesn't stop you doing. But the current standards do. If you want `fetch()` to be synchronous, you have to wrap i…

If you want fetch to be synchronous, why not just write await in front of it?

RPC is the same, except you can't opt for async when you want it.

Re: The Rise and Fall of CORBA (2006)

#154

Earlier quoted context omitted.

> The promise is at the remote end. What? The promise is local, so what do you mean "the promise is at the remote end?" > Promise resolution is idempotent, No. It is only run once (whether resolve or success), that does not mean it's idempotent. Just like exceptions for synchronous code, or error returns.

Nothing personal, but people not aware of where these concepts came from in distributed computing history is annoying, and I don't like repeating myself: http://erights.org/elib/distrib/captp/index.html

Regardless of where promises come from, the fact is that they are locally resolved, not remotely resolved.

Using promises in JavaScript is a hack around the fact that the platform has some pretty large deficiencies.

Re: The Rise and Fall of CORBA (2006)

#155
post #129
post #2

The Wikipedia page says the most recent version of the standard is 3.4, published in 2021: https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A... In my 25+ year career I haven't seen it in use anywhere. I only ever encountered it while getting my CS degree.

It was used by Nokia Networks for all their HP-UX based infrastructure, in a mix of C++ and Perl. Eventually it was replaced by a new server infrastructure based on Java EE and Red-Hat Linux.

CORBA itself is still used there for that purpose.

Re: The Rise and Fall of CORBA (2006)

#156

Earlier quoted context omitted.

Nothing personal, but people not aware of where these concepts came from in distributed computing history is annoying, and I don't like repeating myself: http://erights.org/elib/distrib/captp/index.html

Regardless of where promises come from, the fact is that they are locally resolved, not remotely resolved. Using promises in JavaScript is a hack around the fact that the platform has some pretty large deficiencies.

> Regardless of where promises come from, the fact is that they are locally resolved, not remotely resolved.

Idempotent operations are implicit promises at the protocol level. We're talking about distributed systems here where abstractions and semantics cross machine boundaries, so your local-only focus is not valid. I suggest reading up on the E language via the link I provided.

> Using promises in JavaScript is a hack around the fact that the platform has some pretty large deficiencies.

A single threaded event loop is not necessarily a deficiency.

Post reply on HN