Slashdot Mirror

I'll agree that we don't need to add more buzzword-technology to our environment for the sake of having our press releases be full of buzzwords. However, your statement about CORBA being bloated and slow is misinformed. ORBit is an extraordinarily lightweight, speedy implementation. Bud Tribble addressed this in his recent interview at lwn.net.

For more information about ORBit, you can also visit the ORBit page at RHAD.

In addition, check out the CORBA for Beginners page at OMG.
----

I'll agree that we don't need to add more buzzword-technology to our environment for the sake of having our press releases be full of buzzwords. However, your statement about CORBA being bloated and slow is misinformed. ORBit is an extraordinarily lightweight, speedy implementation. Bud Tribble addressed this in his recent interview at lwn.net.

For more information about ORBit, you can also visit the ORBit page at RHAD.

In addition, check out the CORBA for Beginners page at OMG.
----

I'd find it hard to believe that with the CORBA specification being first agreed upon in 1991 that there wasn't some application built with it in a method similar to the one being discussed above. Relevant link: CORBA history

That was a very, very good article by Miguel. Unfortunately the first few posts I have read are from posters who obviously didn't read it and instead are making personal attacks at Miguel.

Miguel's article is spot on. I love everything about Unix except the fact that Component Based programming is so underused. If there is only one thing Microsoft has done right, it is the way they have developed and pushed COM. With COM, I can write a piece of software that performs a task (be it a Widget or piece of middleware) and COMify it.
Once this is done, anyone can use it regardless of what language it was written in, fast XML parsers can be written in C++ and used in from Javascript or VB. This way developers of business apps do not have to make the choice between a.) putting up with a slow app or b.) writing one themselves with all the attendant bugs therein especially if they have little C++/C skills, also they can go on towards actually creating their application instead of worrying about if they malloced() enough space for their char*'s.

Lots of *nix people believe this implies laziness but fail to realize that reinventing the wheel dozens of times over is folly.

Example I:
I am currently designing and implementing a project management system on Windows(TM) for a small business with a few of my friends. two of them are *nix hackers and they balked at using an XML based protocol to transfer data between the client and server. Now instead of simply designing our protocol then using one of the dozens of available parsers to do this, they decided that we should invent our own binary protocol and write our own parser to parse it.

Our project involves code written in both C++ and Javascript/ASP. We could have used a single COM based parser to consistly interact with the data both from the C++ and the Javascript code but instead its been 2 weeks and counting and our homegrown parser is still being written, tested and debugged. In my opinion this is nothing but a waste of time. When I ask them why not just use XML and an already existing parser their replies boil down to "It just feels wrong.". The chances that a bug or two will slip through in testing or that there is a buffer overflow in our parser is not unlikely considering that most early versions of parsers written in C++ have a few bugs like this hidden somewhere. in this situation component based programming would have allowed us to focus on building and designing our actual application instead of focusing time and energy on a tangential application.

Example II:
At work a MBA intern asked me if it was possible to create an application that housed a search engine that searched a database of MBA students based on criteria like concentration, work experience, graduation date, etc. and then displayed results with links to their resumes in MSFT Word(TM) or HTML format which could be stored on a CD to give recruiters at career fairs. Their first attempt had been to use VB and Access which turned out to be a disaster because of DLL Hell based issues. My simple solution was for them to store all the students in an XML file and to write a Javascript page that used the COM based XML parser (written in C++) to perform the search. Writing this page took less than 2 hours.

