Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Rise and Fall of CORBA (2006)

queue.acm.org

Post reply on HN
Print view View original

31–40 of 156 posts

Re: The Rise and Fall of CORBA (2006)

#31

Post by stickfigure »

brazzy wrote: post #9
lelanthran wrote: post #6

Earlier quoted context omitted.

> In my 25+ year career I haven't seen it in use anywhere. I only ever encountered it while getting my CS degree. Too bad you didn't join the company I left in the 90s. It was used in production. I learned about it in my CS degree too, and (because I was a fulltime dev at the time as well as a part time student) I went ahead and used it at work[1]. From what I remember of using it in production, the only difficulty I…

> Making a server call from the client was transparent. It looked like any other function call That is a very bad idea and one of the reasons this kind of thing rightfully died out. Because a server call isn't like any other function call. It has orders of magnitude higher latency, and additional failure modes that you actually have to take care of. It shouldn't look like any other function call.

> It shouldn't look like any other function call.

I'm sorry, This is the stupidest thing I see commonly repeated in public discourse about software.

Every single distributed application I've ever worked on in my 30-year career (including working for multiple companies you've heard of) wrapped remote calls in something that looks like a normal function call. It doesn't matter if your low-level RPC stub throws RemoteException or returns RemoteError, somewhere up the call stack someone has wrapped this into a simple method that looks like this:

    doSomethingUseful();
In real life, you make a call to a function and you live with the consequences. If you're lucky, the docs let you know the performance and failure characteristics. If not, you make some assumptions. When those assumptions are wrong, you spend some time debugging and profiling.

Adding a bunch of syntactic noise to the callsite doesn't help. The first thing any competent programmer will do is abstract your noise away in convenience methods. Because 99% of the time, it doesn't matter that your call is remote.

Take a look at your own codebase that makes client REST calls to some other service - you may hand-wire a bunch of http calls, but somewhere up the stack there's a function that hides the http mess. Everything below that function is accidental complexity.

Re: The Rise and Fall of CORBA (2006)

#32

Post by hinkley »

lelanthran wrote: post #3

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…

And here I am learning an Erlang language…

Re: The Rise and Fall of CORBA (2006)

#33

Post by jiggawatts »

stickfigure wrote: post #18
lelanthran wrote: post #3

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…

We've finally come full circle with gRPC, which is basically a simplified CORBA. I went through the whole cycle, and while I don't exactly miss CORBA, I do wonder why it took us so long to get back to that baseline of functionality.

A huge influx of “programmers” that knew only JavaScript and thought that HTTP is the only network protocol, that’s why.

But seriously, the root cause of the regression is the web and its associated limitations, quirks, and bad habits.

For example, many web developers started out with eval() and maybe JSON which they thought was simple because it is text based and can be interactively experimented with in the browser console. They could “get started quickly” and they were “moving too fast” to think about codegen tooling, protocol efficiency, typing, or security. Doesn’t matter, they hooked up the form, push it to prod!

It’s a cycle that happens over and over in IT, a variant of the eternal September.

Re: The Rise and Fall of CORBA (2006)

#35

Post by corba_v2 »

nabla9 wrote: post #26

Marc Andreessen was all about CORBA. James Gosling said that JVM (Java Virtual Machine) was more important than Java itself. Remember EJB. In the end it did not matter if the technology was good or bad. Microsoft effortlessly killed everything that was not theirs to control. Now we have n:th iteration, more simple with less ambition. WASM, HTTPS, REST, json...

don't forget frameworks like cadence and temporal :)

Re: The Rise and Fall of CORBA (2006)

#36

Post by hinkley »

tragomaskhalos wrote: post #12

The old adage: "the first rule of distributed objects: don't distribute your objects". DCOM and EJB also came unstuck by failing to observe this rule. It's impossible for young'uns to appreciate just how obsessed the software world was by 'objects', OO and the chimera of reusability in those days; I subscribed to 'Object' magazine, and still recall one article breathlessly predicting that in the future bespoke develo…

The J2EE 1.0 spec was so goddamned infuriating, owing to the fact it was introduced by the company who penned the 8 Fallacies of Distributed Computing. At least half of which it was obviously in violation of. I walked away from it. Or tried to. Every successful implementation violated the spec, because the spec was idiotic. So we were all doing “J2EE” and with each revision what they said we should do looked a bit more like what were were doing already. But by the time it was almost good it was captured by industry.

Then Rod Johnson lambasted it famously and then lived long enough to become J2Ee.

I still have his book here somewhere. I keep meaning to sit down with it and the Spring spec and see how badly the abyss stared into him.

Re: The Rise and Fall of CORBA (2006)

#37

Post by galkk »

tragomaskhalos wrote: post #12

The old adage: "the first rule of distributed objects: don't distribute your objects". DCOM and EJB also came unstuck by failing to observe this rule. It's impossible for young'uns to appreciate just how obsessed the software world was by 'objects', OO and the chimera of reusability in those days; I subscribed to 'Object' magazine, and still recall one article breathlessly predicting that in the future bespoke develo…

It was truly insane. I still remember seeing in my book example of container that could host excel inside of my program and save files etc.

https://en.wikipedia.org/wiki/Object_Linking_and_Embedding

I often think about many things that were explored in that time as Birds of paradise. The desktop as it was seen then was mostly solved, and new challenges of internet didn't yet materialized - many engineers need to do something. So they started to do very weird things

Re: The Rise and Fall of CORBA (2006)

#38

Post by sirtaj »

inferiorhuman wrote: post #20
js2 wrote: 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 tried and discarded CORBA in KOM/KParts well before GNOME got around to putting it in production. DCOP was a response to CORBA's complexity and fragility, and was almost "reinvented" in the form of DBUS.

Re: The Rise and Fall of CORBA (2006)

#39

Post by nologic01 »

I am pretty sure ten years from now people will be rolling their eyes on the acronyms of today: so-called REST, json schema and whatnot.

Lets face it, the problem that people try to solve (frictionless, large scale exchange of complex information between computing devices) and the conditions in which they try to solve it (as part of a few dominating corporations with random business models) are making for a very difficult challenge.

There is pressure to find workable solutions as the benefits are tremendus but so far it has not worked.

Re: The Rise and Fall of CORBA (2006)

#40

Post by bhaak »

I have some sketchy memories for which I have trouble filling in the blanks about an internship at a bank where I wrote a Java POC for getting data from one of the other departments.

It must have been in 1998 or in 1999 and I was brought in to solve a specific problem, only to find out that the higher ups had no idea that there was a problem and there was no documentation. Eventually I wrote a specification and that POC.

While doing that, I learned that the Java CORBA implementation they used at that time was not yet able to talk to the C++ CORBA implementation from the same software producer. How is that even possible? That's the whole raison d'être of CORBA.

As I said I can't get the details together. I'm pretty sure the hardware was Sun but I'm not sure who made the CORBA implementations. Possibly IBM? It would fit the landscape.

Post reply on HN