13 ms·

The Rise and Fall of CORBA (2006)

• js2 3y ago
  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_Architecture 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.
  • iguessthislldo 3y ago
    I graduated in 2018 and it was only mentioned off hand in a systems programming class in a discussion of RPC frameworks. That was basically all I knew about it until I became a maintainer of a CORBA implementation as part of my job. It's not the main part of my job and honestly I still don't know a lot about actually using CORBA. The only part I know a lot about is the interface description language (IDL) used for code generation, which we use a ton of in another framework that I'm actually paid to maintain.
  • lelanthran 3y ago
    > 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 had was in sourcing a free ORB (server software) that supported inter-ORB routing so that I could load-balance.[2] My employer eventually shelled out a small fortune (it was the 90s, we were drowning in VC money) for something from, IIRC, IBM[3] that ran on Sun Enterprise Servers (another small fortune). My experience with CORBA was GREAT! I mean, compared to the way we do it now with browser tech: 1. I could use any language to write the client software, not limited to only Javascript. 2. Making a server call from the client was transparent. It looked like any other function call, unlike how it has to be done now using promises/futures or callbacks. 3. The tech supported exceptions which were also transparent to the programmer. In C++ you could do the following and it would work as expected. try { myObj->foo() } catch { /* ... */ } 4. It was all strongly typed; if you used an argument with the wrong type you'd get either (in compiled languages) a compilation error or (in Interpreted languages) a runtime exception before the call is made. 5. Developer velocity was great. I wrote my object specification, the tools generated both the server-side and the client-side wrappers, and all I had to do was call them. [1] I was young, still in the phase of resume-driven-development. [2] I used a free ORB written in C++ called either Mico or Micro; I don't remember the specifics. [3] Maybe Sun, I'm not sure.
    • brazzy 3y ago
      > 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.
      • lelanthran 3y ago
        > 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.
      • stickfigure 3y ago
        > 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.
  • kanzenryu2 3y ago
    Some older Java application servers still feature a tiny amount of CORBA underneath the covers
  • sk5t 3y ago
    Lotus Notes/Domino supported it for IPC and it worked pretty well, e.g. from .NET which did not have a vendor language binding.
  • inferiorhuman 3y ago
    Gnome used CORBA in the form of Bonobo and KDE reinvented the wheel with DCOP.
    • sirtaj 3y ago
      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.
      • inferiorhuman 3y ago
        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.
        • tguvot 3y ago
          if my memory serves me right, corba (if form of orbit) worked well enough for gnome because almost nothing used it. kde in it's turn were heavily reliant on it (mico) for embedding and communication. but compilation was indeed painfully slow (i still remember never ending kde compiles in 99-2000) so they came up with dcop/kparts after having few drinks and deciding that they can do better
          • sirtaj 3y ago
            Apart from the template bloat, at the time CORBA meant exceptions IIRC. The bits of GNOME that used orbit dealt with the same errors mostly by ignoring the return codes. In the end, both teams decided that assuming components running in remote processes was the wrong default. I'm not sure what GNOME replaced them with, but KParts rescued KDE 2.0
            • tguvot 3y ago
  • seren 3y ago
    I am still working on a code base that has slowly evolved from around 2000 with as its core CORBA as the internal communication bus between actors, so we still use it. We likely want to remove it because it is a bit an overkill in our application, but at the same time it is working and no one wants to pay for a rewrite.
  • willis936 3y ago
    I worked at a defense contractor small business for a short while that used CORBA in some of its products. Previous engineers declared it impossible to update, so they asked me to do it. I had to upgrade the C++ version for the first time in a decade. I didn't find it very fun, but it was satisfying to see an ancient program compile on a more modern toolchain.
  • pjmlp 3y ago
    It was used by Nokia Networks for all their HP-UX based infrastructure, in a mix of C++ and Perl. Eventually it was replaced by a new server infrastructure based on Java EE and Red-Hat Linux.
    • SSLy 3y ago
      CORBA itself is still used there for that purpose.
• lelanthran 3y ago
  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 forever.
  • winrid 3y ago
    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.
    • lelanthran 3y ago
      > 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 outside of the standard.
      • littlecranky67 3y ago
        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.
        • whizzter 3y ago
          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 ambigious mappings when it then comes to the frontend (Typescript) side, the Typescript side then mostly benefits from client-side typings for developers but actually validating isn't always done if we only have SPA consumers (Incompatible upgrade -> new cloned endpoint for the duration of the upgrade period).
