7 ms·

What're they going to say? "CORBA was a giant shitpile and created tire fires for several years but since this is an academic paper, we have to present historic

What're they going to say? "CORBA was a giant shitpile and created tire fires for several years but since this is an academic paper, we have to present historical context for our ideas"...

protomyth 8y ago
I still think the saddest thing I ever saw in the wild was a Smalltalk shop using CORBA. Doing IDL for Smalltalk VM to Smalltalk VM communications is just wrong.
- cmeiklejohn 8y ago
  Can you extrapolate on this?
  - protomyth 8y ago
    If I have a Smalltalk VM and I'm only talking to other Smalltalk VMs then a native Smalltalk solution without the foolishness of using CORBA is preferable. Its just an insane bit of added plumbing.
    - marshray 8y ago
      Having at least your interfaces defined in something resembling DCE IDL can give a useful amount of confidence that the system could plausibly interop with something else. (RPC, COM, etc.)
      - protomyth 8y ago
        First, its something you don't need at the start (and frankly they didn't need for at least a decade), and it not only complicates the code, it also complicates the maintenance and support burden. Interop is probably going to be some other mechanism and should be done only when you need it and have a clear understanding of what actually needs to be done.
        marshray 8y ago
        One can call anything "an insane bit of added plumbing" if it's truly not needed, but that doesn't add much to a discussion of distributed applications.
        protomyth 8y ago
        I think it speaks to the complication people add to distributed applications when something like CORBA is on the table without an actual evaluation if it is really needed. It is most definitely not the only solution.
        cmeiklejohn 8y ago
        The entire point of CORBA was interop, so it's a bit absurd to say it wasn't actually needed, no?
        protomyth 8y ago
        About 4 years ago, I needed a car to drive into the ground that got good gas mileage. I got a pretty good deal on a Kia Rio and I drove it 100 miles a day and it was good on gas and low maintenance. It is just me, so room wasn't an issue. I suppose I could have bought a Cadillac Escalade and spent a lot more on gas and maintenance while being able to haul a lot of people which would of never happened. It also would have cost quite a bit more than my Rio. So, its not absurd to buy a Kia if it meets your needs instead of an Escalade, quite the opposite in fact. Just as it is really foolish to use CORBA when all you really need are the facilities already included with most Smalltalks. Just because I'm doing communications doesn't mean I need the big, expensive solution.
        cmeiklejohn 8y ago
        Agreed, and that's why Distributed Erlang works the way it does. However, it's unfair to criticize CORBA for one of it's design tenets. It was designed for interop, hence the name. Many solutions for transparent distribution were around the same time as Smalltalk. Look at systems like Eden, Emerald, etc.
    - cmeiklejohn 8y ago
      Well, this is basically the story of Distributed Erlang, which does this out of the box transparently.
      - protomyth 8y ago
        PDO on NeXTSTEP was also quite good. I haven't really looked, but I'm pretty sure it survives in mac os.
- cmeiklejohn 8y ago
  Why sad?
toddh 8y ago
Your CORBA experience depended on how you used it. If you used the IDL and messaging and plugged in your own backend it could work quite well. People are still reinventing new IDLs to this day.
- cmeiklejohn 8y ago
  Just like RMI, CORBA was fine if you knew the boundaries where distribution started/ended. The issue with CORBA was the transparency and was apparent since NFS. If you used CORBA tastefully, it was fine.
- cmeiklejohn 8y ago
  To be fair, all modern RPC frameworks like Thrift, Protobuffs, etc. all use a IDL and it would be remiss to discount CORBA for this.
