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

61–70 of 156 posts

Re: The Rise and Fall of CORBA (2006)

#61

Post by tragomaskhalos »

kazinator wrote: post #19
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…

There was also a thread obsession. However, luckily, 'Threads' magazine is about sewing. I had an issue on my desk.

Ah yes apartment threading and all that. Read so much about that stuff, but will go to my grave having never understood it!

Re: The Rise and Fall of CORBA (2006)

#62

Post by smackeyacky »

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…

DCOM was far more practical, mostly because the scope was smaller. I used very successfully with a trading system back in the nineties.

In the same institution, the corba guys just built themselved giant messes trying to unify 4 different languages and the kind of network dependency hell that only corba could allow.

DCOM was never cool, but it also wasn't as ambitious, so good systems got built with it.

Re: The Rise and Fall of CORBA (2006)

#63

Post by blowski »

tragomaskhalos wrote: post #60
blowski wrote: post #21

Earlier quoted context omitted.

> one article breathlessly predicting that in the future bespoke development would become bunk as folks would just buy e.g. an Aircraft object off the peg and plug it into their application Every time I consume a third-party’s REST API, I’m doing that, no? Albeit the article may have oversold the idea in the work ending there.

Well yes that's true, however that's in the spirit of a 3rd party providing a specific service to your program, whereas the object zealots intended objects in the sense of entities with identity being these off-the-peg consumables. Imagine if in a code review every time you declared a class to represent some feature you were challenged as to whether there wasn't some component you could shop for instead. The Aircraft…

What about when I install a library or use a framework? When I use Spring Boot, it's calling my code. I install libraries which dispatch events to which I subscribe and that come with pre-defined objects I pass around. I use SDKs to talk with REST APIs. I even use objects that persist their data in my database, and have their own migration files.

I'm being somewhat disingenuous asking this. I realise most of the code in any application will be bespoke, but I don't think we should deny that the vision you describe has become reality in part.

Re: The Rise and Fall of CORBA (2006)

#64

Post by eternityforest »

Animats wrote: post #27

We might see a comeback of something like CORBA. One of the things CORBA was supposed to do was to enable a mechanism to ask a server "How do I talk to you"? While that wasn't really used much, it has real potential for the LLM era. We need technologies where a client asks the server how to talk to it, then generates the appropriate requests automatically. For example, you should be able to ask anything with a shoppi…

I think negotiation can be a bad thing. Instead of just making a standard so a server can say "This server complies with the BuyCrap 2.0 protocol", and a way to discover this fact, people make up garbage like "This server has a method called AddToCart which takes a string and an integer in this range".

The introspection mostly is used to ask "do you have this feature I already know about from the spec that really should be a mandatory part of the profile".

It just becomes a way to have 850 variants and optional features instead of a true standard, meanwhile the discovery layer risks taking more effort than a one size fits all protocol that covers a use case would have.

Sometimes it's cool for development though, to get a detailed list of a servers capabilities, like some level of built-in documentation, but in practice it seems to be about the same level of effort as just reading a REST API document anyway, at least for basic use cases.

Re: The Rise and Fall of CORBA (2006)

#65

Post by 36547674thrw »

hinkley wrote: post #36
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 mo…

[flagged]

Re: The Rise and Fall of CORBA (2006)

#67

Post by crabbone »

winrid wrote: post #7
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…

Why no type checking? Generate an Open API client for target languages. Done. Assuming you need an API. I'll never build an app that way again, it's not worth my hands. I'd rather use Hotwire, or LiveViews, or Django's Unicorn for the web part. Zod looks nice too.

The problem isn't so much with checking as it is with what kinds of things you can check. OpenAPI offers a very powerless type system. So bad, it's almost not worth using. Not only that, it's designed for JSON, which is an awfully bad format -- so, even if you could check that somehow, you'd still be very limited by what you can actually send.

Also, yeah, all kind of hot garbage you listed will work on Web, because the expectations to the quality of the output is so low... We came to expect Web to be the dumpster fire of programming. Most unfortunately, this kind of garbage spreads into other areas because Web is a universal interface to many things, and there are plenty of programmers who know how to do it.

Re: The Rise and Fall of CORBA (2006)

#68

Post by 36547674thrw »

36547674thrw wrote: post #65
hinkley wrote: post #36

Earlier quoted context omitted.

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 mo…

[flagged]

[flagged]

Re: The Rise and Fall of CORBA (2006)

#69

Post by crabbone »

lelanthran wrote: post #29
winrid wrote: post #7

Earlier quoted context omitted.

Why no type checking? Generate an Open API client for target languages. Done. Assuming you need an API. I'll never build an app that way again, it's not worth my hands. I'd rather use Hotwire, or LiveViews, or Django's Unicorn for the web part. Zod looks nice too.

> Why no type checking? Generate an Open API client for target languages. I dunno. Why aren't more people using openapi? What I see in practice is that almost everyone is using JSON as the transport mechanism and not generating that JSON serialisation code from open API specs. The type-checking in CORBA was not opt-in, it was mandatory. Type-checking in browser fetch() calls are optional. To opt-in you have to go out…

OpenAPI isn't worth using. It's so pathetically bad, that it's not worth the effort.

Those who use it (eg. Kubernetes) do it for show, to put another badge on their Github repo page, to sound more sophisticated and "in the know" than they actually are.

Re: The Rise and Fall of CORBA (2006)

#70

Post by usrusr »

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…

Reminds me of how little love the SOAP that came between had for the XSD that actually did all the heavy lifting. A bazillion ways of reinventing elaborate communicative acts and surrounding ritual, and a big handwavy "yeah, xsd, whatever" to the actual content.

REST was a huge change in perspective in how it put the representation in the spotlight. It seems ironic that this happened on a schemaless baseline, but perhaps that was a fire it needed to go through, "this is the important part and if we put too much automated tooling in this corner you won't give it the attention it deserves".

Post reply on HN