ORMs...
"Hold my beer!"
The Rise and Fall of CORBA (2006)
111–120 of 156 posts
Re: The Rise and Fall of CORBA (2006)
#112Earlier quoted context omitted.
The problem is that the "fast" part is in quotes because it's glacially slow as soon as you get past the initial MVP or demo. I see this idiocy everywhere, to the point that many clouds are now advertising "Day 2 operations" like it's a new thing to be doing things for more than one day . Everywhere you turn, it's: "Get started quick", "Quickstart", "Deploy to !", etc... What do you do after deployment is... crickets…
I upvoted your comment because it's largely accurate. However, I would caution against blanket stereotypes like this: > Look. Sure, if you're an Indian outsourcer developer, this is great. You can bang out monotonous repetitive code like a meat robot and collect a pay check your subsistence farmer parents could only dream of. You can do this for years, and never have to think, or be creative, or risk your job securit…
> 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 ".
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.
Re: The Rise and Fall of CORBA (2006)
#113I honestly thought what most contributed to their fall was that "Corba-la-la-la-la-la!" thing while they attacked.
(sorry)
Re: The Rise and Fall of CORBA (2006)
#114I 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 po…
I'm fascinated by this! Do you have any favorite books or articles that turned you on to CORBA?
Re: The Rise and Fall of CORBA (2006)
#115It 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.
Re: The Rise and Fall of CORBA (2006)
#116I 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.
Re: The Rise and Fall of CORBA (2006)
#117Earlier quoted context omitted.
This is also nonsense. 99% of the time these failure modes are irrelevant. A remote call fails, the error propagates up the call stack, and someone gets an error message. Just like any of the thousands of other things that can produce errors in complex systems. In the rare case you need to harden a particular call, you add caching or retries or whatever other logic fits your use case. It matters not one bit whether y…
> A remote call fails, the error propagates up the call stack, and someone gets an error message. 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 can't address these failure modes properly.
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.
Re: The Rise and Fall of CORBA (2006)
#118Earlier quoted context omitted.
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.
It's irrelevant to calling it a masterstroke market strategy, which is what the sentence you quoted is about.
Anyone can write a great press release. I think the B-schools have classes on that.
Re: The Rise and Fall of CORBA (2006)
#119Re: The Rise and Fall of CORBA (2006)
#120Earlier quoted context omitted.
It's irrelevant to calling it a masterstroke market strategy, which is what the sentence you quoted is about.
Anyone can write a great press release. I think the B-schools have classes on that.
You're all over the place. Nobody said it was difficult.