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

51–60 of 156 posts

Re: The Rise and Fall of CORBA (2006)

#51

Post by whizzter »

lelanthran wrote: post #6
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.

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

2: You can do HTTP/Json requests "transparently" just fine, it's an implementation issue. The issue is if you're doing that from JS you're blocking the only thread and even in a server/desktop language like Java, C# or C++ you're going to be blocking the entire thread and possibly degrade performance. This wouldn't have been any different with CORBA (But people ignored thread cost issues back in those days).

3: again implementation issue.

4: swagger/openapi will help on the compile side (sadly not runtime with all languages but again, language/impl issue)

5: generators are still a thing and available if you look.

Re: The Rise and Fall of CORBA (2006)

#52

Post by lelanthran »

jiggawatts wrote: post #50
danmaz74 wrote: post #42

Earlier quoted context omitted.

You can mock the "moving fast" trope, but the truth is that moving fast has actually been very important for most web-related software development since the beginning. The reason is that the web is a super-competitive environment where the speed of experimentation and adaptation wins most of the time - even if we, as engineers, might not like that.

The problem is that the "fast" part is in quotes because it's glacially slow as soon as you get past the initial MVP or demo. I see this idiocy everywhere, to the point that many clouds are now advertising "Day 2 operations" like it's a new thing to be doing things for more than one day . Everywhere you turn, it's: "Get started quick", "Quickstart", "Deploy to !", etc... What do you do after deployment is... crickets…

I upvoted your comment because it's largely accurate.

However, I would caution against blanket stereotypes like this:

> Look. Sure, if you're an Indian outsourcer developer, this is great. You can bang out monotonous repetitive code like a meat robot and collect a pay check your subsistence farmer parents could only dream of. You can do this for years, and never have to think, or be creative, or risk your job security.

A lot of the outsourced indian devs do indeed match that description, BUT the majority of them that I know of don't want to "bang out monotonous repetitive code like a meat robot and collect a pay check ".

They want to create novel and creative things like everyone else. That they're stuck in the modern equivalent of the assembly line is really not their fault, and most devs, outsourced or not, are in that space anyway.

Re: The Rise and Fall of CORBA (2006)

#53

Post by whizzter »

galkk wrote: post #37
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 s…

Totally different things, distribution of objects is stupid but as a USER I do love what OLE and it's descendants (and what's inside f.ex. Open/Libreoffice) actually provides in terms of actually working plugin API's.

The best example of OLE the ideas that OLE enabled (even if not implemented by it anymore?) is how you can embed spreadsheets and drawings into a Word document, it becomes super useful for me doing my annual report since I can stick a proper spreadsheet that has automatic calculations in the middle of running text.

(Would I be fond of having to implement all of it? Probably not, and there was also probably many stupid usages of it but for what it was for initially it was a win)

Re: The Rise and Fall of CORBA (2006)

#54

Post by lelanthran »

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

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 it and fake it.

Re: The Rise and Fall of CORBA (2006)

#55

Post by lelanthran »

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

2: You can do HTTP/Json requests "transparently" just fine, it's an implementation issue. The issue is if you're doing that from JS you're blocking the only thread and even in a server/desktop language like Java, C# or C++ you're going to be blocking the entire thread and possibly degrade performance. This wouldn't have been any different with CORBA (But people ignored thread cost issues back in those days). 3: again…

For each thing you list as an implementation issue, it's a problem.

My complaint is not "these things don't exist now", it's "they're not part of the standard". For each "it's an implementation issue", you have multiple incompatible competing mechanisms. With CORBA, while the standard was large and stupid, the very basic thing (make an RPC call, get the response and handle any errors) was supported by the standard in a non-ambiguous and practical way.

So, yeah, the fact that something that was available in the 90s is now available depending on implementation is the problem.

Re: The Rise and Fall of CORBA (2006)

#56

Post by littlecranky67 »

whizzter wrote: post #48
littlecranky67 wrote: post #41

Earlier quoted context omitted.

From my experience, code generators arent stable and reliable enough. Whenever I was in a project where either side (Backend/Frontend) generated code from OpenAPI/Swagger spec, they broke at some point - weeks after introducing, by using some new feature/syntax in the specfile. Given that they produce human unmanageable/readable code, ejecting was a terrible solution.

Out of curiosity, what front/backend languages was involved in this? OpenAPI/Swagger has various functionality for supporting polymoprhism but this is usually where problems crop up in my experience due to the mismatch between how languages support it. In our setup, the server is usually C# and we restrict the API's to primitives, records/objects (without inheritance) and lists of the previous. None of this has ambig…

It was mostly TypeScript and C#. Stuff gets worse when you use a generated swagger specfile from code, and then try to feed this into any other generator.