Now they have this search functionality they can press on a CD and give out at career fairs which any recruiter can view without needing more than MSIE 4.0 or greater.
Without Component based programming their request would have been impossible to fill in their time frame and would have also required that the recruiters machines would need to fulfill a stricter set of requirements (like a Webserver being installed or they'd have to install an app).


In conclusion my question is "Why has it taken so long for a major *nix push towards component based technology?". After all we've had CORBA for almost a decade but there hasn't been that much a big push towards components. Frankly I am eagerly awaiting MSFT's .NET for one reason only...cross language inheritance. The thought that my C++ components can be inherited by my Perl, Java or Javascript objects makes me extremely *CENSORED*.
FOOD FOR THOUGHT

Well, first of all, you seem to agree as far as C is concerned since you advocate wrapping all those unsafe C interfaces into better C++ interfaces.

Yeah, pretty much so. Well-written C is attainable, of course, but the benefits of C++ are certainly worth switching.

C++ still uses the C pointer model and adds a similar reference model. And C++ still uses manual memory management for dynamic allocation. You cannot, in general, address those problems by creating safe abstractions. If you try, you end up severely limiting language semantics, and as soon as you face any outside library, you have to convert to raw pointers anyway.

Both the "C pointer model" and the manual memory management are easily wrappable. "Initialization is resource acquisition" is elegant and easy to stick to. You can also easily wrap the interfaces to the other libraries, as I said before. It can all be done very safely if you keep direct pointer operations to a minimum and thoroughly check them as you do. I feel that this extra bit of planning can be worth the power that is gained.

Using string manipulation as a specific example, exactly what about std::string "severely limits language semantics"?

And C++ still does not guarantee fault isolation among modules or any way of determining from the source code of a module whether that module is safe or not. That is, any piece of code you link with can cause arbitrary problems in any other piece of code, and you have no way of telling. Perhaps you think that's inevitable, but it is not. None of the other languages that I mentioned have that misfeature.

Sure there is. See man 2 fork, or CORBA

Arguing that one should not bother fixing those problems because there are lots of other ways in which people can make mistakes is wrong. The problems C/C++ creates for programmers are easily avoided, without performance penalty or other drawbacks. A day lost trying to chase some avoidable pointer bug in a C/C++ program is a day that could have been spent on testing and fixing some conceptual security bug.

No, good programming practices are what prevents bugs. IMHO there isn't much difference between the various type-safe languages in bug prevention, but there is a huge difference between the various programming practices and quality standards. I have talked with plenty of folks who claim that there's "no performance penalty or other drawbacks" to not having the power of C/C++'s low-level control, but I haven't seen anyone back that up with proof. I would really enjoy for someone, anyone, to prove otherwise.

Fortunately, the Software Process Engineering Management Request For Proposition of the OMG and the UML Profiles mechanisms (see this OMG white paper ) should address this concern: It should allow to describe a development process in a little more rigorous way than the current informality and to precise the particular usage of each construct of the UML notation (or extensions of this core notation) in the context of a given development process.

A book exposing Coad's point of view on the UML will be a "good thing"(tm) only when we'll have such conceptual tools at our disposal. Before this moment, it only adds to the confusion of the newcomers to the UML.

I approached this book looking for something that would teach me about patterns

Fortunately, the Software Process Engineering Management Request For Proposition of the OMG and the UML Profiles mechanisms (see this OMG white paper ) should address this concern: It should allow to describe a development process in a little more rigorous way than the current informality and to precise the particular usage of each construct of the UML notation (or extensions of this core notation) in the context of a given development process.

A book exposing Coad's point of view on the UML will be a "good thing"(tm) only when we'll have such conceptual tools at our disposal. Before this moment, it only adds to the confusion of the newcomers to the UML.

I approached this book looking for something that would teach me about patterns

As far as I know at least, CORBA is the competition to DCOM, now COM+.

Not having used either technology I can't say for sure...

The official CORBA FAQ has a feature list that is similar to COM+ in key areas:

http://sisyphus.omg.org/getting started/corbafaq.htm

Yes I develop for Windows. I enjoy it too.

There is no official standar yet. Submissions are still being accepted. But I think it will come together very quickly. You may read this for a starter.

You wrote SAT (or ACT) test; PC computer; SIMM memory; FSF foundation. Others added PIN number; NIC card; ATM machine. I'll add DSS system, RISC computer, and...

The CORBA Architecture.
You know why we call it that? <ianal>The law considers trademarks to be adjectives.</ianal>

Perhaps this isn't an entirely accurate. You're probably in denial and think that everyone else is jealous and is making up lies.

Either way, we hate your company because every decision is based on the answer to the following question: What will eliminate our competition and force user's to use windows?

While this may be acceptable from most companies, it isn't from you because the OS is central to many of our lives. We spend most of our workday, and increasingly more of our social life using computers. And using windows is a mind numbing experience. It is void of creativity and leave's me feeling empty and tired. I can customize it all I want as long as one of you non-creative drone's thought of it first. Again, you only add features which could increase your market share, not what could make window's better, or more fun to use.

Why don't you join the OMG and over 800 companies to support CORBA? Surely this would dramatically improve the internet and benefit consumer's lives in ways we can only dream of today. Oh yeah, that doesn't factor into anything at MS.

Your characterization of Linux user's as pimply faced adolescents is wishful thinking at best. But of course you know this already. Linux is kicking your butt in the server space, and will soon dominate the embedded market too.

Your only hope is to control the internet protocols that we all depend on.

Microsoft and Internet technologies don't mix. Don't do it... don't even think about it.

From the article:

Maybe I'm being overly cynical, but I've always had a problem with some of the ethics of an organization which not only defines a standard, but also sells pieces of the only implementation of the standard.

So I guess he's steering clear of Rational, UML, and most of The Object Management Group.

For information on the OMG's efforts in integrating XML into CORBA, and white papers discussing the similarities and differences between CORBA and SOAP/XML-RPC, take a look at http://www.omg.org/library/corbaxml.html.

http://www.omg.org was hacked this morning. Banner said "Free gH" - I have a screenshot if anyone is interested... also included instructions to restore normal site. (Site is currently down)

It is great that there is actually a choice, but even though I prefer GNOME for personal reasons KDE is the choice for anyone attempting to build complex and large applications. The strongest and most understated strength of KDE is that is built on top of the MICO implementation of CORBA . Which is by very far the most advanced free implementation out there, as compared to ORBit which is what GNOME uses. This makes the real difference, at least to me. CORBA is a very powerful tool and having a robust implementation really makes a big difference. Eventually GNOME will catch up but for now for serious development it has to be KDE.

Say, is international standard supported by hundreds of vendors suddenly vendor standard?
DCOM - M.S.
CORBA rest of the world.
I think you should look at Object Management Groups'homepage before you let something this stupid from you again.

He basically claims that OMG is giving up language neutrality. Here is a quote from the OMG press release that he is supposedly commenting on:

While the CORBA solution has embraced Java, it has not done so at the expense of other languages. In fact, Java is the only language for which CORBA supports binary portability. For other all other languages, CORBA is portable only at the source code level.

The press release is simply a joint announcement from Sun and OMG announcing that there will be a close collaboration between EJB and CORBA. Importantly, EJB will be supporting the core of CORBA's network communication model: IIOP, which pretty much guarantees that you can write your objects in any language and on any platform, as long as you can make TCP sockets.

I must say that this guy's experience is really, really, far from my own and that ceretainly shapes his very, very different interpretation of this press release. He says that he sees half of all programmers who are working with object integration programming with VB. I certainly don't.

I think people should read the OMG release themselves and draw their own conclusions, but I read it as a commitment from Sun to cooperate with OMG to come up with a vendor neutral object specification ... something to address the fundamental questions of vendor and platform dependence raised by Microsoft's DOM.

1. The deadline for CORBA Component model proposals isn't until August 1999, so no decision has been made.

2. The OMG press release doesn't say what Mr. Sessions implies. It certainly doesn't say that vendor/language neutrality is being abandonded for the Component Model. It's basically just says EJB and CORBA work real good together. Read it for yourself here

3. And finally, from ObjectWatch's home page: "We specialize in offering training and
consulting on Microsoft's distributed component architectures"