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

81–90 of 156 posts

Re: The Rise and Fall of CORBA (2006)

#81

Post by naasking »

stickfigure wrote: post #31
brazzy wrote: post #9

Earlier quoted context omitted.

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

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

This isn't a problem as long as the returned value provides the right failure semantics (like futures). The problem with trying to encapsulate the network is that deep call chains lead to cascading failures for problems that are common in networks (partitions, latency, etc.). These failure modes also lead to more pervasive use of timeouts in deep call chains, which then introduces non-determinism, which itself makes issues impossible to debug.

Re: The Rise and Fall of CORBA (2006)

#83

Post by DonHopkins »

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]

I'd post a 10 page specifically detailed diatribe, but you don't deserve it because you're just pathetically sealioning about a lost cause. So first read and respond in detail to my 10 page diatribes about CORBA instead, which is the actual topic of this discussion, then you can post your own 10 page detailed diatribe full of specific idiocies about what you love so much about J2EE. Deal? Then let's hear it.

https://news.ycombinator.com/item?id=36547527

https://news.ycombinator.com/item?id=36547511

And FYI, go read what Rod Johnson has to say if you're really interested, know what you're talking about, and not just sealioning (and about J2EE, really??! Of all the things to choose to sealion about, have some fucking taste and self respect, and post something you're not embarrassed to put your real name by!):

https://thenewstack.io/spring-rod-johnson-enterprise-java/

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

"Java is a DSL for taking large XML files and converting them to stack traces."

Edit: [crickets chirping] Yeah, I thought so.

Re: The Rise and Fall of CORBA (2006)

#84

Post by girvo »

lelanthran wrote: post #52
jiggawatts wrote: post #50

Earlier quoted context omitted.

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

Well said. And they take like a duck to water when given the chance to do that novel creative tool driven work (and paid well).

Though in my direct example I’m talking about Malaysian outsourcing devs!

Re: The Rise and Fall of CORBA (2006)

#85

Post by heisenbit »

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…

It solved a few problems but the strictness of the bindings was not helpful. The C++ heavy tooling focus was neither and don‘t get me started on the gap between promise and actual implementation. Once you dealt with different ORBs in a large scale installation (read 3G networks) it became madness. In my first job I fought and kept it out. On my third it caught up with me and I had the fun to rip one vendor out and swap an open source in as the former did not work with the C++ compiler and we were a tier 1 telco vendor and the Orb vendor was on site with the source code. Total mess.

Re: The Rise and Fall of CORBA (2006)

#86

Post by stickfigure »

naasking wrote: post #81
stickfigure wrote: post #31

Earlier quoted context omitted.

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

> 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. This isn't a problem as long as the returned value provides the right failure semantics (like futures). The problem with trying to encapsulate the network is that deep call chains lead to cascading failures…

This is also nonsense. 99% of the time these failure modes are irrelevant. A remote call fails, the error propagates up the call stack, and someone gets an error message. Just like any of the thousands of other things that can produce errors in complex systems.

In the rare case you need to harden a particular call, you add caching or retries or whatever other logic fits your use case. It matters not one bit whether you're using futures or synchronous rpc stubs. Actually it does - synchronous code is easier to harden because it's easier to reason about.

Even javascript added await because it's better to pretend that async code looks synchronous. The failure semantics of "throws an exception" are just fine.

Re: The Rise and Fall of CORBA (2006)

#87

Post by DonHopkins »

tragomaskhalos wrote: post #59
quickthrower2 wrote: post #25

Earlier quoted context omitted.

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.

I loved Don Box's books on COM and SOAP. But "Essential COM" sure made my brain hurt once it started talking about DCOM.

https://news.ycombinator.com/item?id=29593432

>Earlier I posted an article by Don Box comparing SOM and COM, and I mentioned that WebAssembly is going through a similar evolution, and might benefit from some of the lessons of COM and SOM: [...]

https://news.ycombinator.com/item?id=20266627

>This article comparing SOM and COM was written by Don Box. (first archived in January 1999, but doesn't say when published): [...]

>Don Box wrote an excellent in-depth book about COM: "Essential COM": "Nobody explains COM better than Don Box" -Charlie Kindel, COM Guy, Microsoft Corporation. [...]

>Here's a synopsis of COM I wrote in response to "Can someone link to a synopsis describing what "COM" is? It's hard to search for. (e.g. microsoft com visual studio)":

https://news.ycombinator.com/item?id=12975257

>Glad you asked! One of my favorite topics. ;)

>COM is essentially a formal way of using C++ vtables [1] from C and other languages, so you can create and consume components in any language, and call back and forth between them. It's a way of expressing a rational subset of how C++ classes work and format in memory, in a way that can be implemented in other languages.

https://news.ycombinator.com/item?id=22282936

>Apple's OpenDoc based browser, CyberDog, was also quite amazing and flexible, because it was completely component based and integrated with OpenDoc. But that plane never got off the ground, because Steve Jobs rightfully focused on saying "No" and "put a bullet in OpenDoc's head".

Re: The Rise and Fall of CORBA (2006)

#88

Post by derriz »

The article doesn't spend enough time on the fact that actual _interoperability_ didn't actually come to CORBA until it was already past its peak. So a key feature of the technology never really worked.

I worked at a CORBA vender for a year or two in the 1990s and even interoperability between languages, platforms and versions OF OUR OWN CORBA implementation was barely supported and down to luck more than anything else.

Note that CORBA existed as a spec for years before actually specifying an actual wire protocol (IIOP) which you'd imagine would be a fairly fundamental part of any distributed tech which had the goal of offering interoperability. And even years after IIOP appeared, getting CORBA to work between vendors' products was basically impossible.

"Interoperability" in effect meant buying 100% into a single vendor's offering and paying a load of money to consultants to manage version upgrades, getting fixes for "niche" platforms, etc. CORBA's notion of "interoperability" was more along the lines of the way old IBM offered "interoperability" between their different mainframes and minis, and not in the way understood today which is vendor neutral and open.

Another poster says that IONA (one of the biggest vendors) believed that they were going to topple Microsoft. In my opinion, it was actually IBM and the old "big vendor" model where they saw their future. They started offering (mostly broken) Transaction Managers, Service Discover agents, a Message Broker, etc. - as what they hoped would be alternatives to the then dominant big-enterprise tech like CICS/MQ. They imagined a future for big enterprises based around C++/CORBA replacing COBOL/CICS/MQ.

Re: The Rise and Fall of CORBA (2006)

#90

Post by jodrellblank »

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 subscribed to 'Object' magazine, and still recall 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. "

One drum I keep beating is that COM in Windows is amazing for scripting and interoperability between programs. Before PowerShell and "everything is an object [but you're stuck in one .NET process]" there was COM. From Python, from VBScript, from ActivePerl, even in Powershell to break out of .NET, from C# and Java, you could do their language equivalent of:

    $snmp = new-object -ComObject olePrn.OleSNMP
    $snmp.open('127.0.0.1', 'snmp_community', 2, 1000)
    $snmp.get('.1.3.6.1.2.1.1.3.0')
and voila, pluggable SNMP engine into any script in any Windows scripting or programming language. Use it in Excel in Visual Basic for Applications and update your spreadsheet with SNMP results. Then embed the Excel spreadsheet in a Word document. Ppen PowerShell on Windows and run this code[1] to query all registered ones, 1744 on my system, surely some are useful or fun?

Want to read JPG headers? Lean on Explorer to do it, without needing a JPG metadata library in every language. Want to integrate with Windows Text to Speech, or Excel, or Dyalog APL or send a fax from JScript or automate a browser or whatever? COM objects are there.

And it's a world being thrown away in favour of "simply download a Selenium wrapper for every language" and "simply do an OAUTH login to a web service to interface with a styled sluggish CRUD text system". And that's a shame, because web developers, macOS users, Linux users, smartphone users, don't know what they're missing. I'm sympathetic to it being apparently horrible to program the backend in C++, but this world you're scoffing at actually existed and has good features especially for the casual hacker who wants to use system-wide standard interfaces to large and powerful engines, with client and server written in differing languages.

[1] https://stackoverflow.com/questions/660319/where-can-i-find-...

Post reply on HN