Live data from Hacker News

The Rise and Fall of CORBA (2006)

queue.acm.org

11–20 of 156 posts

Re: The Rise and Fall of CORBA (2006)

#11
I was about to opine that this title was an homage to the 2009 GI Joe movie, but then I realised it had been written prior to the film's release. I can only assume that in actual fact, "GI Joe: The rise of COBRA" was in fact an homage to this article.

Re: The Rise and Fall of CORBA (2006)

#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 development would become bunk as folks would just buy e.g. an Aircraft object off the peg and plug it into their application. The fact that such blatant silliness actually met with knowing nods gives the insight into how technologies that promised to wire this brave new world together became hot properties almost regardless of their details.

It is telling that J2EE became at least mildly sane when people started ignoring entity beans and working exclusively with session beans, inching towards the realisation that the api was the thing that needed to be remote. Imo the current status quo with REST (in its usual bastardised guise) and json as the language neutral representation, alongside aids like Json schema and OpenApi, while by no means perfect, are workable enough and certainly light years ahead of these earlier fumbling efforts.

Re: The Rise and Fall of CORBA (2006)

#13
post #9

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.

> That is a very bad idea and one of the reasons this kind of thing rightfully died out.

I agree, but, like everything else that is a bad idea, naming conventions help.[1] Namespacing helped too.

I used naming conventions to ensure that network calls looked different, and namespaces that kept network objects in their own module.

[1] Right now we rely on naming conventions in most codebases to differentiate between #define'd literals and variables (C), between constants and variables (Java), between variables and methods (Kotlin, Java, everything else), between interfaces and classes (C#, C++, everything else too, probably), for everything in Python (pep8).

Using naming conventions to identify remote calls is no different than using naming conventions to identify interfaces.

Re: The Rise and Fall of CORBA (2006)

#14

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.

Re: The Rise and Fall of CORBA (2006)

#15
>To create quality software, the ability to say “no” is usually far more important than the ability to say “yes.” Open source embodies this in something that can be called “benevolent dictatorship”: Even though many people contribute to the overall effort, a single expert (or a small cabal of experts) ultimately rejects or accepts each proposed change. This preserves the original architectural vision and stops the proverbial too many cooks from spoiling the broth.

“Focusing is about saying no.” -Steve Jobs, WWDC ‘97 -- As sad as it was, Steve Jobs was right to “put a bullet in OpenDoc’s head”.

https://donhopkins.medium.com/focusing-is-about-saying-no-st...

And also:

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

DonHopkins on Jan 24, 2018 | parent | context | favorite | on: Ted Nelson on What Modern Programmers Can Learn fr...

In the ideal world we would all be using s-expressions and Lisp, but now XML and JSON fill the need of language-independent data formats.

>Not trying to defend XSLT (which I find to be a mixed bag), but you're aware that it's precursor was DSSSL (Scheme), with pretty much a one-to-one correspondence of language constructs and symbol names, aren't you?

The mighty programmer James Clark wrote the de-facto reference SGML parser and DSSSL implementation, was technical lead of the XML working group, and also helped design and implement XSLT and XPath (not to mention expat, Trex / RELAX NG, etc)! It was totally flexible and incredibly powerful, but massively complicated, and you had to know scheme, which blew a lot of people's minds. But the major factor that killed SGML and DSSSL was the emergence of HTML, XML and XSLT, which were orders of magnitude simpler.

James Clark: http://www.jclark.com/

https://en.wikipedia.org/wiki/James_Clark_(programmer)

There's a wonderful DDJ interview with James Clark called "A Triumph of Simplicity: James Clark on Markup Languages and XML" where he explains how a standard has failed if everyone just uses the reference implementation, because the point of a standard is to be crisp and simple enough that many different implementations can interoperate perfectly.

A Triumph of Simplicity: James Clark on Markup Languages and XML:

http://www.drdobbs.com/a-triumph-of-simplicity-james-clark-o...

I think it's safe to say that SGML and DSSSL fell short of that sought-after simplicity, and XML and XSLT were the answer to that.

"The standard has to be sufficiently simple that it makes sense to have multiple implementations." -James Clark

My (completely imaginary) impression of the XSLT committee is that there must have been representatives of several different programming languages (Lisp, Prolog, C++, RPG, Brainfuck, etc) sitting around the conference table facing off with each other, and each managed to get a caricature of their language's cliche cool programming technique hammered into XSLT, but without the other context and support it needed to actually be useful. So nobody was happy!

