Some time in the past twelve hours, the ToS was updated. There is no longer any trace of the recording clause.
There is still a clause that requires me to waive my right to participate in a class action though. I can sue EventBrite only individually, not as part of a class action. (It appears that no-one, for any reason, whether merchant or customer, can ever pursue them in a class action under that ToS.)
> The big problem with IDL-based RPC is that it becomes essentially impossible to version your APIs.
That is true for CORBA, but it is not true for Ice. Have a look at http://www.triodia.com/staff/michi/connections/iss ue8.pdf "Can a Leopard Change its Spots?" for a versioning mechanism that allows you to seamlessly version an application without breaking backward compatibility.
> Hennings opinions should be taken with a pinch of salt. While he co-authored the bet known book on CORBA, he has since left the CORBA arena following the merger of his own company with IONA, and is now pushing an alternative technology called ICE.
Correct--I decided to do something better than CORBA after slaving my guts out for seven years trying to make CORBA better, and largely getting nowhere. Eventually, I realized that there was only so much sh*t I could push uphill and decided to focus my efforts on something more productive.
> The concepts like the POA are too over engineered, but the underlying ideas of language neutrality, a simple interface definition language and a common wire protocol have not been bettered.
I beg to differ. The CORBA POA interface requires over 200 lines of IDL definitions when, in fact, I can provide all of the functionality of the POA, plus some extra, in just over 30 lines.
Yes, language neutrality is a good idea. No, CORBA IDL is *not* simple, not by a long shot. (Look at the last section of the Slice chapter in the Ice manual for some of the reasons.)
IIOP is a very poorly designed protocol that has more flaws than a dog has fleas. Among them a quite major one that prevents efficient implementation of notification services. (See the Ice manual for details.)
> One area where CORBA is particularily useful, is in event or notification based systems.
> Most recently, I used CORBA to replace a SOAP based system. Compared to SOAP, the CORBA based system was faster, easier to work with and far more reliable.
I don't doubt that. It's very hard to beat the ineptitude of SOAP and WS. Now, if you had used Ice to do the same thing, you would probably have done it in half the time, with half the pain, and twice the performance:-)
Having been involved quite deeply in the OMG, I would beg to differ. Especially in the early days, a single company could highjack proceedings simply by threatening to withdraw from the consortium. If any one of the big players at the time had indeed withdrawn, it would have spelled disaster. So, on occasion, one of the big companies got their way after threatening to withdraw...
Later, it wasn't so easy to hold the organization to ransom, and outright blackmail was replaced by political maneuvring. I remember many occasions where the contents of a world-wide standard depended not on technical merit, but much more on who went drinking with whom at the hotel bar the night before the vote.
Web services were never designed to solve this sort of problem. They were never focused on the needs of a performance-critical, real time system like a MMORPG, but rather on doing things like swapping data between corporations and driving Web sites.
The bandwidth and CPU cycles consumed by SOAP are nothing short of staggering. (Look at the archives in comp.object.corba for some calculations.) SOAP easily eats 10-100 times the bandwidth of IIOP (and IIOP isn't particularly good at conserving bandwidth either--Ice does a much better job of that). With SOAP's bandwidth requirements, there is no way we could have made Wish work over an ordinary 56kB modem.
Web services is basically CORBA ten years ago, with a different implementation (XML, SOAP, etc.) that should hopefully work better than CORBA's baroque design-by-committee industry standards. But behind all the buzzwords, we're still talking about the same basic sorts of distributed technology.
I agree that WS is basically CORBA all over again, but I very much doubt that it will work better than CORBA. True, CORBA has indeed suffered badly from design-by-committee, but WS seems to be headed for the same fate. And I watch people make the same mistakes all over again with Web Services. It's disheartening really: instead of learning from the painful lessons of the past, we forge ahead and make the same mistakes again. Partly, that's because, by the time a new technology gains enough momentum to challenge the previous technology, the veterans (who have the experience with the old technology to really work out how to do it better this time) have moved on; and the new people now working on the new technology don't have all the experience of the veterans and then promptly fall into the same old traps...
why does the author constantly mention CORBA? Perhaps I'm not familiar enough with the Java perspective, but I assumed CORBA/COM (etc) were basically dead (or dying) when it came to modern internet programming.
That's a fair question. Looking at the requirements, we needed middleware that is language- and platform-independent. That immediately rules out things such as COM, DCOM, RMI, and.NET. CORBA really was the only candidate. Also, all of us (the people who wrote Ice) had a lot of CORBA experience, and Ice borrows a lot of ideas from CORBA. (No, not everything in CORBA is bad;-) So, I ended up contrasting things to CORBA because Ice is both similar and different to CORBA.
CORBA isn't exactly dead--people are still building industrial-strength systems with it. And, to be fair, CORBA is the most widely-used distribution technology to date. It's just that CORBA is ageing and that, after more than ten years of experience, we now know how to do better and avoid CORBA's mistakes.
The author and company were only familiar with CORBA.
No, not really. I have experience with Sun RPC, DCE, COM, DCOM, Web Services, and CORBA.
Distributed-objects are an older, more established technology. [ie proven]
There are a lot of existing systems, algorithms, ideas, programs, etc. to build a distributed-object system.
Yes, to are large extent. There is a lot of experience we have gained over the past ten years or so on how to build distributed systems that work.
It masks the network from the API (yes, this should be a CON).
That's an old topic that comes up periodically. The most-quoted paper on that topic is probably A Note on Distributed Computing. Personally, I disagree with many of the conclusions in that paper. True, I can't afford to forget that there is a network underneath my API because the semantics are truly different from the non-distributed case. But that does not strike me as a compelling reason to make a remote invocation substantially different from a local one.
Engineering effort is required to make sure clients can access the model with any langauge, and also to allow designers flexibility in the object model. Most of this should be cheaper with a web-services model.
I don't see where web services would be cheaper than any other language-agnostic platform. In fact, everything I have seen so far about web services is more complex than Ice (or CORBA). And web services are horribly inefficient. If you are interested, look for my postings on the topic in comp.object.corba with Deja.
The reason we have web services (or, more accurately, might have them some day) is a political one rather than a technical one: back in the hey-days of the distributed computing war between CORBA and DCOM, Microsoft were about to lose the battle. They weren't going to simply cede the battlefield to the OMG so, rather than fight a war they couldn't win, they simply created a new battlefield. Sadly, web services is about re-inventing the distributed object wheel all over again and, even more sadly, with even more mistakes and corners on the wheel than CORBA.
You don't get to throw around as many buzzwords.
Unfortunately, in some circles, that seems to be an important criterion in the decision making. Personally, I prefer to use things that work and have substance, instead of chasing after silver bullets:-)
There is duplicated code on both the client and server.
Huh? You haven't been listening to my friend Don Box by any chance?;-) If that is what you are referring to, it's simply wrong (or certainly, it is wrong as Don presented it in his interview). Neither CORBA nor Ice require duplicated code on client and server--they are pure client-s
However the article is not about rolling your own ORB, it's about designing a MMORPG middleware, which can have little to nothing to do with an object broker.
Hmmm... To build a game on that scale, we needed a distribution platform of some kind. Having looked at what we needed, and having considered CORBA (which some of us knew a lot about, having previously built a commercial ORB), we knew that CORBA wasn't going to meet our requirements. So, we ended up building a new middleware.
It's quite surprising how much the middleware and its object model end up influencing game design and performance. For example, I don't think Wish could have been built without object migration, without some of the protocol features we came up with for efficient event distribution, or any number of other things. The game requirements influenced the design of the middleware, and vice-versa, so I would say that the two actually have a lot to do with each other.
In my experience this usually happens when the people involved don't really understand the problem they are trying to solve
You might want to have a look at my home page -- I think I can honestly state that I know quite a bit about middleware and the problems we are trying to solve:-)
The problem with games is that they often need both styles of comms, synchronous twoway RPC as well as event-style pub/sub comms. Any middleware that supports one but not the other is likely to be hard to use. We designed Ice such that it can do both well. (You can look at Chapters 18 & 25 of the doc for details.)
Basically, Ice supports the usual twoway, synchronous RPC, as well as oneway calls (which don't require a reply from the server), and UDP. The protocol is designed such that it is possible to build very efficient message switches for event distribution.
BTW, I used to work at DSTC with the guys who built Elvin -- it's a fine piece of work and well woth a closer look.
Flat files? Wow! I admire those people's courage:-)
For what it's worth, Ice and Wish use Berkeley DB (http://www.sleepycat.com). It's a DB with a small footprint, high performance, and good transaction support. Nice licensing conditions too -- you pay only if you want to keep your source code secret.
> "At ZeroC we used Java because some of our > development staff had little prior C++ > experience..."
Actually, this was something the copy editor messed up, unfortunately. At ZeroC, there is absolutely no shortage of C++ skills:-) The sentence was meant to read "At Mutable Realms...", where some (but not all) developers have C++ experience.
In terms of whether you want to use Ice (or another middleware product) for your game, that's up to you, of course. But taking on all the networking chores during game development (as well as all the other complex things) is a lot of work, and middleware certainly can reduce development time by a lot.
> - complexity. It is definitely not for the beginner and has a large initial learning curve. If you write client-side stuff, it is heaven. If you write server-side stuff, prepare yourself. If you want to do CORBA-compliant fault tolerance or security, don't call me:)
I wouldn't say "heaven" myself:) There are *many* issues around CORBA's complexity:
- the insanely complex C++ mapping - bloated and complex run-time APIs - inefficient protocol - far too complex type system - missing features - inefficient and overly complex object model
I've been working on Ice (www.zeroc.com) in an effort to come up with something that is as powerful as CORBA, adds some features that are sorely missing from CORBA (such as UDP support), yet is *much* simpler. To give one example, the definition of the POA API requires 211 lines of IDL. Ice has an object adapter that is just as fully featured and flexible, yet its API is defined in only 29 lines of IDL.
I think the original scenario calls for middleware, no doubt. What gets in the way is that what most people call "middleware" is far too complex and heavy-weight to be palatable, so developers get put off using middleware and endlessly re-invent the wheel by going down to raw sockets. It shouldn't have to be that way...
First, realize that if you really thought you could learn a programming language in 10 minutes, you're too stupid to be a programmer.
Spend the remaining 9 minutes 40 seconds letting that sink in.
I appreciate the point:-) Unfortunately, we have "Teach Yourself Linux in 10 Minutes" (yes, that's a real book!) The title has about as much credibility as "Lose 20kg of weight in two weeks!" Yet, it seems that people see nothing strange in what is obviously an oxymoron and buy the book anyway. (And many such impossible titles are selling in surprising numbers...)
Walk into an engineering firm or archetect firm and ask them if they want to go back to sketching blueprints.
I'm in the process of building a new house. When I started looking for architects and builders, I always asked them whether they used a CAD system for the plans, and whether they could do things like provide virtual walkthroughs for a design.
I talked to dozens of different companies and found only a single one that would use CAD for their building projects. (I didn't chose that company for other reasons.) All the other companies, guess what they do? They employ draftspersons who create and modify plans exactly as they did twenty years ago, with pencil, paper, and whiteout.
I was quite surprised by this and asked for the reasons. The common answers were:
- The learning curve is too steep. It takes more than a year for someone to get proficient enough with a CAD system to be effective.
- The cost of the software and hardware is too high.
- We tried it and the software was too stupid. It knows nothing about building regulations, will let you do impossible things, such as putting a twenty meter span for a ceiling without the appropriate supports, it cannot cope with things that we need to do routinely, such as curved stairs, etc, etc.
- The software is buggy. We had endless reliability problems and gave up in the end.
- It's too slow. A good draftsperson is faster with pencil and paper than with a CAD system.
- The overhead isn't worth it. For a small building, I can do the wiring plan in a few minutes on paper. If I use a CAD system, I spend hours having to enter all sorts of detail first, and then, most likely, I get a suboptimal wiring plan.
So, at least in the Australian housing industry, CAD systems are essentially non-existent with both builders and architects.
Fallacy 4: Programs Help Their Users Which he then says is a false because they are only focused on upgrades, money and crushing the competition. And yet, later he'll say why open source is useless. Um.
That's quoting me out of context. I stated that source is useless as insurance against a vendor going belly-up because I'm not in the business of maintaining whatever software I got from that vendor, and because I'm unlikely to have the skills to look after that source.
Fallacy 5: If It's Graphical, It's Easy CLI might be more "powerful" in the hands of a skilled user (I won't give mine up), but well done GUIs can be self explanatory
You said it. Well-done GUIs can be a joy to use. Unfortunately, the majority of GUIs I come across are not well-done. The text widget into which I'm typing this right now on this web page is a prime example. It's about 50 characters wide, and 10 lines tall. That's too little context to be useful -- I can't refer back or forward more than a few sentences. When I resize my web browser to make it larger, everything resizes but that window, which stays exactly the same size. So I'm doomed to type into this abomination with minimal context, and I don't get even the most basic functionality for text editing, such as searching or spell checking. So, quite often, I write a reply using my favourite text editor and then paste it into the widget for posting. I shouldn't have to do this.
But back to the point: the fallacy is that people are told that, just because something is graphical, it's easy. That's simply untrue. Even with a GUI, I still have to understand what I'm doing. The more complex that task I want to perform, the more I need to know, and the more complex and clutter the GUI gets. Take the average application package and try to use it. Here are a few unusability examples:
- In older versions of Word, when I did a search, the highlighted target sometimes ended up underneath the dialog box for searching. That's quite jarring, because I just pressed the "Find" button and now I'm looking at a page that doesn't have a highlight anywhere. I'm confused until I realize that the search target is probably underneath the dialog box and move the dialog box out of the way.
- In later versions of Word, the problem was "solved": when I do a search and the search target happens to be underneath the dialog box, the dialog box repositions itself such that the target is visible. What a hopelessly useless way to deal with the problem! It means that, on a document where I'm searching for a frequently-used phrase, the search dialog keeps jumping around madly without rhyme or reason.
Why not scroll the document and leave the box in place instead? For that matter, why does a search require a dialog box at all? Couldn't I just type the search string once and then have the dialog box go away? Couldn't we do away with the dialog box altogether? For example, when I pull down Edit->Search, why can't a text widget appear right there underneath my mouse pointer and automatically go away as soon as I hit Enter?
- Try Adobe Acrobat Reader and use its search function. Once you have typed a string into the dialog box and hit enter, the dialog box disappears and the search target is highlighted. Nice. To search again, I can simply hit ^G to go to the next target. Nice. Except that there is a bug in the code somewhere: if you do other things after searching, such as scrolling around or following a hyperlink, the next time you hit ^G, the dialog box reappears and you have to hit Enter as well to initiate the next search. Thereafter, every time you hit ^G, the dialog box pops back up. Really annoying, and simply a bug. But that bug has been there for years...
- I use Microsoft Outlook occasionally to connect to a mail server with SSL. The server doesn't have a properly signed certificate, so Outlook pops up a warning dialog and asks whether I want to continue. Fine. But more than half the time, the dialog box ends up underneath the main Outlook window where I can't see it! Yet, the box is modal, so Outlook itself appears to be hung. Moreover, the dialog box doesn't have a button on the toolbar, so I can't bring it to the front by clicking on its button. If I minimize Outlook, I also minimize the dialog box. Only way to get at the dialog box is to move the main Outlook window out of the way to expose it. This is atrocious design!
- I typically use several programs at once on my Windows desktop. Frequently, I initiate something, such as an FTP transfer or a compilation and then go back to doing something else, like writing email. I'm a touch typist, and I type fast. In the middle of me typing into my xterm, a dialog box pops up from nowhere to ask me something. That dialog box grabs the focus and, before I know it, several of my keystrokes have been sent to that dialog box, which obediently closes and does God knows what. This is unspeakably poor design, yet I have to put up with it on a daily basis.
There are thousands of examples along the same lines -- sometimes the desktop metaphor is used incorrectly, sometimes there is a bug, and sometimes the designer of the GUI was unbelievably incompetent. Why is it that these problems have not been addressed, even though we've had GUIs for more than 15 years?
Fallacy 6: Computers are Getting Faster Computers are getting faster, the experience is not. On my Apple ][, I could turn it on and in a matter of several seconds, be typing in a word processor. But then, it didn't have spell checking, fonts, and I couldn't make a spreadsheet larger than something like 32x64.
The computer you are using today is likely several hundred times faster than your Apple ][. Are you really suggesting that adding features such as spell checking and fonts justifies slowing the program down, even though the hardware is several hundred times faster? Are you really suggesting that it would be technically impossible to make a current-day word processor load just as quickly as the one you used back then? All that in the face of hardware that is hundreds, if not thousands of times faster, and in the face of all the progress we are supposed to have made in computing in the past 15 years? If we put our minds to it, we *can* have word processors that load in a split second, and we *can* have GUIs that are easy to use and don't spring surprises on us. But, for some reason, we don't seem to consider it worth the bother...
That said, he certainly seemed to bring up a lot of food for thought. Do you think he'd be willing to do a Slashdot Interview?
Sure, why not? That might also be a good opportunity to correct some of the misunderstandings that have come about by being quoted out of context.
By the way, did someone publish a transcript of the session or something? Some people are referring to portions of the talk in more detail than the summary that was posted in the original article (but they may have been present in person, of course). If there is such a transcript, could someone mail me the URL please?
Remember, this is one of the people behind CORBA. He would say source is useless. He wants a software world of black boxes connected together.
Interesting that you should say that. If you look up ORBacus (the product I was working on at OOC before we were acquired by IONA), you will see that it ships as source code and is available for anyone to download off the web. To say that I oppose distributing source code is simply incorrect. To say that I want a software world of black boxes connected together is simply wrong (and presumptious).
Most people have accepted that this particular promise of OO programming was hype. He hasn't.
How interesting you should say that... For the record, when Raymond Smith approached me to give this talk, he asked whether I could modify the talk a little for the audience and say something about Open Source or Linux or something along those lines. I obliged by replacing fallacy 10. Here is the text of the original fallacy 10 (with which I presented talk many times previously, including the OMG meeting in Danvers last year):
Fallacy 10
We've had objects since 1967
Object-oriented programming has by and large failed to deliver
Reuse does not happen for free
Components are not the rescue either
Neither is <insert not invented yet technology here>
You can find the original version of the talk at
http://www.gcritf.onthenet.com.au/techtalk/model ed /
The page I referred to is at
http://www.gcritf.onthenet.com.au/techtalk/model ed/sld012.htm
So, when you say that Most people have accepted that this particular promise of OO programming was hype. He hasn't. you are demonstrably wrong.
its completely arrogant to equate Brain surgery to C++. For one thing, lives are not at stake. This analogy is delusional with extreme grandeur.
After 14 years of programming with C++, I still do not consider myself an expert. After more than twenty years as a computing professional, I still only know a tiny part of what there is to know about computing. Computing is a very complex field, and design and programming of large systems appears to be one of the most complex activities people engage in. I believe that this puts computing on par in complexity with activities such as brain surgery, bridge design, or contract law. I can go to a university for a four-year degree course and come out as a qualified civil engineer. I can go to a university for a four-year degree course and come out a qualified software engineer. The time I spent acquiring the qualification is the same in both cases.
Fallacy 2: Computers Allow People to Do things They Could Not Do Otherwise
As a matter of fact, they DO empower us. With Word I can do mass mailings in an hour, instead of all day. A great word processor will do a lot of the annoying things like spellcheck and thesaurus and automatic formatting of headings and footnotes and equations - which used to be a severe drain of time. A great spreadsheet lets you analyse numbers with impressive ease - ask any accountant how much the spreadsheet has transformed their parctice. This power of analysis has allowed professionals to actually expand their business instead of being mired down in drudgery.
It takes a lot more than a good word processor to create a good document. Creating a good document requires two things:
Domain (in this case, typesetting) knowledge. Having typeset a book, I know that even the best document creation programs today are hopelessly inadequate when it comes to professional typesetting standards. This is true for Word, Frame, InterLeaf, and even TEX. Apart from the fact that all of these tools make unforgivable typesetting mistakes, I still need to know about the correct use of fonts, why I would choose a sans-serif versus a serif font, how to correctly format a bibliography, the use of kerning, the correct way to spell things (spelling checkers do not know this), the correct use of grammar, etc, etc. These are all things my word processor will not do for me.
What makes a document great isn't it's presentation (although presentation is important). What makes a document great is great content. Last time I looked, my word processor was unable to provide that content.
Fallacy 3: Computers Increase Productivity
yes, they do, if used with discipline. See above. The idiots who waste all day adding sound effects are the same ones who in eth 40's used to while the day way lobbing sharp pencils into the ceiling. Procrastination has evolved with technology but is essentially the same.
I wasn't talking about procrastination. (That's the problem when someone posts a summary of a talk that can't possibly reflect more than a tiny fraction of what I actually said.) What I pointed out here is that our programs have become feature-rich to the point where they completely overwhelm their users. Have a close look at the average word processor and multitude of feature that are in there. That's beyond the level where users are still comfortable, so much so that users resort to something known as "displacement behavior". In a nutshell, people resort to displacement behavior when they are no longer able to deal with the complexity of the actual task at hand and do something else instead that the do still understand, in order to avoid the feeling of being inadequate and to have at least some success experience. The same behavior can be seen in programmers who are given a task that is too hard for them. The typical displacement behavior exhibited by entire product teams in this case is to not solve the actual problem, but to build tools that will help them solve the problem eventually. So, an entire team goes off and builds things such as a tracing and debugging infrastructure, a container library, an error handling framework, etc, etc...
The average commercial, shrink-wrapped software package today (be that a spread sheet, word processor, presentation program, or whatever) is now so complicated that most users never use more than 5% of the features, and resort to displacement behavior in order to cope with the stress of using the package.
Fallacy 4: Programs Help Their Users
true, software companies try to ensnare their users. Also true that DVD makers try to snsnare their consumers, that groceries and airlines and car salesmen all use deceptive marketing, schemes, and even planned obsolescence to suck your wallet drier. You shoudl blame capitalism, not computers.
So, does this mean that we all should do the same thing? Two (or many) wrongs make one right? I don't think so.
Fallacy 5: If It's Graphical, It's Easy
the vast majority of GUIs make simple tasks much easier. If you think that arcane text codes and comands are easier than just clicking the Underline button, then you're a/etc/conf hacker, not someone working in an office relying on Word to get the memo done.
with a gui, you dont NEED to be a "sysadmin, programmer, typesetter, etc." to get work DONE. You just get work done. In a CLI you have to be all these things and more.
The GUI I get with Windows does not make me a sysadmin. I may choose to use a CLI or a GUI to perform sysadmin tasks, but either way, I have to understand what sysadmin is about, and the GUI does not make being a sysadmin intrinsically easier (even though a lot of marketing people claim it does). As far as word processors go, if you are a touch-typist, GUIs are terrible. They continuously force me to move my hand between the keyboard and the mouse. I'm way faster producing text draft with vi than with Word or Frame. The word processor is good at solving layout issues. As a text input and editing program, it is far less efficient than something like vi or emacs.
also, the paperclip has NEVER interrupted me to tell me a joke. Document the allegation!
On two separate occasions, the paperclip interrupted me to tell me a joke. I don't remember the exact words, but I do remember that I was absolutely incredulous that I had just been interrupted so I could read some amusing anecdote. I do not know what precise sequence of actions causes the paperclip to do this, so I cannot reproduce and document it. I'm afraid that all I can do is to give my word that this indeed happened to me.
Fallacy 6: Computers are Getting Faster
yes, they are. NO software I can buy today can really tax my 2 GHZ Pc, not even the most bloated WINXP install. My Pentium DOES boot faster than my old 386, Word loads in a few seconds, my web page is limited by my dial in connection (which i am forced to use because of monopolies and lack of regulation in telecom, not because of any computer issue). Its obvious that a Pentium 4 compiles faster than a 486, and the programs of today have more functionality anyway. EVERYTHING took FAR LONGER 5, 10 years ago.
I never said that everything was slower today. But I do notice that quite a few things are slower today than five or ten years ago. For example, the C++ compiler I use today is slower than the one I used five years ago even though the machine I run it on is maybe 500 times faster than the one I had a few years ago. Each successive generation of Frame takes longer to start up than the previous one. Each successive web browser I use is slower to start up and to render than the one I had before. I believe it is correct to say that almost all speed improvements we see in computing today are due to hardware, not software. Code bloat, poor compilers, poor libraries, poor application design, lack of knowledge on efficient algorithms and data structures, number of features (or misfeatures) -- all of these contribute to code bloat and poor run-time performance. If the hardware guys hadn't made the progress they did, we couldn't afford to run most of the programs we run today because they'd be intolerably slow. Software has easily more than compensated for all the hardware advance. Why else is it that, for every new version of Windows, I need a machine that's several times more powerful than the previous one?
Fallacy 7: Programs are Getting Better
Yes they are. True many obscure functionalities are barely used but they are there - and they barely slow things down in todays 2 GHz age.
I think whether programs are getting better depends largely on the perspective of a particular person. As a non-computing, consumer-type user of commercial software packages, I may disagree. Programs are getting more and more complex to use, harder to install, harder to uninstall, harder to keep up-to-date, are prone to virus infection, force me to keep buying bigger hardware all the time, often make it impossible to transfer customization to another computer running the same program, etc, etc. Depending on how you look at it, this can easily add up to the view that programs are getting worse. Many people have mentioned to me in the past that they wish they had a simple DOS machine again because things were easier in some ways then. I know, this is an amazing thing to say, but it is very telling. People are afraid of their own computer in many cases. When non-programmer friends ask me for help with some problem, some of them are in a continuous panic that something they touch or change may render something else unusable, forcing them to reinstall, rewrite their document, or pay exorbitant support fees to get the problem fixed. I know of many users who live with partially crippled programs that had their configuration damaged at some point in preference to try and fix and the problem, for fear of making it worse.
I dont buy the anecdote about a single hyperlink inflating a 800K document to 2.2 MB. I just tried it myself, but taking 800 K of raw text and pasting it into Word. Then i added a link. The file size difference is negligible, but dont take my word for it, TRY IT YOURSELF! And then stop propagating foolish incendiary lies.
The anecdote is real, and I wasn't lying. I can't remember which version of Word that was because this happened a few years ago. From memory, it may have been Word 95 (or it could have been Word 97, not sure anymore). At any rate, the incident did indeed happen as I described it. The point of the anecdote was not to propagate foolish incendiary lies, but to point out code and file bloat. Executables are getting larger, documents are getting larger, operating systems are getting larger, etc, etc. Sure, they do more things than they used to, so that's to be expected. Except that the rate of growth seems to be out of synch with the benefits of the new features. Software is simply no longer written as carefully as it used to be written when hardware resources were more scarce. But is it really necessary to have file sizes in the hundreds of kilobytes when the actual text message in them contains only a few thousand characters?
Fallacy 8: Programmers are Getting Better
well, if they all bitch and moan like this, maybe this really is a fallacy. But, I doubt it. Most of teh programmers I know are able to switch between languages and adapt to different environments. Most old time programmers are surgically attached to the Language of Choice for them and will never change. Look at the quality of coding being done on the Linux Kernel, in Oracle's 8i, in Windows'.NET. These are true advances in computing complexity and it is a continuing process.
My thesis is that CS graduates are, on average, less qualified today than they used to be, especially when it comes to lower abstraction levels, such as hardware principles or assembly language, and theoretical computing, such as compiler construction or complexity analysis. I keep in touch with quite a few academics who teach CS, and they generally concur with me in this. The reason is that universities are forced to teach things today as part of a course they didn't have to teach previously, so they are spreading themselves thinner. And curricula drop topics that were once considered de rigeur, such as computational theory, in favour of trivial things, such as HTML. When I wrote my honous thesis, I was told that it had to be typeset. I asked how to do that and was told "man troff". A few weeks later, I knew the basics of typesetting and had taught myself enough of troff, pic, eqn, and tbl to get by. I never received any credit points for this -- it was expected that I would learn these things as part of my normal study. These days, I can enrol in a course that teaches HTML programming and get credit points for it. The time I spend in that course is time I will not spend in a course on computational theory, or assembly language (if one is still available).
BTW, ANY student who majors in CS will know what a core dump is, dont be alarmist. Any student who isnt CS, has no reason to know. So what?
As a matter of fact, I have met quite a few CS graduates who did not know what a core dump is, or what to do with it, and who had no idea of basic things such as demand paging, how a general-purpose memory allocator works, or how a CPU arranges memory into segements. They could draw pretty UML diagrams though, I admit...
the jab about knowing how to write excel memos being a mark of qualification is just arrogant snobbery.
It's an exaggeration, but not snobbery. We routinely ask programmers (especially graduates) to do things they are in no way qualified to do. Projects are routinely staffed with underqualified people. I've been on more than one project where the job of writing an X11 GUI was given to a person who had never written a GUI before. I've been on projects where the person who was supposed to produce our testing strategy and design unit and system tests had never written a line of code. As long as we make mistakes like this, people will write poor code, produce poor designs, get frustrated on the job, and suffer burn-out. Read Fred Brook's "The Mythical Man Month" and then read Ed Yourdon's "The Death March", which was written about twenty years later. The messages about project management failures in the two books are largely identical. I can only conclude that the sum total of what we have learned about software project management in those twenty years is very close to zero.
And the average retention time is from the dotcom boom, it surely isnt true anymore. YOu have a problem with people cashing in on their skills while they could?
This statistic actually predates the dotcom boom by nearly ten years. I don't have more recent figures, but looking around me, I rarely find a person who has been with the same company for more than three years, but I continuously find people who have been with a company for less than 18 months.
Fallacy 9: Programming is About Date Structures and Algorithms
this is an extremely provincial accusation - probably better to just nod and agree with you rather than set off a religious war.
Agreed that programmers are not taught to design. Well, who taught you? If experience sufficed for you to become a self-declared expert, then it will suffice for others also.
Data structures and algorithms are important, but only one small aspect of programming. Design, especially interface design (both human-machine interfaces and API design) are probably more important than data structures and algorithms because, as programmers, we spend a huge amount of time building such interfaces. Yet, these skills are by and large not taught at universities, or taught only as an afterthought. To say that if could learn by experience, other people can do it too is correct, but misses the point: it's like saying than continuing to do it the hard way (and clumsily) is good enough. Why shouldn't we teach something that's so important to CS students?
Fallacy 10: Open Source is the Answer
The Answer? The Answer to what? with apologies to DOuglas Adams, first off you better figure out just what the Question is!
Not long ago, I remember quite a few people telling the world at large that, not long from now, all software will be free and Open Source, and that commercial software production is dying. So far, their predications have not come true, and I don't think they ever will. Open Source is great for some things, and not so great for others. For example, a large part of the world's software are embedded code that does things such as control air conditioners, manage the engine in my car, make the lift stop at the right floor, and so on. I am not aware of any Open Source implementations of such software. The motivation for making such code Open Source isn't there, it's not sexy enough, the code is too specialized, a "make money by providing support" economic model won't work, etc. And, let's face it, Open Source is subject to many of the same flaws that closed software is. Just because someone writes Open Source, that doesn't make them a good designer or a good programmer. There are bad pieces of Open Source around, just as there are good ones.
99% of all documents are written to be printed on paper.
Hell, no! 99% of documents (besides programs) I write are emails.
I'm not nitpicking, this is a major flaw in the argument.
This may be true for you (and it's true for me). It's probably true for the vast majority of programmers. Is it true for the vast majority of MS Word users? I doubt that very much. The vast majority of MS Word users use the program to write assignments, business correspondence, research papers (in a field other than computing!), love letters, etc. Those documents, in almost every case, get printed out, so embedded video or sound clips, and embedded links that launch programs are of dubious value then.
Were you present at the talk? I don't know, of course, but if you were, I doubt you would have said what you did. A few points:
1) The talk was a keynote. People don't go to keynotes to learn about a new algorithm or to listen to an hour-long marketing presentation. Instead, they go to get some insight, a new angle, to be entertained, to have a good laugh, and so on (possibly, all of the above). So, I put together a keynote that I thought would be entertaining and funny, provide an unusual angle, and would do this with enough substance to avoid boredom. I think the keynote achieved that.
2) I don't think the argument is shallow. I've been a computer professional for more than twenty years, and the topics I touched on during the keynote arose from experience. I have given this talk at quite a few conferences all over the world -- the feedback I get indicates that these issues touch a chord with people. Many people have written to me afterwards to tell me that the talk changed the way they look at their profession and has changed their daily lives.
3) I believe that what I presented is indeed based on fact. The problems I point out are real, not just made up. Yes, I did exaggerate in places. After all, the talk is meant to be provocative. I am an OS and distributed computing expert with post-graduate qualifications and more than two decades of programming experience. Yet, my Windows PC effortlessly brings me to the brink of nervous breakdown on a regular basis and reduces me to a helpless wreck, making me feel like an idiot. If I, as an expert, am left helpless in the face of some problem, what chance has a non-computing person got? There are very real and definite problems with our software, so much so that experts often can't fix things. That's a far cry from the empowering device we would like our computers to be.
Hmmm... I think a big problem here is that my comments were taken somewhat out of context. This wasn't about blasting Open Source at all, but to simply illustrate that Open Source can't satisfy all of the world's software needs. A lot of code we need, such as aircon controllers, engine management systems, etc. is too specialized and not sexy enough to attract Open Source developers. So, such source will continue to be written for monetary compensation. Open Source is great -- without it, I wouldn't be able to run my business. But I thought it would be worthwhile pointing out that (like any other model), the Open Source model isn't without problems and that its proponents (just like its opponents) sometimes use arguments that don't stand up under closer examination.
Seeing that I set off such a storm, I thought it would be best to clarify what I said (and meant) when I said "Source code is useless."
First up: the entire talk is meant to be provocative and entertaining, and to get people to think about things that normally tend to get swept under the carpet. So, when I put up something like "Source code is useless", at least I know I got their attention:-)
So, here is why I said this:
One of the often recited arguments in favor of Open Source is that having the source code is insurance against things such as the vendor going out of business or deciding to no longer maintain a product: because I have the source, I'm no longer subject to vendor lock-in.
For the vast majority of commercial software development situations, I think this argument is severely flawed. Consider the following scenario (substitute any other large and complex piece of software for an ORB, if you wish):
My company builds stock broking software that allows stock brokers to trade on-line, monitor portfolios, etc. The application runs on many machines, including handhelds. Because there is a lot of distributed computing going on there, I've decided to use a CORBA ORB from vendor X as my RPC platform. A year later, after deploying my application on thousands of machines at dozens of customer sites, vendor X goes out of business. No problem: vendor X gave me the source code, so I can just continue to use the ORB and maintain it myself...
Wrongo: I'm into building stock broking applications, not ORBs. Moreover, I do not have the in-house programming skills that are required to maintain a networking product such as an ORB -- my programmers are good at writing financial models and don't know much about sockets, IIOP, threading models, and the like. Besides, there's well over 100,000 lines of C++ code in the ORB; it takes months to get a feel for how that code base hangs together and to even begin to understand it.
But let's assume for the moment that I do have skilled programmers who do understand sockets programming and threading, and that I am even willing to pay them to work on the ORB instead of my application. Will that help me? Not likely. For the ORB to remain useful to me in the future, I will not only need the occasional bug fix, but I will also need to port it to new hardware, OS, and compilers. (It's depressing how often the code needs changing just because a new compiler version appears.) So, apart from the skills required to fix the odd bug, my programmers will require deep understanding of the code (and all the subtle hacks that have crept into the code over the years to work around various bugs in compilers and libraries); without such deep understanding of the code, my programmers won't be able to port it. But let's assume my programmers are so clever that they can do that, and that I am rich enough to afford paying them for it. Will that mean that I'm going to keep using the ORB from vendor X? Not likely. Here is why:
For the ORB to remain useful (and for my application to remain competitive), the ORB must track the OMG specifications and support new features as they are being standardized. Adding new features to an ORB is technically non-trivial. (For example, the OMG recently standardized asynchronous messaging; adding that functionality to an ORB requires large and intrusive architechtural changes and thousands of lines of code.) But let's assume that my programmers are so good that they can do all that, and that I'm still rich enough to afford it.
Will I keep the ORB? Not likely:
The CORBA spec runs to thousands of pages, much of it containing highly complex (and sometimes highly obscure) material. To effectively maintain an ORB, I need to know most of the spec pretty much by heart. It takes many months (years?) to become conversant enough with all of CORBA's nooks and crannies to correctly reflect those semantics in code. But let's assume my programmers are so clever that they can do all this, and that I'm still rich enough to afford it. Will I keep the ORB? Not likely:
To effectively implement the specification, I not only need the specification, I need to contribute to writing it and, once it is written, I need to contribute to maintaining it (yes, specifications have bugs and require maintenance just like code). To do this effectively, I have to participate in the OMG process. This not only means becoming an OMG member (which isn't cheap), it also means attending meetings all over the world, devoting large amounts of time to participate in task forces and to respond to RFPs, and to engage in long drawn-out discussions and lobbying with other members to make sure that some proposed new feature doesn't make a mess of my ORB architecture.
The above illustrates why I said what I did: pragmatically, the source code is useless to me. Remember, I originally was in the business of building and selling a stock-broking application. By keeping the ORB, I'm committing myself to paying three or four full-time staff members to look after the ORB, at a cost of several hundred thousand dollars a year. (And that is assuming that I have staff members who are sufficiently competent in CORBA technology, which is unlikely to be the case.)
When vendor X goes out of business, the realistic course of action for me is to shrug my shoulders and to find another ORB from a vendor who I think won't go out of business. That's far more cost-effective than hacking around in a large code base that I don't understand and that isn't directly relevant to my core business.
Whether we are talking about a CORBA ORB or some other piece of code here, such as a compiler, container library, database, or whatever, the reality is that all these bits of technology are far to complex and specialized for me (as an application developer, that is, a user of the technology) to be able to do anything useful with the source code.
Of course, none of this means that Open Source is bad, or useless. Far from it. But it does mean that, for the vast majority of Open Source customers, the source provides little (if any) insurance. Open Source projects do shut down occasionally, just as vendors occasionally go out of business. When that happens, I'm hosed, source code or not.
Slashdot Mirror
Some time in the past twelve hours, the ToS was updated. There is no longer any trace of the recording clause.
There is still a clause that requires me to waive my right to participate in a class action though. I can sue EventBrite only individually, not as part of a class action. (It appears that no-one, for any reason, whether merchant or customer, can ever pursue them in a class action under that ToS.)
Readers may also be interested in my comments on that paper.
Cheers,
Michi.
> The big problem with IDL-based RPC is that it becomes essentially impossible to version your APIs.
s ue8.pdf "Can a Leopard Change its Spots?" for a versioning mechanism that allows you to seamlessly version an application without breaking backward compatibility.
That is true for CORBA, but it is not true for Ice. Have a look at http://www.triodia.com/staff/michi/connections/is
Cheers,
Michi.
> So, CORBA is like Java. Ubiquitous in big companies and capable of producing highly scalable systems with excellent reliability
Yes, agree. And CORBA does it at several times the development cost, defect count, memory footprint, and performance overhead than what is necessary.
Cheers,
Michi.
> Hennings opinions should be taken with a pinch of salt. While he co-authored the bet known book on CORBA, he has since left the CORBA arena following the merger of his own company with IONA, and is now pushing an alternative technology called ICE.
b a/browse_frm/thread/6f47a3d21cd0d9dc/f597718937b8a 3f3?lnk=st&q=3eXDf.916%24k6.18007%40nasal.pacific. net.au&rnum=1&hl=en#f597718937b8a3f3).
:-)
Correct--I decided to do something better than CORBA after slaving my guts out for seven years trying to make CORBA better, and largely getting nowhere. Eventually, I realized that there was only so much sh*t I could push uphill and decided to focus my efforts on something more productive.
> The concepts like the POA are too over engineered, but the underlying ideas of language neutrality, a simple interface definition language and a common wire protocol have not been bettered.
I beg to differ. The CORBA POA interface requires over 200 lines of IDL definitions when, in fact, I can provide all of the functionality of the POA, plus some extra, in just over 30 lines.
Yes, language neutrality is a good idea. No, CORBA IDL is *not* simple, not by a long shot. (Look at the last section of the Slice chapter in the Ice manual for some of the reasons.)
IIOP is a very poorly designed protocol that has more flaws than a dog has fleas. Among them a quite major one that prevents efficient implementation of notification services. (See the Ice manual for details.)
> One area where CORBA is particularily useful, is in event or notification based systems.
The CORBA event and notification service are interface nightmares, and cannot be efficiently implemented due to design flaws in IIOP. (See http://groups.google.com.au/group/comp.object.cor
> Most recently, I used CORBA to replace a SOAP based system. Compared to SOAP, the CORBA based system was faster, easier to work with and far more reliable.
I don't doubt that. It's very hard to beat the ineptitude of SOAP and WS. Now, if you had used Ice to do the same thing, you would probably have done it in half the time, with half the pain, and twice the performance
Cheers,
Michi.
Having been involved quite deeply in the OMG, I would beg to differ. Especially in the early days, a single company could highjack proceedings simply by threatening to withdraw from the consortium. If any one of the big players at the time had indeed withdrawn, it would have spelled disaster. So, on occasion, one of the big companies got their way after threatening to withdraw...
Later, it wasn't so easy to hold the organization to ransom, and outright blackmail was replaced by political maneuvring. I remember many occasions where the contents of a world-wide standard depended not on technical merit, but much more on who went drinking with whom at the hotel bar the night before the vote.
Cheers,
Michi.
Trust me: Ice is better than CORBA, and by more than just a little bit :-)
Unfortunately, Ruby has threading issues that prevent an Ice implementation for it. Otherwise, we would have done a Ruby binding long ago.
Cheers,
Michi.
Web services were never designed to solve this sort of problem. They were never focused on the needs of a performance-critical, real time system like a MMORPG, but rather on doing things like swapping data between corporations and driving Web sites.
The bandwidth and CPU cycles consumed by SOAP are nothing short of staggering. (Look at the archives in comp.object.corba for some calculations.) SOAP easily eats 10-100 times the bandwidth of IIOP (and IIOP isn't particularly good at conserving bandwidth either--Ice does a much better job of that). With SOAP's bandwidth requirements, there is no way we could have made Wish work over an ordinary 56kB modem.
Web services is basically CORBA ten years ago, with a different implementation (XML, SOAP, etc.) that should hopefully work better than CORBA's baroque design-by-committee industry standards. But behind all the buzzwords, we're still talking about the same basic sorts of distributed technology.
I agree that WS is basically CORBA all over again, but I very much doubt that it will work better than CORBA. True, CORBA has indeed suffered badly from design-by-committee, but WS seems to be headed for the same fate. And I watch people make the same mistakes all over again with Web Services. It's disheartening really: instead of learning from the painful lessons of the past, we forge ahead and make the same mistakes again. Partly, that's because, by the time a new technology gains enough momentum to challenge the previous technology, the veterans (who have the experience with the old technology to really work out how to do it better this time) have moved on; and the new people now working on the new technology don't have all the experience of the veterans and then promptly fall into the same old traps...
Cheers,
Michi.
why does the author constantly mention CORBA? Perhaps I'm not familiar enough with the Java perspective, but I assumed CORBA/COM (etc) were basically dead (or dying) when it came to modern internet programming.
That's a fair question. Looking at the requirements, we needed middleware that is language- and platform-independent. That immediately rules out things such as COM, DCOM, RMI, and .NET. CORBA really was the only candidate. Also, all of us (the people who wrote Ice) had a lot of CORBA experience, and Ice borrows a lot of ideas from CORBA. (No, not everything in CORBA is bad ;-) So, I ended up contrasting things to CORBA because Ice is both similar and different to CORBA.
CORBA isn't exactly dead--people are still building industrial-strength systems with it. And, to be fair, CORBA is the most widely-used distribution technology to date. It's just that CORBA is ageing and that, after more than ten years of experience, we now know how to do better and avoid CORBA's mistakes.
The author and company were only familiar with CORBA.
No, not really. I have experience with Sun RPC, DCE, COM, DCOM, Web Services, and CORBA.
Distributed-objects are an older, more established technology. [ie proven]
There are a lot of existing systems, algorithms, ideas, programs, etc. to build a distributed-object system.
Yes, to are large extent. There is a lot of experience we have gained over the past ten years or so on how to build distributed systems that work.
It masks the network from the API (yes, this should be a CON).
That's an old topic that comes up periodically. The most-quoted paper on that topic is probably A Note on Distributed Computing. Personally, I disagree with many of the conclusions in that paper. True, I can't afford to forget that there is a network underneath my API because the semantics are truly different from the non-distributed case. But that does not strike me as a compelling reason to make a remote invocation substantially different from a local one.
Engineering effort is required to make sure clients can access the model with any langauge, and also to allow designers flexibility in the object model. Most of this should be cheaper with a web-services model.
I don't see where web services would be cheaper than any other language-agnostic platform. In fact, everything I have seen so far about web services is more complex than Ice (or CORBA). And web services are horribly inefficient. If you are interested, look for my postings on the topic in comp.object.corba with Deja.
The reason we have web services (or, more accurately, might have them some day) is a political one rather than a technical one: back in the hey-days of the distributed computing war between CORBA and DCOM, Microsoft were about to lose the battle. They weren't going to simply cede the battlefield to the OMG so, rather than fight a war they couldn't win, they simply created a new battlefield. Sadly, web services is about re-inventing the distributed object wheel all over again and, even more sadly, with even more mistakes and corners on the wheel than CORBA.
You don't get to throw around as many buzzwords.
Unfortunately, in some circles, that seems to be an important criterion in the decision making. Personally, I prefer to use things that work and have substance, instead of chasing after silver bullets :-)
There is duplicated code on both the client and server.
Huh? You haven't been listening to my friend Don Box by any chance? ;-) If that is what you are referring to, it's simply wrong (or certainly, it is wrong as Don presented it in his interview). Neither CORBA nor Ice require duplicated code on client and server--they are pure client-s
However the article is not about rolling your own ORB, it's about designing a MMORPG middleware, which can have little to nothing to do with an object broker.
Hmmm... To build a game on that scale, we needed a distribution platform of some kind. Having looked at what we needed, and having considered CORBA (which some of us knew a lot about, having previously built a commercial ORB), we knew that CORBA wasn't going to meet our requirements. So, we ended up building a new middleware.
It's quite surprising how much the middleware and its object model end up influencing game design and performance. For example, I don't think Wish could have been built without object migration, without some of the protocol features we came up with for efficient event distribution, or any number of other things. The game requirements influenced the design of the middleware, and vice-versa, so I would say that the two actually have a lot to do with each other.
In my experience this usually happens when the people involved don't really understand the problem they are trying to solve
You might want to have a look at my home page -- I think I can honestly state that I know quite a bit about middleware and the problems we are trying to solve :-)
Cheers,
Michi.
The problem with games is that they often need both styles of comms, synchronous twoway RPC as well as event-style pub/sub comms. Any middleware that supports one but not the other is likely to be hard to use. We designed Ice such that it can do both well. (You can look at Chapters 18 & 25 of the doc for details.)
Basically, Ice supports the usual twoway, synchronous RPC, as well as oneway calls (which don't require a reply from the server), and UDP. The protocol is designed such that it is possible to build very efficient message switches for event distribution.
BTW, I used to work at DSTC with the guys who built Elvin -- it's a fine piece of work and well woth a closer look.
Cheers,
Michi.
See this link for a properly printable version.
Flat files? Wow! I admire those people's courage :-)
For what it's worth, Ice and Wish use Berkeley DB (http://www.sleepycat.com). It's a DB with a small footprint, high performance, and good transaction support. Nice licensing conditions too -- you pay only if you want to keep your source code secret.
Cheers,
Michi.
> "At ZeroC we used Java because some of our
:-) The sentence was meant to read "At Mutable Realms...", where some (but not all) developers have C++ experience.
> development staff had little prior C++
> experience..."
Actually, this was something the copy editor messed up, unfortunately. At ZeroC, there is absolutely no shortage of C++ skills
In terms of whether you want to use Ice (or another middleware product) for your game, that's up to you, of course. But taking on all the networking chores during game development (as well as all the other complex things) is a lot of work, and middleware certainly can reduce development time by a lot.
Cheers,
Michi.
You can find a PDF version of the full article (exactly as printed in the magazine) here.
Cheers,
Michi.
> - complexity. It is definitely not for the beginner and has a large initial learning curve. If you write client-side stuff, it is heaven. If you write server-side stuff, prepare yourself. If you want to do CORBA-compliant fault tolerance or security, don't call me :)
:) There are *many* issues around CORBA's complexity:
I wouldn't say "heaven" myself
- the insanely complex C++ mapping
- bloated and complex run-time APIs
- inefficient protocol
- far too complex type system
- missing features
- inefficient and overly complex object model
I've been working on Ice (www.zeroc.com) in an effort to come up with something that is as powerful as CORBA, adds some features that are sorely missing from CORBA (such as UDP support), yet is *much* simpler. To give one example, the definition of the POA API requires 211 lines of IDL. Ice has an object adapter that is just as fully featured and flexible, yet its API is defined in only 29 lines of IDL.
I think the original scenario calls for middleware, no doubt. What gets in the way is that what most people call "middleware" is far too complex and heavy-weight to be palatable, so developers get put off using middleware and endlessly re-invent the wheel by going down to raw sockets. It shouldn't have to be that way...
Cheers,
Michi.
First, realize that if you really thought you could learn a programming language in 10 minutes, you're too stupid to be a programmer.
Spend the remaining 9 minutes 40 seconds letting that sink in.
I appreciate the point
Cheers,
Michi.
I'm in the process of building a new house. When I started looking for architects and builders, I always asked them whether they used a CAD system for the plans, and whether they could do things like provide virtual walkthroughs for a design.
I talked to dozens of different companies and found only a single one that would use CAD for their building projects. (I didn't chose that company for other reasons.) All the other companies, guess what they do? They employ draftspersons who create and modify plans exactly as they did twenty years ago, with pencil, paper, and whiteout.
I was quite surprised by this and asked for the reasons. The common answers were:
- The learning curve is too steep. It takes more than a year for someone to get proficient enough with a CAD system to be effective.
- The cost of the software and hardware is too high.
- We tried it and the software was too stupid. It knows nothing about building regulations, will let you do impossible things, such as putting a twenty meter span for a ceiling without the appropriate supports, it cannot cope with things that we need to do routinely, such as curved stairs, etc, etc.
- The software is buggy. We had endless reliability problems and gave up in the end.
- It's too slow. A good draftsperson is faster with pencil and paper than with a CAD system.
- The overhead isn't worth it. For a small building, I can do the wiring plan in a few minutes on paper. If I use a CAD system, I spend hours having to enter all sorts of detail first, and then, most likely, I get a suboptimal wiring plan.
So, at least in the Australian housing industry, CAD systems are essentially non-existent with both builders and architects.
Fallacy 4: Programs Help Their Users Which he then says is a false because they are only focused on upgrades, money and crushing the competition. And yet, later he'll say why open source is useless. Um.
That's quoting me out of context. I stated that source is useless as insurance against a vendor going belly-up because I'm not in the business of maintaining whatever software I got from that vendor, and because I'm unlikely to have the skills to look after that source.
Fallacy 5: If It's Graphical, It's Easy CLI might be more "powerful" in the hands of a skilled user (I won't give mine up), but well done GUIs can be self explanatory
You said it. Well-done GUIs can be a joy to use. Unfortunately, the majority of GUIs I come across are not well-done. The text widget into which I'm typing this right now on this web page is a prime example. It's about 50 characters wide, and 10 lines tall. That's too little context to be useful -- I can't refer back or forward more than a few sentences. When I resize my web browser to make it larger, everything resizes but that window, which stays exactly the same size. So I'm doomed to type into this abomination with minimal context, and I don't get even the most basic functionality for text editing, such as searching or spell checking. So, quite often, I write a reply using my favourite text editor and then paste it into the widget for posting. I shouldn't have to do this.
But back to the point: the fallacy is that people are told that, just because something is graphical, it's easy. That's simply untrue. Even with a GUI, I still have to understand what I'm doing. The more complex that task I want to perform, the more I need to know, and the more complex and clutter the GUI gets. Take the average application package and try to use it. Here are a few unusability examples:
- In older versions of Word, when I did a search, the highlighted target sometimes ended up underneath the dialog box for searching. That's quite jarring, because I just pressed the "Find" button and now I'm looking at a page that doesn't have a highlight anywhere. I'm confused until I realize that the search target is probably underneath the dialog box and move the dialog box out of the way.
- In later versions of Word, the problem was "solved": when I do a search and the search target happens to be underneath the dialog box, the dialog box repositions itself such that the target is visible. What a hopelessly useless way to deal with the problem! It means that, on a document where I'm searching for a frequently-used phrase, the search dialog keeps jumping around madly without rhyme or reason.
Why not scroll the document and leave the box in place instead? For that matter, why does a search require a dialog box at all? Couldn't I just type the search string once and then have the dialog box go away? Couldn't we do away with the dialog box altogether? For example, when I pull down Edit->Search, why can't a text widget appear right there underneath my mouse pointer and automatically go away as soon as I hit Enter?
- Try Adobe Acrobat Reader and use its search function. Once you have typed a string into the dialog box and hit enter, the dialog box disappears and the search target is highlighted. Nice. To search again, I can simply hit ^G to go to the next target. Nice. Except that there is a bug in the code somewhere: if you do other things after searching, such as scrolling around or following a hyperlink, the next time you hit ^G, the dialog box reappears and you have to hit Enter as well to initiate the next search. Thereafter, every time you hit ^G, the dialog box pops back up. Really annoying, and simply a bug. But that bug has been there for years...
- I use Microsoft Outlook occasionally to connect to a mail server with SSL. The server doesn't have a properly signed certificate, so Outlook pops up a warning dialog and asks whether I want to continue. Fine. But more than half the time, the dialog box ends up underneath the main Outlook window where I can't see it! Yet, the box is modal, so Outlook itself appears to be hung. Moreover, the dialog box doesn't have a button on the toolbar, so I can't bring it to the front by clicking on its button. If I minimize Outlook, I also minimize the dialog box. Only way to get at the dialog box is to move the main Outlook window out of the way to expose it. This is atrocious design!
- I typically use several programs at once on my Windows desktop. Frequently, I initiate something, such as an FTP transfer or a compilation and then go back to doing something else, like writing email. I'm a touch typist, and I type fast. In the middle of me typing into my xterm, a dialog box pops up from nowhere to ask me something. That dialog box grabs the focus and, before I know it, several of my keystrokes have been sent to that dialog box, which obediently closes and does God knows what. This is unspeakably poor design, yet I have to put up with it on a daily basis.
There are thousands of examples along the same lines -- sometimes the desktop metaphor is used incorrectly, sometimes there is a bug, and sometimes the designer of the GUI was unbelievably incompetent. Why is it that these problems have not been addressed, even though we've had GUIs for more than 15 years?
Fallacy 6: Computers are Getting Faster Computers are getting faster, the experience is not. On my Apple ][, I could turn it on and in a matter of several seconds, be typing in a word processor. But then, it didn't have spell checking, fonts, and I couldn't make a spreadsheet larger than something like 32x64.
The computer you are using today is likely several hundred times faster than your Apple ][. Are you really suggesting that adding features such as spell checking and fonts justifies slowing the program down, even though the hardware is several hundred times faster? Are you really suggesting that it would be technically impossible to make a current-day word processor load just as quickly as the one you used back then? All that in the face of hardware that is hundreds, if not thousands of times faster, and in the face of all the progress we are supposed to have made in computing in the past 15 years? If we put our minds to it, we *can* have word processors that load in a split second, and we *can* have GUIs that are easy to use and don't spring surprises on us. But, for some reason, we don't seem to consider it worth the bother...
Cheers,
Michi.
Sure, why not? That might also be a good opportunity to correct some of the misunderstandings that have come about by being quoted out of context.
By the way, did someone publish a transcript of the session or something? Some people are referring to portions of the talk in more detail than the summary that was posted in the original article (but they may have been present in person, of course). If there is such a transcript, could someone mail me the URL please?
Interesting that you should say that. If you look up ORBacus (the product I was working on at OOC before we were acquired by IONA), you will see that it ships as source code and is available for anyone to download off the web. To say that I oppose distributing source code is simply incorrect. To say that I want a software world of black boxes connected together is simply wrong (and presumptious).
Most people have accepted that this particular promise of OO programming was hype. He hasn't.
How interesting you should say that... For the record, when Raymond Smith approached me to give this talk, he asked whether I could modify the talk a little for the audience and say something about Open Source or Linux or something along those lines. I obliged by replacing fallacy 10. Here is the text of the original fallacy 10 (with which I presented talk many times previously, including the OMG meeting in Danvers last year):
Fallacy 10
You can find the original version of the talk at
http://www.gcritf.onthenet.com.au/techtalk/mode
The page I referred to is atl ed /sld012.htm
http://www.gcritf.onthenet.com.au/techtalk/mode
So, when you say that Most people have accepted that this particular promise of OO programming was hype. He hasn't. you are demonstrably wrong.
Cheers,
Michi.
Brain Surgery in 14 Easy Lessons
its completely arrogant to equate Brain surgery to C++. For one thing, lives are not at stake. This analogy is delusional with extreme grandeur.
After 14 years of programming with C++, I still do not consider myself an expert. After more than twenty years as a computing professional, I still only know a tiny part of what there is to know about computing. Computing is a very complex field, and design and programming of large systems appears to be one of the most complex activities people engage in. I believe that this puts computing on par in complexity with activities such as brain surgery, bridge design, or contract law. I can go to a university for a four-year degree course and come out as a qualified civil engineer. I can go to a university for a four-year degree course and come out a qualified software engineer. The time I spent acquiring the qualification is the same in both cases.
Fallacy 2: Computers Allow People to Do things They Could Not Do Otherwise
As a matter of fact, they DO empower us. With Word I can do mass mailings in an hour, instead of all day. A great word processor will do a lot of the annoying things like spellcheck and thesaurus and automatic formatting of headings and footnotes and equations - which used to be a severe drain of time. A great spreadsheet lets you analyse numbers with impressive ease - ask any accountant how much the spreadsheet has transformed their parctice. This power of analysis has allowed professionals to actually expand their business instead of being mired down in drudgery.
It takes a lot more than a good word processor to create a good document. Creating a good document requires two things:
Fallacy 3: Computers Increase Productivity
yes, they do, if used with discipline. See above. The idiots who waste all day adding sound effects are the same ones who in eth 40's used to while the day way lobbing sharp pencils into the ceiling. Procrastination has evolved with technology but is essentially the same.
I wasn't talking about procrastination. (That's the problem when someone posts a summary of a talk that can't possibly reflect more than a tiny fraction of what I actually said.) What I pointed out here is that our programs have become feature-rich to the point where they completely overwhelm their users. Have a close look at the average word processor and multitude of feature that are in there. That's beyond the level where users are still comfortable, so much so that users resort to something known as "displacement behavior". In a nutshell, people resort to displacement behavior when they are no longer able to deal with the complexity of the actual task at hand and do something else instead that the do still understand, in order to avoid the feeling of being inadequate and to have at least some success experience. The same behavior can be seen in programmers who are given a task that is too hard for them. The typical displacement behavior exhibited by entire product teams in this case is to not solve the actual problem, but to build tools that will help them solve the problem eventually. So, an entire team goes off and builds things such as a tracing and debugging infrastructure, a container library, an error handling framework, etc, etc...
The average commercial, shrink-wrapped software package today (be that a spread sheet, word processor, presentation program, or whatever) is now so complicated that most users never use more than 5% of the features, and resort to displacement behavior in order to cope with the stress of using the package.
Fallacy 4: Programs Help Their Users
true, software companies try to ensnare their users. Also true that DVD makers try to snsnare their consumers, that groceries and airlines and car salesmen all use deceptive marketing, schemes, and even planned obsolescence to suck your wallet drier. You shoudl blame capitalism, not computers.
So, does this mean that we all should do the same thing? Two (or many) wrongs make one right? I don't think so.
Fallacy 5: If It's Graphical, It's Easy
the vast majority of GUIs make simple tasks much easier. If you think that arcane text codes and comands are easier than just clicking the Underline button, then you're a
with a gui, you dont NEED to be a "sysadmin, programmer, typesetter, etc." to get work DONE. You just get work done. In a CLI you have to be all these things and more.
The GUI I get with Windows does not make me a sysadmin. I may choose to use a CLI or a GUI to perform sysadmin tasks, but either way, I have to understand what sysadmin is about, and the GUI does not make being a sysadmin intrinsically easier (even though a lot of marketing people claim it does). As far as word processors go, if you are a touch-typist, GUIs are terrible. They continuously force me to move my hand between the keyboard and the mouse. I'm way faster producing text draft with vi than with Word or Frame. The word processor is good at solving layout issues. As a text input and editing program, it is far less efficient than something like vi or emacs.
also, the paperclip has NEVER interrupted me to tell me a joke. Document the allegation!
On two separate occasions, the paperclip interrupted me to tell me a joke. I don't remember the exact words, but I do remember that I was absolutely incredulous that I had just been interrupted so I could read some amusing anecdote. I do not know what precise sequence of actions causes the paperclip to do this, so I cannot reproduce and document it. I'm afraid that all I can do is to give my word that this indeed happened to me.
Fallacy 6: Computers are Getting Faster
yes, they are. NO software I can buy today can really tax my 2 GHZ Pc, not even the most bloated WINXP install. My Pentium DOES boot faster than my old 386, Word loads in a few seconds, my web page is limited by my dial in connection (which i am forced to use because of monopolies and lack of regulation in telecom, not because of any computer issue). Its obvious that a Pentium 4 compiles faster than a 486, and the programs of today have more functionality anyway. EVERYTHING took FAR LONGER 5, 10 years ago.
I never said that everything was slower today. But I do notice that quite a few things are slower today than five or ten years ago. For example, the C++ compiler I use today is slower than the one I used five years ago even though the machine I run it on is maybe 500 times faster than the one I had a few years ago. Each successive generation of Frame takes longer to start up than the previous one. Each successive web browser I use is slower to start up and to render than the one I had before. I believe it is correct to say that almost all speed improvements we see in computing today are due to hardware, not software. Code bloat, poor compilers, poor libraries, poor application design, lack of knowledge on efficient algorithms and data structures, number of features (or misfeatures) -- all of these contribute to code bloat and poor run-time performance. If the hardware guys hadn't made the progress they did, we couldn't afford to run most of the programs we run today because they'd be intolerably slow. Software has easily more than compensated for all the hardware advance. Why else is it that, for every new version of Windows, I need a machine that's several times more powerful than the previous one?
Fallacy 7: Programs are Getting Better
Yes they are. True many obscure functionalities are barely used but they are there - and they barely slow things down in todays 2 GHz age.
I think whether programs are getting better depends largely on the perspective of a particular person. As a non-computing, consumer-type user of commercial software packages, I may disagree. Programs are getting more and more complex to use, harder to install, harder to uninstall, harder to keep up-to-date, are prone to virus infection, force me to keep buying bigger hardware all the time, often make it impossible to transfer customization to another computer running the same program, etc, etc. Depending on how you look at it, this can easily add up to the view that programs are getting worse. Many people have mentioned to me in the past that they wish they had a simple DOS machine again because things were easier in some ways then. I know, this is an amazing thing to say, but it is very telling. People are afraid of their own computer in many cases. When non-programmer friends ask me for help with some problem, some of them are in a continuous panic that something they touch or change may render something else unusable, forcing them to reinstall, rewrite their document, or pay exorbitant support fees to get the problem fixed. I know of many users who live with partially crippled programs that had their configuration damaged at some point in preference to try and fix and the problem, for fear of making it worse.
I dont buy the anecdote about a single hyperlink inflating a 800K document to 2.2 MB. I just tried it myself, but taking 800 K of raw text and pasting it into Word. Then i added a link. The file size difference is negligible, but dont take my word for it, TRY IT YOURSELF! And then stop propagating foolish incendiary lies.
The anecdote is real, and I wasn't lying. I can't remember which version of Word that was because this happened a few years ago. From memory, it may have been Word 95 (or it could have been Word 97, not sure anymore). At any rate, the incident did indeed happen as I described it. The point of the anecdote was not to propagate foolish incendiary lies, but to point out code and file bloat. Executables are getting larger, documents are getting larger, operating systems are getting larger, etc, etc. Sure, they do more things than they used to, so that's to be expected. Except that the rate of growth seems to be out of synch with the benefits of the new features. Software is simply no longer written as carefully as it used to be written when hardware resources were more scarce. But is it really necessary to have file sizes in the hundreds of kilobytes when the actual text message in them contains only a few thousand characters?
Fallacy 8: Programmers are Getting Better
well, if they all bitch and moan like this, maybe this really is a fallacy. But, I doubt it. Most of teh programmers I know are able to switch between languages and adapt to different environments. Most old time programmers are surgically attached to the Language of Choice for them and will never change. Look at the quality of coding being done on the Linux Kernel, in Oracle's 8i, in Windows'
My thesis is that CS graduates are, on average, less qualified today than they used to be, especially when it comes to lower abstraction levels, such as hardware principles or assembly language, and theoretical computing, such as compiler construction or complexity analysis. I keep in touch with quite a few academics who teach CS, and they generally concur with me in this. The reason is that universities are forced to teach things today as part of a course they didn't have to teach previously, so they are spreading themselves thinner. And curricula drop topics that were once considered de rigeur, such as computational theory, in favour of trivial things, such as HTML. When I wrote my honous thesis, I was told that it had to be typeset. I asked how to do that and was told "man troff". A few weeks later, I knew the basics of typesetting and had taught myself enough of troff, pic, eqn, and tbl to get by. I never received any credit points for this -- it was expected that I would learn these things as part of my normal study. These days, I can enrol in a course that teaches HTML programming and get credit points for it. The time I spend in that course is time I will not spend in a course on computational theory, or assembly language (if one is still available).
BTW, ANY student who majors in CS will know what a core dump is, dont be alarmist. Any student who isnt CS, has no reason to know. So what?
As a matter of fact, I have met quite a few CS graduates who did not know what a core dump is, or what to do with it, and who had no idea of basic things such as demand paging, how a general-purpose memory allocator works, or how a CPU arranges memory into segements. They could draw pretty UML diagrams though, I admit...
the jab about knowing how to write excel memos being a mark of qualification is just arrogant snobbery.
It's an exaggeration, but not snobbery. We routinely ask programmers (especially graduates) to do things they are in no way qualified to do. Projects are routinely staffed with underqualified people. I've been on more than one project where the job of writing an X11 GUI was given to a person who had never written a GUI before. I've been on projects where the person who was supposed to produce our testing strategy and design unit and system tests had never written a line of code. As long as we make mistakes like this, people will write poor code, produce poor designs, get frustrated on the job, and suffer burn-out. Read Fred Brook's "The Mythical Man Month" and then read Ed Yourdon's "The Death March", which was written about twenty years later. The messages about project management failures in the two books are largely identical. I can only conclude that the sum total of what we have learned about software project management in those twenty years is very close to zero.
And the average retention time is from the dotcom boom, it surely isnt true anymore. YOu have a problem with people cashing in on their skills while they could?
This statistic actually predates the dotcom boom by nearly ten years. I don't have more recent figures, but looking around me, I rarely find a person who has been with the same company for more than three years, but I continuously find people who have been with a company for less than 18 months.
Fallacy 9: Programming is About Date Structures and Algorithms
this is an extremely provincial accusation - probably better to just nod and agree with you rather than set off a religious war.
Agreed that programmers are not taught to design. Well, who taught you? If experience sufficed for you to become a self-declared expert, then it will suffice for others also.
Data structures and algorithms are important, but only one small aspect of programming. Design, especially interface design (both human-machine interfaces and API design) are probably more important than data structures and algorithms because, as programmers, we spend a huge amount of time building such interfaces. Yet, these skills are by and large not taught at universities, or taught only as an afterthought. To say that if could learn by experience, other people can do it too is correct, but misses the point: it's like saying than continuing to do it the hard way (and clumsily) is good enough. Why shouldn't we teach something that's so important to CS students?
Fallacy 10: Open Source is the Answer
The Answer? The Answer to what? with apologies to DOuglas Adams, first off you better figure out just what the Question is!
Not long ago, I remember quite a few people telling the world at large that, not long from now, all software will be free and Open Source, and that commercial software production is dying. So far, their predications have not come true, and I don't think they ever will. Open Source is great for some things, and not so great for others. For example, a large part of the world's software are embedded code that does things such as control air conditioners, manage the engine in my car, make the lift stop at the right floor, and so on. I am not aware of any Open Source implementations of such software. The motivation for making such code Open Source isn't there, it's not sexy enough, the code is too specialized, a "make money by providing support" economic model won't work, etc. And, let's face it, Open Source is subject to many of the same flaws that closed software is. Just because someone writes Open Source, that doesn't make them a good designer or a good programmer. There are bad pieces of Open Source around, just as there are good ones.
Cheers,
Michi.
Hell, no! 99% of documents (besides programs) I write are emails.
I'm not nitpicking, this is a major flaw in the argument.
This may be true for you (and it's true for me). It's probably true for the vast majority of programmers. Is it true for the vast majority of MS Word users? I doubt that very much. The vast majority of MS Word users use the program to write assignments, business correspondence, research papers (in a field other than computing!), love letters, etc. Those documents, in almost every case, get printed out, so embedded video or sound clips, and embedded links that launch programs are of dubious value then.
Cheers,
Michi.
Were you present at the talk? I don't know, of course, but if you were, I doubt you would have said what you did. A few points:
1) The talk was a keynote. People don't go to keynotes to learn about a new algorithm or to listen to an hour-long marketing presentation. Instead, they go to get some insight, a new angle, to be entertained, to have a good laugh, and so on (possibly, all of the above). So, I put together a keynote that I thought would be entertaining and funny, provide an unusual angle, and would do this with enough substance to avoid boredom. I think the keynote achieved that.
2) I don't think the argument is shallow. I've been a computer professional for more than twenty years, and the topics I touched on during the keynote arose from experience. I have given this talk at quite a few conferences all over the world -- the feedback I get indicates that these issues touch a chord with people. Many people have written to me afterwards to tell me that the talk changed the way they look at their profession and has changed their daily lives.
3) I believe that what I presented is indeed based on fact. The problems I point out are real, not just made up. Yes, I did exaggerate in places. After all, the talk is meant to be provocative. I am an OS and distributed computing expert with post-graduate qualifications and more than two decades of programming experience. Yet, my Windows PC effortlessly brings me to the brink of nervous breakdown on a regular basis and reduces me to a helpless wreck, making me feel like an idiot. If I, as an expert, am left helpless in the face of some problem, what chance has a non-computing person got? There are very real and definite problems with our software, so much so that experts often can't fix things. That's a far cry from the empowering device we would like our computers to be.
Cheers,
Michi.
Hmmm... I think a big problem here is that my comments were taken somewhat out of context. This wasn't about blasting Open Source at all, but to simply illustrate that Open Source can't satisfy all of the world's software needs. A lot of code we need, such as aircon controllers, engine management systems, etc. is too specialized and not sexy enough to attract Open Source developers. So, such source will continue to be written for monetary compensation. Open Source is great -- without it, I wouldn't be able to run my business. But I thought it would be worthwhile pointing out that (like any other model), the Open Source model isn't without problems and that its proponents (just like its opponents) sometimes use arguments that don't stand up under closer examination.
Cheers,
Michi.
Seeing that I set off such a storm, I thought it would be best to clarify what I said (and meant) when I said "Source code is useless."
:-)
First up: the entire talk is meant to be provocative and entertaining, and to get people to think about things that normally tend to get swept under the carpet. So, when I put up something like "Source code is useless", at least I know I got their attention
So, here is why I said this:
One of the often recited arguments in favor of Open Source is that having the source code is insurance against things such as the vendor going out of business or deciding to no longer maintain a product: because I have the source, I'm no longer subject to vendor lock-in.
For the vast majority of commercial software development situations, I think this argument is severely flawed. Consider the following scenario (substitute any other large and complex piece of software for an ORB, if you wish):
My company builds stock broking software that allows stock brokers to trade on-line, monitor portfolios, etc. The application runs on many machines, including handhelds. Because there is a lot of distributed computing going on there, I've decided to use a CORBA ORB from vendor X as my RPC platform. A year later, after deploying my application on thousands of machines at dozens of customer sites, vendor X goes out of business. No problem: vendor X gave me the source code, so I can just continue to use the ORB and maintain it myself...
Wrongo: I'm into building stock broking applications, not ORBs. Moreover, I do not have the in-house programming skills that are required to maintain a networking product such as an ORB -- my programmers are good at writing financial models and don't know much about sockets, IIOP, threading models, and the like. Besides, there's well over 100,000 lines of C++ code in the ORB; it takes months to get a feel for how that code base hangs together and to even begin to understand it.
But let's assume for the moment that I do have skilled programmers who do understand sockets programming and threading, and that I am even willing to pay them to work on the ORB instead of my application. Will that help me? Not likely. For the ORB to remain useful to me in the future, I will not only need the occasional bug fix, but I will also need to port it to new hardware, OS, and compilers. (It's depressing how often the code needs changing just because a new compiler version appears.) So, apart from the skills required to fix the odd bug, my programmers will require deep understanding of the code (and all the subtle hacks that have crept into the code over the years to work around various bugs in compilers and libraries); without such deep understanding of the code, my programmers won't be able to port it. But let's assume my programmers are so clever that they can do that, and that I am rich enough to afford paying them for it. Will that mean that I'm going to keep using the ORB from vendor X? Not likely. Here is why:
For the ORB to remain useful (and for my application to remain competitive), the ORB must track the OMG specifications and support new features as they are being standardized. Adding new features to an ORB is technically non-trivial. (For example, the OMG recently standardized asynchronous messaging; adding that functionality to an ORB requires large and intrusive architechtural changes and thousands of lines of code.) But let's assume that my programmers are so good that they can do all that, and that I'm still rich enough to afford it.
Will I keep the ORB? Not likely:
The CORBA spec runs to thousands of pages, much of it containing highly complex (and sometimes highly obscure) material. To effectively maintain an ORB, I need to know most of the spec pretty much by heart. It takes many months (years?) to become conversant enough with all of CORBA's nooks and crannies to correctly reflect those semantics in code. But let's assume my programmers are so clever that they can do all this, and that I'm still rich enough to afford it. Will I keep the ORB? Not likely:
To effectively implement the specification, I not only need the specification, I need to contribute to writing it and, once it is written, I need to contribute to maintaining it (yes, specifications have bugs and require maintenance just like code). To do this effectively, I have to participate in the OMG process. This not only means becoming an OMG member (which isn't cheap), it also means attending meetings all over the world, devoting large amounts of time to participate in task forces and to respond to RFPs, and to engage in long drawn-out discussions and lobbying with other members to make sure that some proposed new feature doesn't make a mess of my ORB architecture.
The above illustrates why I said what I did: pragmatically, the source code is useless to me. Remember, I originally was in the business of building and selling a stock-broking application. By keeping the ORB, I'm committing myself to paying three or four full-time staff members to look after the ORB, at a cost of several hundred thousand dollars a year. (And that is assuming that I have staff members who are sufficiently competent in CORBA technology, which is unlikely to be the case.)
When vendor X goes out of business, the realistic course of action for me is to shrug my shoulders and to find another ORB from a vendor who I think won't go out of business. That's far more cost-effective than hacking around in a large code base that I don't understand and that isn't directly relevant to my core business.
Whether we are talking about a CORBA ORB or some other piece of code here, such as a compiler, container library, database, or whatever, the reality is that all these bits of technology are far to complex and specialized for me (as an application developer, that is, a user of the technology) to be able to do anything useful with the source code.
Of course, none of this means that Open Source is bad, or useless. Far from it. But it does mean that, for the vast majority of Open Source customers, the source provides little (if any) insurance. Open Source projects do shut down occasionally, just as vendors occasionally go out of business. When that happens, I'm hosed, source code or not.
Cheers,
Michi.