• longemen3000 3y ago
  CORBA is used in the chemical industry (CAPE-OPEN standard) https://www.colan.org/ https://www.colan.org/
• b800h 3y ago
  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.
  • HlessClaudesman 3y ago
    COBRA in production: 29 minutes of imagined glory, 1 minute of ignominious RETREAT!!! https://www.youtube.com/watch?v=thbICk05yPk https://www.youtube.com/watch?v=thbICk05yPk
  • jabl 3y ago
    Maybe it was a homage to the 1980's action movie "Cobra" with Sylvester Stallone.
• tragomaskhalos 3y ago
  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.
  • kazinator 3y ago
    There was also a thread obsession. However, luckily, 'Threads' magazine is about sewing. I had an issue on my desk.
    • tragomaskhalos 3y ago
      Ah yes apartment threading and all that. Read so much about that stuff, but will go to my grave having never understood it!
      • kazinator 3y ago
        Apartment threading means that your component has a thread in, which doesn't call into other components. It receives the requests via messages, same if it were running in another process. I believe there is marshaling of arguments to an apartment thread, like in the out-of-process case. Thus you don't have to deal with the possibility that two or more calling threads are executing the component's code.
• DonHopkins 3y ago
  >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-steve-jobs-wwdc-97-ff0174c171d0 https://donhopkins.medium.com/focusing-is-about-saying-no-st... And also: https://news.ycombinator.com/item?id=16227249 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/ http://www.jclark.com/ https://en.wikipedia.org/wiki/James_Clark_(programmer) 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-on-m/184404686 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 <script> 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 <msxsl:script>: https://docs.microsoft.com/en-us/dotnet/standard/data/xml/xslt-stylesheet-scripting-using-msxsl-script 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.
• DonHopkins 3y ago
  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://news.ycombinator.com/item?id=20266450 https://web.archive.org/web/19990127184653/http://www.develop.com/dbox/COM_vs_SOM_Summ.htm https://web.archive.org/web/19990127184653/http://www.develo... Also: https://news.ycombinator.com/item?id=34127174 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_to_do_persistent_engine_for_project_doe 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 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-doe.html 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 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://en.wikipedia.org/wiki/Distributed_Objects_Everywhere https://www.javaworld.com/article/2077168/distributed-object-computing-with-joe-and-neo.html 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-foundation-in-more-development-trouble?sdsrc=next 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/ 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 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.
• amatwl 3y ago
  I literally worked on a project two years ago that was still using CORBA. Oof.
  • CoastalCoder 3y ago
    I still see CORBA mentioned in some U.S. defense contractor job postings.
    • amatwl 3y ago
      Yep, for the record, the project was while I was still at a defense contractor :).
  • freshboy69 3y ago
    I think I know where you worked lol Cigna is still HEAVILY using CORBA. It's pretty awful
• spaintech 3y ago
  My first exposure to CORBA was 1996/97 where it was used to deploy a major distributed infrastructure. It worked quite well to manage and integrate this large scale deployment, some of it expanded beyond just one datacenter, so it was nice to have a really good control system to manage thousands of services across such a large estate with minimal user intervention. Applications were patch and upgraded through the CORBA services and we scaled the system to provide national and international infrastructure services. I would wager nearly 20 years since I had insight into how that infrastructure worked that this is still running… Obvious use case is telcos.
• nabla9 3y ago
  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...
  • corba_v2 3y ago
    don't forget frameworks like cadence and temporal :)
• Animats 3y ago
  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 shopping cart how to buy stuff. Especially for B2B E-commerce.
  • eternityforest 3y ago
    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.
    • Animats 3y ago
      > about the same level of effort as just reading a REST API document anyway, at least for basic use cases. The idea is to automate that, using a LLM to read a description and create the appropriate reply messages, retrying until it works. You need at least a rough specification and semi-useful error messages. Then let the system work until it has established communication.
      • eternityforest 3y ago
        I think any LLM that could do that could probably do just as well with a badly written informal README, same as humans do.