Then Microsoft came out with MSXML, with an XSL processor that let you include tags in your XSLT documents to do all kinds of magic stuff by dynamically accessing the DOM and performing arbitrary computation (in VBScript, JavaScript, C#, or any IScriptingEngine compatible language). Once you hit a wall with XSLT you could drop down to JavaScript and actually get some work done. But after you got used to manipulating the DOM in JavaScript with XPath, you being to wonder what you ever needed XSLT for in the first place, and why you don't just write a nice flexible XML transformation library in JavaScript, and forget about XSLT.

XSLT Stylesheet Scripting Using :

https://docs.microsoft.com/en-us/dotnet/standard/data/xml/xs...

Excerpts from the DDJ interview (it's fascinating -- read the whole thing!):

>DDJ: You're well known for writing very good reference implementations for SGML and XML Standards. How important is it for these reference implementations to be good implementations as opposed to just something that works?

>JC: Having a reference implementation that's too good can actually be a negative in some ways.

>DDJ: Why is that?

>JC: Well, because it discourages other people from implementing it. If you've got a standard, and you have only one real implementation, then you might as well not have bothered having a standard. You could have just defined the language by its implementation. The point of standards is that you can have multiple implementations, and they can all interoperate.

>You want to make the standard sufficiently easy to implement so that it's not so much work to do an implementation that people are discouraged by the presence of a good reference implementation from doing their own implementation.

>DDJ: Is that necessarily a bad thing? If you have a single implementation that's good enough so that other people don't feel like they have to write another implementation, don't you achieve what you want with a standard in that all implementations — in this case, there's only one of them — work the same?

>JC: For any standard that's really useful, there are different kinds of usage scenarios and different classes of users, and you can't have one implementation that fits all. Take SGML, for example. Sometimes you want a really heavy-weight implementation that does validation and provides lots of information about a document. Sometimes you'd like a much lighter weight implementation that just runs as fast as possible, doesn't validate, and doesn't provide much information about a document apart from elements and attributes and data. But because it's so much work to write an SGML parser, you end up having one SGML parser that supports everything needed for a huge variety of applications, which makes it a lot more complicated. It would be much nicer if you had one SGML parser that is perfect for this application, and another SGML parser that is perfect for this other application. To make that possible, the standard has to be sufficiently simple that it makes sense to have multiple implementations.

>DDJ: Is there any markup software out there that you like to use and that you haven't written yourself?

>JC: The software I probably use most often that I haven't written myself is Microsoft's XML parser and XSLT implementation. Their current version does a pretty credible job of doing both XML and XSLT. It's remarkable, really. If you said, back when I was doing SGML and DSSSL, that one day, you'd find as a standard part of Windows this DLL that did pretty much the same thing as SGML and DSSSL, I'd think you were dreaming. That's one thing I feel very happy about, that this formerly niche thing is now available to everybody.

Re: The Rise and Fall of CORBA (2006)

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

The first 3 is every RPC API which is not complete dreck.

4 and 5 are limited to the schema-based ones.

Re: The Rise and Fall of CORBA (2006)

#17
COM vs SOM: The Component Object Model and Some Other Model (1999) (archive.org) DonHopkins on June 24, 2019 | hide | past | favorite | 22 comments

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

https://web.archive.org/web/19990127184653/http://www.develo...

Also:

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

DonHopkins 6 months ago | parent | context | favorite | on: The Dawn and Dusk of Sun Microsystems [video]

>Sun started to turn into DEC when the manufacturing people started getting hired from DEC into Sun.

That is precisely what happened. Sun also hired a whole bunch of frat boy brogrammers and incompetent bozogrammers from HP and AT&T, too.

I have a lot of respect for the old HP and DEC, but the charlatans that Sun hired from HP and DEC who perpetrated Project DOE (Distributed Object Everywhere) and CORBA were a completely incompetent turkey farm who sabotaged Sun and dragged it into the ground.

https://techmonitor.ai/technology/sunsoft_taps_object_design...

We used to call it Project DOPE (Distributed Object Practically Everywhere), and the OMG (Object Management Group) was better described as OMFG, then it took so long to ship NEO that they should have called it NEOLD.

https://gunkies.org/wiki/Solaris

>SunSoft is delivering the first component against its vision of Project DOE. In February 1991, SunSoft and Hewlett-Packard (HP) developed the industry's first Distributed Object Management Facility (Distributed OMF). This was submitted to the Object Management Group (OMG). In June, SunSoft added to its object technology foundation with the introduction of ToolTalk. The product has been endorsed by a number of leading software vendors including Lotus Development Corp., Cadence, Valid and Clarity Software. Other elements of Project DOE will be introduced later this year.

http://sunsite.uakom.sk/sunworldonline/swol-10-1995/swol-10-...

>New York City -- Perhaps the only vaporware touted for a longer period of time before its release than Windows 95 was Sun's Project DOE. This ambitious object-oriented programming toolkit and distributed operating environment that offers built-in network awareness has arrived at last. The company chose a hastily planned morning press event during Unix Expo to offer details on the software Sun's talked about for almost five years.

>The software and programs making up Project DOE (Distributed Objects Everywhere) are now under the umbrella term "Neo," a word Sun CEO Scott McNealy joked doesn't stand for anything in particular except it being the last three-letter word not trademarked in the US. (Apparently, the second to the last was "JOE," a term Sun picked up for its Java application development tools.)

Then once Java became popular, Sun was overrun by enormous hoards of minions jumping on the Java bandwagon, who just wanted to work effortlessly for a successful company instead of working hard to make a company successful (just as JWZ observed about Netscape, too).

McNealy's worst enemies weren't at Microsoft, they were only himself and the other useless idiots he hired after selling out to AT&T, letting all those DOEZOS on the bus, and rolling out the Java Juggernaut.

The only misguided lesson Scott McNealy learned from his tragic failure driving Sun into the ground was to put all his wood behind one arrow of Putin's useful idiot Trump, instead of so many useless idiots from AT&T, DEC, and HP.

I wrote:

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

DonHopkins on March 1, 2020 | parent | context | favorite | on: Sun's NeWS was a mistake, as are all toolkit-in-se...

Yes you're definitely in the ball park with a beer and a hot dog -- there was a huge amount of corporate baggage. The hype and corporate bullshit that surrounded Java is a good example of what that corporate baggage would have been like if it had been deployed for NeWS's benefit instead of Java's.

If Sun had put as much energy into promoting and supporting NeWS as they did with Java, we would probably live in a very different world today.

Sun turned a corner when they abandoned their Berkeley hippie BSD roots and got into bed with AT&T / SVR4 / Solaris, and that changed a lot of stuff for the worse, making it a lot harder to do things like give away the source code to X11/NeWS. A lot of people from different companies who used to be Sun's enemies, and who had extremely different philosophies and antithetical approaches to "open software", joined Sun and started influencing and managing its policies and projects. A disastrous example was the Distributed Objects Everywhere project and CORBA fiasco, which was originally the crazy idea of a bunch of people from HP and DEC, Sun's former nemesis's, who then came to Sun and started pushing it into everything, to the detriment of NeWS and other older projects at Sun. Some of the problematic people and armchair architectural astronauts that Sun imported and put in charge of DOE/CORBA, like Steve MacKay and Michael Powell, were worthless corporate bullshitters whose main goals were to establish and maintain a hegemony, and they kept their grandiose plans in their head and never wrote anything down or made any hard decisions or came up with anything concrete, because they didn't want to be pinned down to committing to something, when they were actually in way over their heads. The whole point of the incredibly complex software they finally developed was interoperability with other company's compatible software, but in reality none of it actually worked together. It only talked to itself. SLOWLY.

Since DOE was intended to run everywhere and talk to everything but actually didn't, they should have called DOPE for Distributed Objects Practically Everywhere.

DOPE was a complete failure at its stated mission, and it had ridiculously costly overhead and complexity. When they finally delivered something years behind schedule and lacking crucial promised features, it actually required TWO CDROMs to install. (You'd think they could have distributed a distributed network object system over the network, instead of via CDROM, but nooooo: it was just too big to download.) And in the end, nobody actually used "DOE" or "NEO" for anything consequential. They wasted a spectacular amount of time, energy, money, careers, and good will on that crap.

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

https://www.javaworld.com/article/2077168/distributed-object...

And then when Java finally came along, the same meddlesome corporate baggage handlers and armchair architectural astronauts went into overdrive to evangelize and promote the Java Juggernaut. And even more of them flocked in droves to Sun to jump on the Java bandwagon. If it was bad after the invasion of System V / AT&T / HP / DEC minions, things got much worse once the Java zombies started arriving in teaming brain-eating hoards to get their part of the action in response to all the hype. The original Java team was brilliant, and there were some extremely excellent people working on it, but they were totally outnumbered by the dead weight of all the hangers-on who didn't want to work hard to make a struggling company great, but just wanted an easy job at a secure company that was already great.

If Sun had shown the commitment and dedicated the resources to NeWS that they did to DOE and Java, things would be a lot different. And it would have probably also turned out terribly, for all the same reasons.

JWZ said the same kind of thing happened at NetScape, too.

https://tech.slashdot.org/story/05/03/10/146234/mozilla-foun...

>This is starting to sound familiar (Score:4, Interesting) by gothzilla ( 676407 ) on Thursday March 10, 2005 @11:10AM (#11899790)

>I remember reading JWZ's blog back in the Netscape days. I remember one entry in particular where he noted that Netscape had changed. It used to be full of people who wanted to help create a great company. It turned into a place full of people who just wanted to work for a great company. The people who live to help create get replaced by those who want to ride on their coat-tails. This happens when businesses become successful. Everything changes. Like the band that was good friends and partied together every night. They get signed, shit gets serious, and suddenly they're fighting and arguing about things till they break up and go their separate ways.

>From an old post in his blog:

>What is most amazing about this is not the event itself, but rather, what it indicates: Netscape has gone from ``hot young world-changing startup'' to Apple levels of unadulterated uselessness in fewer than four years, and with fewer than 3,000 employees.

>But I guess Netscape has always done everything faster and bigger. Including burning out.

>It's too bad it had to end with a whimper instead of a bang. Netscape used to be something wonderful.

>The thing that hurts about this is that I was here when Netscape was just a bunch of creative people working together to make something great. Now it's a faceless corporation like all other faceless corporations, terrified that it might accidentally offend someone. But yes, all big corporations are like that: it's just that I was here to watch this one fall.

>Perhaps the same fate awaits Mozilla. Hopefully not, but when your product becomes as successful as Mozilla and Firefox have, things do change and change is inevitable. It all comes down to how the people involved with the projects handle the change.

>Mozilla did rise from the ashes of Netscape though. Hopefully some of the original Netscape people are still around to help lead Mozilla in the right direction, using their experience from the crashing and burning of Netscape in the late 90's.

>JWZ's rantings can be found at http://www.jwz.org/gruntle/ [jwz.org]

(Just click on the testicle!)

``I have yet to come across so much self-righteous bullshit as when I gaze upon the massive heap of crap that is the jwz web experience.''

-- an anonymous poster to slashdot.org, 1998.

I'm not saying it always has to end in tragedy: C# and TypeScript turned out beautifully, given the constraints they had to deal with, in spite of the fact that they came from a giant corporate behemoth like Microsoft. (Although I'm sure there's a lot of bullshit going on behind the scenes, the trend is to make them more open and community driven.)

----

Chuck McManis also wrote:

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

ChuckMcM on Jan 1, 2013 | parent | next [–]

Yes, I am aware. I was at a Usenix conference where Rob Pike presented a paper on it, back when it was a bright idea out of Bell Labs. It is the curse of brilliant people that they see too far into the future, get treated as crazy when they are most lucid and get respect when they are most bitter [1]. I was working for Sun Microsystems at the time and Sun was pursuing a strategy known as "Distributed Objects Everywhere" or (DOE) but insiders derisively called it "Distributed Objects Practically Everywhere" or DOPE, it was thinking about networks of 100 megabits with hundreds of machines on them. Another acquaintance of mine has a PDP 8/s this was a serial implementation of the PDP-8 architecture, Gordon Bell did that in the 70's well before serial interconnects made sense. It was a total failure, the rest of the world had yet to catch up. Both Microsoft and Google have invested in this space, neither have published a whole lot, every now and then you see something that lets you know that somebody is thinking along the same lines, trying to get to an answer. I suspect Jeff Bezos thinks similarly if his insistence on making everything an API inside Amazon was portrayed accurately.

The place where the world is catching up is that we have very fast networks in very dense compute. In the case of a cell phone you see a compute node which is a node in a web of nodes which are conspiring to provide a user experience. At some point that box under the table might have X units of compute, Y units of IO, and Z units of storage. It might be a spine which you can load up with different colored blocks to get the combination of points needed to activate a capability at an acceptable latency. If you can imagine a role playing game where your 'computer' can do certain things based on where you invested its 'skill points' that is a flavor of what I think will happen. The computers that do shipping, or store sales will have skill points in transactions, the computers that simulate explosions will have skill points in flops. People will argue whether or not the brick from Intel or the Brick from AMD/ARM really deserves a rating of 8 skill points in CRYPTO or not.

[1] I didn't get to work with Rob when I was at Google although I did hear him speak once and he didn't seem particularly bitter, so I don't consider him a good exemplar of the problem. Many brilliant people I've met over the years however have been lost to productive work because their bitterness at not being accepted early only has clouded their ability to enjoy the success their vision has seen since they espoused it.

Re: The Rise and Fall of CORBA (2006)

#18

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.

Re: The Rise and Fall of CORBA (2006)

#19

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.

Re: The Rise and Fall of CORBA (2006)

#20
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.
Post reply on HN