The Rise and Fall of CORBA (2006)(queue.acm.org) |
The Rise and Fall of CORBA (2006)(queue.acm.org) |
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.
(sorry)
My first grey hairs started popping out during that project.
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.
“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 <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/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.
"Hold my beer!"
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.
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')
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-...
On mobile OS, entitlements or OS IPC like Binder.
In what concerns Windows it is still pretty much present tense, how COM is spread all around the OS, specially since Vista.
Maybe you don't kow what you are missing by just using pipes with small binaries for everything :)
I did a ton of python-com projects for a big aerospace company in the late 90's and it was amazingly easy to get a lot of well-integrated functionality for little time and effort. Really sad that it's not more common now.
Then Rod Johnson lambasted it famously and then lived long enough to become J2Ee.
I still have his book here somewhere. I keep meaning to sit down with it and the Spring spec and see how badly the abyss stared into him.
REST was a huge change in perspective in how it put the representation in the spotlight. It seems ironic that this happened on a schemaless baseline, but perhaps that was a fire it needed to go through, "this is the important part and if we put too much automated tooling in this corner you won't give it the attention it deserves".
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 something. So they started to do very weird things
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)
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.
You're saying someone else's successful (and partial) execution of an idea somehow validates the original failed execution.
In the same institution, the corba guys just built themselved giant messes trying to unify 4 different languages and the kind of network dependency hell that only corba could allow.
DCOM was never cool, but it also wasn't as ambitious, so good systems got built with it.
REST, GraphQL and gRPC language specific SDKs aren't any different, and now we have containers and kubernetes in addition.
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.
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.
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.
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.
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-enterp...
The Internet had no time for multi-company, political garbage like SOAP and CORBA.
Just like CORBA sounded great in the press releases, but went nowhere in practice. Which is what this article is about.
For example, you should be able to ask anything with a shopping cart how to buy stuff. Especially for B2B E-commerce.
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.
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.
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.
If you are interested in this type of technology, I recommend looking at ZeroC's Ice. https://zeroc.com
It's CORBA with all the warts removed, and a lot of other useful stuff added.
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
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/External_Data_Representation
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...
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.
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.
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.
The Apathetic Telephone Company - Saturday Night Live:
https://www.youtube.com/watch?v=7uiXH9-GEcw
Ernestine Gossips with Cher:
Cigna is still HEAVILY using CORBA. It's pretty awful
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.
But seriously, the root cause of the regression is the web and its associated limitations, quirks, and bad habits.
For example, many web developers started out with eval() and maybe JSON which they thought was simple because it is text based and can be interactively experimented with in the browser console. They could “get started quickly” and they were “moving too fast” to think about codegen tooling, protocol efficiency, typing, or security. Doesn’t matter, they hooked up the form, push it to prod!
It’s a cycle that happens over and over in IT, a variant of the eternal September.
The thing that CORBA (and COM/DCOM) gives you on top of RPC is object references, what's called location transparency in DCOM. That is, if you have an API like this:
*Pie getPie()
class Pie {
int getSize()
}
gRPC and other modern RPCs don't have object identity or objects. They just return structs, and you have to invent your own IDs. So in gRPC, the server may expose:
rpc GetPie(PieRequest) returns (PieResponse) {}
Where things become insane is where you have big graphs of objects, some of which may be remote references (stubs), some local in your own app. Maybe you accidentally store a reference in a global/static variable, which means your application is effectively holding the remote object "open". Performance typically goes out the window because just calling a method, even if it's data like getSize(), results in a network roundtrip.
I still think the underlying ideas were sane: Defining type-safe, portable interfaces using an IDL, then generate client and server code from that IDL. RPC has been reinvented many times, and gRPC won't be the last iteration. I do suspect we could have something CORBA-ish working over the Internet if we can get the technical design right.
You're not going to have dozens of Todo objects that you are callinng methods on. You're going to have a TodoService that has some methods. This is isn't very object oriented; the things sent in & out are just dumb data, it's just request/response.
I think cap'n'proto gets a little closer to having an actual notion of objects, in that the protocol has actual identifiers built in. But it's still more about services than objects.
Corba seemed to really be object oriented; you'd get back todo1 and call todo1.done().
Scaling networks provided more value, and HTTP over networks was always going to work so protocols over HTTP just had to catch up, feature-wise.
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.
Also, yeah, all kind of hot garbage you listed will work on Web, because the expectations to the quality of the output is so low... We came to expect Web to be the dumpster fire of programming. Most unfortunately, this kind of garbage spreads into other areas because Web is a universal interface to many things, and there are plenty of programmers who know how to do it.
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.
What is telling because it's a badly defined beast that mostly doesn't work. But it did the type checking, automatic (client) endpoint creation, self-documentation, reflection-based (server) endpoints, support for lots and lots of languages (as long as you don't use something like an array)...
People keep promising new protocols that do one or two of those things on the modern world, but they always fail to deliver. AFAIK, the last promise was grpc, but doesn't even use a widely supported subset of HTTP so it has no chance of ever going anywhere.
But also CORBA was maybe as far as I can tell the first programming tech to ever get canceled. That everyone went Vampire Castle on & decided collectively to crap on & lambast. What before CORBA had such a loyal hate club, was so bandwagon to disdain? It was a boogeyman tale, one we collectively whispered ourselves away from, even though most people had little sense.
It'd be interesting to try to dig up some of the old GNOME 2 efforts that did have Corba stuff in various apps & systems. Try to find some authors to say how they felt at the time. Go look at the code & see how it was.
The idea of having objects that can connect acriss boundaries is indeed super interesting. I love webdev & it's great, but we have noticeably not gotten very far in 20 years. GraphQL was one would be normalizing upstart, and ideas like resolvers have some merit, but it's still chiefly a state transfer system (which also has real time. Subscribe mode). It's still not really a well paved way to connect systems.
Even if we don't have distributed objects, just expanding the range of normative things we can do with resources on the web feels like it hasn't greatly expanded. Our efforts are still artisinal, handcraft by each team. We need to start figuring out, even if not distributed objects per se, how to grow the capabilities of online/connected systems pervasively.
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.
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 { /* ... */ }
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.
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.
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.
4 and 5 are limited to the schema-based ones.
https://www.linuxjournal.com/magazine/kdemdashthe-next-gener...
Eventually it was replaced by a new server infrastructure based on Java EE and Red-Hat Linux.
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".
So while CORBA could do a lot more, it wasn't necessarily being used that way. At least not anywhere I saw; maybe there were shops out there doing more exotic things.
Cap'n Proto is all about the objects! I would say this is the whole point of the design, and my main motivation in creating it.
(Unlike CORBA, though, Cap'n Proto does not try to pretend that RPCs are equivalent to local calls. In particular it has promise pipelining to compensate for latency, rather than pretending there is no latency. https://capnproto.org/rpc.html)
RPC is the same, except you can't opt for async when you want it.
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.
I'm being somewhat disingenuous asking this. I realise most of the code in any application will be bespoke, but I don't think we should deny that the vision you describe has become reality in part.
In other words, it boils down to the objects vs interfaces, OO vs functional programming arguments in the last decades.
In reality, we still do both. But it’s clear by now that we don’t want remote objects anymore but remote services.
It isn't going anywhere, even if the tooling keeps as clunky as ever.
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 <cloud>!", etc...
What do you do after deployment is... crickets chirping, wolves howling, and a tumble weed rolling slowly past.
CORBA, Java Remoting, .NET WCF, WS-*, etc... are complex technologies that can't be trivially poked and prodded with curl or a repl. What they provide is tooling and long-term velocity and safety even with hundreds of developers on the team.
Heck, even as a solo developer I strongly favoured the "proper" RPC systems. I could define a class type once, and then Visual Studio or IDEA or whatever would spit out tens of thousands of lines of error-free boilerplate code that otherwise I would have to hand-roll.
You can't imagine how depressed it makes me when I see some Web API guide that starts off with a cheery "this is a simple..." and then there's five hundred pages of English text.
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.
But people that need to get things finished, past day two into day five hundred? We use the good stuff, with automation.
Half the world still builds roads with hand tools. Where I live, we build roads with heavy machinery.
That's the difference. Any idiot can pick up a hammer and say "road building is easy". They'll still be building that road with an army of workers a year later.
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.
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.
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();
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.
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.
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.
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.
Generating a OpenAPI/Swagger spec in .NET is as easy as telling a lib like NSwag to generate and publish documents from your API's (and you can filter out to only show public API's in the docs). Probably as easy in Java,go,etc.
Consuming services can usually be done almost as easily by downloading the spec and pointing a code-generator to it.
HOWEVER the mandatory vs opt-in part is why we are stuck with JSON based api's, consuming/providing the typings becomes extra work when interfacing/playing with an API from any dynamic language such as JS, Python, Ruby, etc whilst you really only pay a relatively minor performance penalty from typed languages that people won't care about in dev up until it hits in production (Assuming you have an modern JSON serializer library built for speed).
Anything resembling "bloat"/complexity (sadly types is in this category from the perspective of many anti-TS JS developers, esp as API-typings still won't come from the host language but having to be provided separately) will be offputting and lead to any such spec being ignored by a substantial chunk of developers.
Those who use it (eg. Kubernetes) do it for show, to put another badge on their Github repo page, to sound more sophisticated and "in the know" than they actually are.
Given that they produce human unmanageable/readable code, ejecting was a terrible solution.
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).
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.
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.
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
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
Well, majority of you know are not majority of actual IT workforce in India. As some one who worked for a decade or so with Indian IT vendor and worked with outsourced developer till today. Most of them have no interest beyond meeting client requirement which is just code word for a massaged resume contain exact keywords that clients put in job requirement.
> 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, ..
Well they could've take low paying job that's creative. But IT jobs offer high income while sitting in A/C office and following instructions of manager/client.
Nothing wrong with that I am doing same. It is not a fault it is explicit choice they have made.
Though in my direct example I’m talking about Malaysian outsourcing devs!
in gnome i think they did something like "gparts" based on glib. but because gnome desktop was composed in large part from applications written in gtk and not in gnome libs it never had too much uptake (unlike in kde). but i might be wrong - i been kde user from 1.0 alpha4 and gnome was parallel universe
Uh-huh, but did the message actually get through? Can they safely just retry? These are very uncommon failure modes on local systems but very common on networked systems. Without a proper stateful abstraction beyond just "procedure call", like a promise, you can't address these failure modes properly.
> In the rare case you need to harden a particular call, you add caching or retries or whatever other logic fits your use case
Which now makes your system nondeterministic like I said.
> Even javascript added await because it's better to pretend that async code looks synchronous
Yes, linear code is easier to read. I don't see what this has to do with anything. The use of promises and await indicates a possibility of failure semantics that would otherwise not be apparent in the program's control-flow.
Yes, you can superficially make this look like synchronous code, but it's not synchronous code.
...
> The use of promises and await indicates a possibility of failure semantics that would otherwise not be apparent in the program's control-flow.
They don't, though. They don't indicate if the message got through. They don't indicate if you can safely retry. Their failure mode is exactly as opaque or as transparent as synchronous calls.
The reason for their existence and mandatory use in Javascript is due to a deficiency of the platform (single thread, so all synchronous calls block).
If the platform was better they would never have existed.
The promise is at the remote end. Promise resolution is idempotent, so retries always resolve to the same value. These are correct promise semantics as pioneered in the E language.
Again, total nonsense. There's nothing special about a promise. Whatever logic you can build on promises is easier to build synchronously. Everything that applies to building distributed systems applies whether you use rpc stubs or promises. Promises are just noisier and harder to reason about.
Trying to hide the promises behind a synchronous client interface is unnecessarily constraining and inefficient, like requiring large stack contexts that can't be restarted or persisted, and so can't be simply resumed after partitions.
What? The promise is local, so what do you mean "the promise is at the remote end?"
> Promise resolution is idempotent,
No. It is only run once (whether resolve or success), that does not mean it's idempotent.
Just like exceptions for synchronous code, or error returns.
Using promises in JavaScript is a hack around the fact that the platform has some pretty large deficiencies.
Idempotent operations are implicit promises at the protocol level. We're talking about distributed systems here where abstractions and semantics cross machine boundaries, so your local-only focus is not valid. I suggest reading up on the E language via the link I provided.
> Using promises in JavaScript is a hack around the fact that the platform has some pretty large deficiencies.
A single threaded event loop is not necessarily a deficiency.