But when hand-writing openapi specs, there are a lot of features that are not understood by generator or lead to subtle bugs. Stuff like intersections, mixins (oneOf, allOf, anyOf, not), and union types (with named discriminators) are a thing in OpenAPI but kind of are hard to map to C# or Java for that sake. And the way you can map it, is strongly opinionated and might be different between generators (or their templates). But also other stuff, like non-supported `$ref` statements where giving us a headache.

If you start out with generators and are willing to compromise on API cleanliness (i.e. workaround by changing the OpenAPI spec when a bug in the generator arises) you might be fine.

But in cross-department or even cross-company teams, with hand optimized API definitions (specfiles), I wouldn't take the risk. I cannot emphasize risk here enough. Yes, you might be fine for a while. But you receive a new version of the specfile, and suddenly the output generated code breaks, won't even compile. This is a huge problem. You can fight whoever gave you the specfile to revert the changes, but if it passes the OpenAPI test suite, you will have a hard time arguing. So you suddenly have to eject the generated code and hope you can make changes - usually its unmaintainable, unreadable generated code. Alternatively, this is the moment when you rip out the generator and re-implement everything by hand.

Just beware, when chosing a generator, you make a bet that it is mature and bug-free enough to handle all cases that will come during project lifetime - and you bet a significant amount risk to that maturity. And if you know of any rock-solid, battle-tested generator for C# and/or TypeScript, please share. I only see either outdated ones with 100+ github issues per year, or relatively new players that lack a track record. And neither is company/money backed, so you rely on someones open-source work.

Re: The Rise and Fall of CORBA (2006)

#57

Post by whizzter »

jiggawatts wrote: post #50
danmaz74 wrote: post #42

Earlier quoted context omitted.

You can mock the "moving fast" trope, but the truth is that moving fast has actually been very important for most web-related software development since the beginning. The reason is that the web is a super-competitive environment where the speed of experimentation and adaptation wins most of the time - even if we, as engineers, might not like that.

The problem is that the "fast" part is in quotes because it's glacially slow as soon as you get past the initial MVP or demo. I see this idiocy everywhere, to the point that many clouds are now advertising "Day 2 operations" like it's a new thing to be doing things for more than one day . Everywhere you turn, it's: "Get started quick", "Quickstart", "Deploy to !", etc... What do you do after deployment is... crickets…

You have some points but this scenario is also an industry symptom of what sloppy and/or inexperienced developers cause.

As an experienced developer being in this environment you have to be humble to the fact that money is still what rules interactions and apparent non-progress with vague promises can be seen from a _client_ perspective as no progress at all from seemingly total beginners.

Moving "fast" is often needed to assure people and for grunt-work it's absolutely fine as long as it doesn't build in bad requirements into the system...

And that brings us to the IMPORTANT point, moving fast gives you a good prototype ground and a chance to check assumptions with the client/end-users, but you need experienced people to put in brakes and remove bad assumptions out of the codebase before it leads to second-order bloat that makes the bad assumptions impossible to weed out.

In "enterprise" dev the core task that you don't want to hand off to juniors is often database models, data invariants, synchronization semantics,etc that inexperienced people will just try to paper over with increasing amounts of code when wrong and thereby creating huge swaths of code that just cements the bad assumptions into place and creates this glacial progress that you mentioned.

Re: The Rise and Fall of CORBA (2006)

#58

Post by inferiorhuman »

sirtaj wrote: post #38
inferiorhuman wrote: post #20

Earlier quoted context omitted.

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.

Now there's a name I've not seen in a while.

And, yeah, if memory serves CORBA worked well enough for Gnome but not KDE because the C++ story was not great. Whatever bindings being used were dependent on features not well supported by G++, templates being painfully slow to compile, etc.

Re: The Rise and Fall of CORBA (2006)

#59

Post by tragomaskhalos »

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

I vaguely remember those spinning balls in Windows 2000, XP etc. to know your DCOM components were working. Are they still a thing? We did the 3 tier DNA thing, using VB because in VB it was simple, in C++ it looked hellish.

VB was denounced as infantile nonsense fit only for the GUI by us C++ jocks, until we'd done COM in both C++ and then in VB - then we realised what a huge favour VB was doing in insulating you from so much of the complexity. Sure there were Don Box-level things you could probably only do in C++, but for us working stiffs doing business apps it was like day following night.

Re: The Rise and Fall of CORBA (2006)

#60

Post by tragomaskhalos »

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

> 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 example was egregious - does a company doing in flight catering want the same thing as an air traffic control simulation?! It's also about boundaries - a typical 3rd party REST api has a clean and obvious boundary, but how would one of these Aircraft objects sensibly interoperate with my program, as it can't know anything about the rest of the application. The hand-wavers never thought to explore these critical problems.
Post reply on HN