• hinkley 3y ago
  I interviewed with AT&T for a job and the interviewer was sure a piece of concurrent code was sound and I was sure it was not, but couldn’t articulate it at the end of a long day. I would have been working in CORBA when it was already on its way out. Silver lining that was a bullet I dodged entirely, except of course having the pay the opportunity cost all early Java devs paid because there was an ORB in the JDK for ten+ years.
  • DonHopkins 3y ago
    Good thing you dodged that bullet, or you'd still be counting ringie dingies and not caring. The Apathetic Telephone Company - Saturday Night Live: https://www.youtube.com/watch?v=7uiXH9-GEcw https://www.youtube.com/watch?v=7uiXH9-GEcw Ernestine Gossips with Cher: https://www.youtube.com/watch?v=U0Gw9IUmjwM https://www.youtube.com/watch?v=U0Gw9IUmjwM
• corba_v2 3y ago
  platforms like Cadence and temporal reminds me of CORBA - basically when you think about it, they are CORBA or EJBs just in a new flavor.
• nologic01 3y ago
  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.
• bhaak 3y ago
  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.
• MichiHenning 3y ago
  We still don't have anything in common use that can do what CORBA could do. gRPC doesn't even come close. If you are interested in this type of technology, I recommend looking at ZeroC's Ice. https://zeroc.com https://zeroc.com It's CORBA with all the warts removed, and a lot of other useful stuff added.
  • tguvot 3y ago
    iirc zeroc established by people who used to do corba and then decided that they can do it better. i tried to use it in one of products i worked on a while ago, but licensing was cost prohibitive: $200k ( $500k ?) or few percent from sales
• MichiHenning 3y ago
  BTW, a more readable and better formatted version of the article is here: http://www.triodia.com/staff/michi/queue/queue_doc2.html http://www.triodia.com/staff/michi/queue/queue_doc2.html
• hackandthink 3y ago
  "In the early ’90s, persuading programs on different machines to talk to each other was a nightmare ... (Other early middleware, such as Sun ONC... was tied to C and Unix and not suitable for heterogeneous environments.)" I disagree here. SUN RPCs (ONC) based on XDR worked well and were quite enjoyable to use. CORBA was victim of the Second-system effect. And CORBA meant C++ in the early 90ies. Memory management was a nightmare, C++ and CORBA Apis don't go well together. https://en.wikipedia.org/wiki/Sun_RPC https://en.wikipedia.org/wiki/Sun_RPC https://en.wikipedia.org/wiki/External_Data_Representation https://en.wikipedia.org/wiki/External_Data_Representation
• pachico 3y ago
  Damn dyslexia, I was expecting an article about G.I. Joe...
  • DonHopkins 3y ago
    There should be a Python ORB called Typhon.
• garganzol 3y ago
  I still use CORBA with huge success. For example, it is a backbone of several commercial systems that connect vending units in different regions and even countries. For what it's worth, CORBA is hard to use from languages without a proper reflection. But with something like Java or .NET - it's a breeze. And before you start asking questions why - no, REST or gRPC do not cut it. They are too primitive and come with poorly defined semantics. Their HTTP/1.1 transport is rudimental, though HTTP/2.0 made it better by allowing multiplex streams with an elusive possibility of a proper bidirectional communication. But CORBA already had all that, and more, since 2005! And I use it to the fullest extent in the distributed systems my company designs.
  • rrdharan 3y ago
    gRPC is tightly coupled with HTTP/2 so the way you’re grouping it with REST doesn’t really make sense.
    • garganzol 3y ago
      gRPC-esque protocols started to appear as protobuf serialization (for procedure calls) on top of a REST endpoint (for tunneling). It officially became gRPC and "coupled" with HTTP/2 much later.
  • phendrenad2 3y ago
    I'm fascinated by this! Do you have any favorite books or articles that turned you on to CORBA?
• michaelteter 3y ago
  There have been many Silver Bullets in software development, and they probably all had some real value. But it seems they get latched onto and over-hyped, particularly for decision makers and funders. In reality, what is probably most missing is consistent effort toward better organization and complexity management of problems (leading to effective solutions). Without naming current 2-letter hype trains, we're doing it again after the blockchain stuff finally fizzled. Blockchain didn't magically solve our organizational and complexity problems, and so we need a new great hope. New tech and patterns are exciting (probably mostly because of the promise of making our lives easier), but eventually one stops accepting them with big expectations. Ultimately it seems like instead of addressing the real difficulty in our technical solution development we create new distractions and use them to hide ourselves from the bigger problem that we can't seem to deal with.