- cryptonector 8y ago
  People have been reinventing IDLs since forever and a day. S-expressions are the oldest serialization format that I know of. ASN.1 is a fairly ancient IDL that was used for RPC back in the early 80s (ISODE/ROSE). There's ONC RPC, with XDR as the IDL. There's DCE RPC (and MS-RPC). And many many many many others. There's tons of serialization formats, and they all tend to have one or more related sort of RPC frameworks, ad-hoc or otherwise. Perl5 has several, no? This is the space of NIH. Take protocol buffers. It's supposed to be an anti-ASN.1, but it's actually remarkably similar to ASN.1's DER (distinguished encoding rules), which means it has lots of the same mistakes. It's all very sad.
  - cmeiklejohn 8y ago
    If you actually read the paper, we talk about ASN.1 and why it's insuffient for what we are doing. That's clearly stated, and it's clear you didn't read that paragraph.
    - cryptonector 8y ago
      I was responding to a comment, not TFA. I had not read TFA at all at that time. Looking at the one paragraph that mentions ASN.1 (skimming the rest for context), I cannot help but wonder how familiar you are with ASN.1. SNMP is not a good example of how to use ASN.1. To be fair you're referencing a paper that discusses SNMP's use of ASN.1, but... you say nothing at all about how ASN.1 is inadequate, or what might be missing from it! What gives. Did you actually read anything about ASN.1? Did you even skim the ITU-T x.68x and x.69x document series? [EDIT: I missed the second citation about why ASN.1 is inadequate. I will have to read that, though I'll admit that I am skeptical. Keep in mind that ASN.1 has been extended over time, so that one good question might be: what is missing that cannot be added? This is especially a good question when the alternative is to start from scratch.] Note that I am [and my earlier comment certainly was] not defending or promoting ASN.1. I am saying that we have had a lot of reinventions of IDLs. Now I'm also adding that a lot of ASN.1 haters don't really have a clue about ASN.1. Typically what they hate is a) the tag-length-value encoding rules (but not all ASN.1 encoding rules are TLV!), BER/DER/CER, and b) the syntax (which, whatever, it's just syntax). The ASN.1 haters completely miss out on: the rather vast literature on encoding rules (including PER and OER which most closely resemble XDR), advanced features (e.g., the Information Object System), and especially the related SDL (which, granted, I believe simply hasn't had much use at all, at least that I'm aware of, but it's a very interesting idea that deserves more study). Instead, the ASN.1 haters generally produce or choose alternatives which either have roughly the same darned problems (Protocol Buffers, I'm looking at you), or a completely different set of also-obnoxious problems (e.g., JSON's escaping requirements for strings). And so the circle of NIH [bad] wheel reinvention goes. Another common objection to ASN.1 is lack of open source tooling. However, this is not really true anymore, with several decent open source ASN.1 compilers in existence. Of course, if you choose to invent a new IDL, then initially there will be no open source tooling for it! I'm perfectly happy to not use ASN.1. I'll be perfectly happy if someone else doesn't use it. I'm not happy to see ASN.1 haters toss the baby (ASN.1's good ideas) out with the bathwater only to then reinvent the wheel badly. Your exceedingly-light on the evidence dismissal of ASN.1 is par for the course, and does not help. EDIT: Note that I'm not calling you an "ASN.1 hater".
contravariant 8y ago
"Corba, while partially successful..."

What're they going to say? "CORBA was a giant shitpile and created tire fires for several years but since this is an academic paper, we have to present historical context for our ideas"...

protomyth 8y ago

I still think the saddest thing I ever saw in the wild was a Smalltalk shop using CORBA. Doing IDL for Smalltalk VM to Smalltalk VM communications is just wrong.

cmeiklejohn 8y ago
Can you extrapolate on this?
- protomyth 8y ago
  If I have a Smalltalk VM and I'm only talking to other Smalltalk VMs then a native Smalltalk solution without the foolishness of using CORBA is preferable. Its just an insane bit of added plumbing.
  - marshray 8y ago
    Having at least your interfaces defined in something resembling DCE IDL can give a useful amount of confidence that the system could plausibly interop with something else. (RPC, COM, etc.)
    - protomyth 8y ago
      First, its something you don't need at the start (and frankly they didn't need for at least a decade), and it not only complicates the code, it also complicates the maintenance and support burden. Interop is probably going to be some other mechanism and should be done only when you need it and have a clear understanding of what actually needs to be done.
      - marshray 8y ago
        One can call anything "an insane bit of added plumbing" if it's truly not needed, but that doesn't add much to a discussion of distributed applications.
        protomyth 8y ago
        I think it speaks to the complication people add to distributed applications when something like CORBA is on the table without an actual evaluation if it is really needed. It is most definitely not the only solution.
      - cmeiklejohn 8y ago
        The entire point of CORBA was interop, so it's a bit absurd to say it wasn't actually needed, no?
        protomyth 8y ago
        About 4 years ago, I needed a car to drive into the ground that got good gas mileage. I got a pretty good deal on a Kia Rio and I drove it 100 miles a day and it was good on gas and low maintenance. It is just me, so room wasn't an issue. I suppose I could have bought a Cadillac Escalade and spent a lot more on gas and maintenance while being able to haul a lot of people which would of never happened. It also would have cost quite a bit more than my Rio. So, its not absurd to buy a Kia if it meets your needs instead of an Escalade, quite the opposite in fact. Just as it is really foolish to use CORBA when all you really need are the facilities already included with most Smalltalks. Just because I'm doing communications doesn't mean I need the big, expensive solution.
        cmeiklejohn 8y ago
        Agreed, and that's why Distributed Erlang works the way it does. However, it's unfair to criticize CORBA for one of it's design tenets. It was designed for interop, hence the name. Many solutions for transparent distribution were around the same time as Smalltalk. Look at systems like Eden, Emerald, etc.
  - cmeiklejohn 8y ago
    Well, this is basically the story of Distributed Erlang, which does this out of the box transparently.
    - protomyth 8y ago
      PDO on NeXTSTEP was also quite good. I haven't really looked, but I'm pretty sure it survives in mac os.