• Simon_O_Rourke 3y ago
  My father's business partner was one of the founders of Iona Technologies, the makers of the Orbix Corba Request Broker. Back in the mid 1990s they had visions of being bigger than Microsoft, but events and progress overtook them, and the company was sold for a pittance in the mid 2000s.
• weaponeer 3y ago
  The best described and documented useless thing ever, perhaps excepting PHIGS...
  • pjmlp 3y ago
    Now there is an API I haven't seen in a while.
• derriz 3y ago
  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.
• NelsonMinar 3y ago
  And been replaced with a zillion microservices with gRPC interfaces. Not sure that's an improvement.
• srhtftw 3y ago
  I played with various orbs on and off for many years. The only system I ever found that somewhat worked was VNC which used omniORB. However VNC is mainly about remote frame buffers so I think it's fair to say VNC achieved a modicum of success in spite of using CORBA.
• AlbertCory 3y ago
  > SOAP had serious technical shortcomings, but, as a market strategy, it was a masterstroke. Wrong. SOAP descended quickly into the "whatever happened to" category. Like CORBA. I'm happy to say I threw out SOAP and used REST instead at Google, in practically my first act there: https://albertcory50.substack.com/p/working-at-google-enterprise https://albertcory50.substack.com/p/working-at-google-enterp... The Internet had no time for multi-company, political garbage like SOAP and CORBA.
  • nunuvit 3y ago
    Why are you taking the sentence out of context to change its meaning? TFA says it was a good business move by Microsoft for Microsoft because it fragmented the competition which had been consolidating around CORBA. What happened to it afterwards is irrelevant.
    • AlbertCory 3y ago
      Because what happened to it afterwards is NOT irrelevant. Just like CORBA sounded great in the press releases, but went nowhere in practice. Which is what this article is about.
      • nunuvit 3y ago
        It's irrelevant to calling it a masterstroke market strategy, which is what the sentence you quoted is about.
        • AlbertCory 3y ago
          Anyone can write a great press release. I think the B-schools have classes on that.
          • deleted 3y ago
            [deleted]
          • nunuvit 3y ago
• davidw 3y ago
  CORBA is one of the first technologies that I came across and saw that it was kind of 'hot', but decided I'd learn it if I ended up really needing it. And I never did. It's important to learn when to ignore things in this field. It's never possible to be 100% sure, but there are always going to be 'new! hot!' things.
• sgt101 3y ago
  ORMs... "Hold my beer!"
• MollyRealized 3y ago
  I honestly thought what most contributed to their fall was that "Corba-la-la-la-la-la!" thing while they attacked. (sorry)
• bwanab 3y ago
  It is being overlooked that one of the big impediments to CORBA was the literal cost of license from the vendors. They all wanted to make big bucks. It kind of reminds me of the early days of LISP and smalltalk. Venders were more interested in cashing in than spreading the technology. To be sure, for a big company it wasn't that huge, but when the Dot-com boom went bust and company's were trying to find ways to save money, that was a big flag on the expense sheet given that alternatives were becoming available.
  • HarHarVeryFunny 3y ago
    There's TAO which is an open source CORBA implementation that works just as well as any of the commercial implementations. Nobody in their right mind would use CORBA for a new project of course.
• mannyv 3y ago
  I worked with what was arguably the first large-scale CORBA product (IBM/Tivoli's TME10 product). The main problem with COBRA was speed. At the time, authentication was brutally slow...and there was a separate problem with figuring out which object was canonical. OTOH, being able to patch/override any function with any language was pretty handy. Of course, that because a configuration and operational nightmare, because custom configured overrides would get wiped out when upgrades happened. And it made it difficult for support to figure anything out, since many places were heavily customized by consultants. It's an interesting idea that foundered on the technological limitations of the era, like OpenDoc, Telescript, etc.
• projectileboy 3y ago
  The biggest problem I ran into was that ORBs from different manufacturers just didn’t play nice with one another. And then SOAP and Enterprise Service Bus repeated the whole damn thing.
• Nihilartikel 3y ago
  Just this headline is triggering repressed memories of building a component in a simulation federation for a defense subcontractor in the early 2000s on an awful realtime CORBA system. My first grey hairs started popping out during that project.