cmeiklejohn 8y ago
Why sad?

toddh 8y ago

Your CORBA experience depended on how you used it. If you used the IDL and messaging and plugged in your own backend it could work quite well. People are still reinventing new IDLs to this day.

cmeiklejohn 8y ago
Just like RMI, CORBA was fine if you knew the boundaries where distribution started/ended. The issue with CORBA was the transparency and was apparent since NFS. If you used CORBA tastefully, it was fine.
cmeiklejohn 8y ago
To be fair, all modern RPC frameworks like Thrift, Protobuffs, etc. all use a IDL and it would be remiss to discount CORBA for this.
cryptonector 8y ago
People have been reinventing IDLs since forever and a day. S-expressions are the oldest serialization format that I know of. ASN.1 is a fairly ancient IDL that was used for RPC back in the early 80s (ISODE/ROSE). There's ONC RPC, with XDR as the IDL. There's DCE RPC (and MS-RPC). And many many many many others. There's tons of serialization formats, and they all tend to have one or more related sort of RPC frameworks, ad-hoc or otherwise. Perl5 has several, no? This is the space of NIH. Take protocol buffers. It's supposed to be an anti-ASN.1, but it's actually remarkably similar to ASN.1's DER (distinguished encoding rules), which means it has lots of the same mistakes. It's all very sad.
- cmeiklejohn 8y ago
  If you actually read the paper, we talk about ASN.1 and why it's insuffient for what we are doing. That's clearly stated, and it's clear you didn't read that paragraph.
  - cryptonector 8y ago
    I was responding to a comment, not TFA. I had not read TFA at all at that time. Looking at the one paragraph that mentions ASN.1 (skimming the rest for context), I cannot help but wonder how familiar you are with ASN.1. SNMP is not a good example of how to use ASN.1. To be fair you're referencing a paper that discusses SNMP's use of ASN.1, but... you say nothing at all about how ASN.1 is inadequate, or what might be missing from it! What gives. Did you actually read anything about ASN.1? Did you even skim the ITU-T x.68x and x.69x document series? [EDIT: I missed the second citation about why ASN.1 is inadequate. I will have to read that, though I'll admit that I am skeptical. Keep in mind that ASN.1 has been extended over time, so that one good question might be: what is missing that cannot be added? This is especially a good question when the alternative is to start from scratch.] Note that I am [and my earlier comment certainly was] not defending or promoting ASN.1. I am saying that we have had a lot of reinventions of IDLs. Now I'm also adding that a lot of ASN.1 haters don't really have a clue about ASN.1. Typically what they hate is a) the tag-length-value encoding rules (but not all ASN.1 encoding rules are TLV!), BER/DER/CER, and b) the syntax (which, whatever, it's just syntax). The ASN.1 haters completely miss out on: the rather vast literature on encoding rules (including PER and OER which most closely resemble XDR), advanced features (e.g., the Information Object System), and especially the related SDL (which, granted, I believe simply hasn't had much use at all, at least that I'm aware of, but it's a very interesting idea that deserves more study). Instead, the ASN.1 haters generally produce or choose alternatives which either have roughly the same darned problems (Protocol Buffers, I'm looking at you), or a completely different set of also-obnoxious problems (e.g., JSON's escaping requirements for strings). And so the circle of NIH [bad] wheel reinvention goes. Another common objection to ASN.1 is lack of open source tooling. However, this is not really true anymore, with several decent open source ASN.1 compilers in existence. Of course, if you choose to invent a new IDL, then initially there will be no open source tooling for it! I'm perfectly happy to not use ASN.1. I'll be perfectly happy if someone else doesn't use it. I'm not happy to see ASN.1 haters toss the baby (ASN.1's good ideas) out with the bathwater only to then reinvent the wheel badly. Your exceedingly-light on the evidence dismissal of ASN.1 is par for the course, and does not help. EDIT: Note that I'm not calling you an "ASN.1 hater".

contravariant 8y ago

"Corba, while partially successful..."