I tend to think that discussions along these lines generate significantly more heat than light. For starters, I would bet that many of the opinions that have been expressed with regards to learning computer science (higher level language versus lower level language, C versus Java, etc) are coming from people who probably did NOT learn what they know of computer science in the manner that they prescribe. I could easily suggest that scheme should be taught as the first computer science language followed by C then Ruby, then maybe a little Java or Smalltalk then haskell, but the fact of the matter is that this is not the progression that I made (nor do I know many of the languages that are prescribed above). For an example, I truly think that there is a lot to be learned from a language like scheme, but rather than the first, this is the LAST language I learned (having recently been T.A. for a class taught using the Wizard Book). Having already studied other programming languages, I discovered that there is a lot to learn about both the Structure and Interpretation of Computer Programs (pun intended) from that language. But what I found as a teaching assistant is that the concepts that were so clear to me from this language were not so simple for students with much less of a background in programming languages than I had.
This is part of the "expert" dilemma. If you already have a vast amount of knowledge from years of hard work, it isn't necessarily easy to prescribe how or in what order to pass this knowledge base on to others. Perhaps there does not exist an optimal starting point for everyone. Maybe you just have to start somewhere, collecting knowledge until enough connections can be made that all of a sudden you are an expert.
Another point that should probably be considered is the purpose of a computer science education. From this discussion, it's pretty clear that many people have different ideas of the purpose of a university or AP computer science education. Some seem to think that it is training for real-world programming in C or Java or whatever is the language du jour of industry. Other's consider it a ground for creating the code hacks of the future. Others in fact find it to be the place to teach computer theory for future computer science graduate students. And the replies posted here strongly reflect these biases. Perhaps different schools have a different leaning in their programs, some being theoretical schools, others trade schools. I think it's important to note that not only are there different programs, but different students, who may find different schools and classes more or less suited to their needs.
<blockquote>Sometimes I actually don't want every joe 6 pack to be running linux. The prideful part of me says, "learn the goddamn system and stop complaining. And if you can't, puleeze go back to windows. Grandma shouldn't be anywhere near a linux box anyway." The human part of me (oh, pride IS human, Doh) says, "*sniff*, try these:"
</blockquote>
I'd say that the above comment expresses a good portion of the state of the world of unix/linux/open source. Those who participate or simply lurk on slashdot alone represent a vast diversity of experiences and interests with respect to Linux, et al. Some here are power users and like to tweak every knob available to them. Some get great pleasure out of digging and digging and learning every nook and corner of their system. Customization is king. Others are simply looking for a free(as in beer)/cheap unix or unix-like operating system that feels more like home than a windows system will ever be.
Some people are plain not interested in being hardcore system administrators. Believe it or not there are programmers who couldn't give a hoot about the underlying details of linux or any other operating system. They simply want a platform upon which they can do interesting work, possibly NOT related to systems programming, maintenance, etc.
Just recently I picked up a laptop and began the process of making it fit for my use. I spend a good portion of time reading email, surfing the web, and programming. I happened to get a Mac Powerbook G3 and a copy of Yellow Dog Linux, and I got quite an education during the process of setting up my system.
MacOS installs and reinstalls like cake. Even being unfamiliar with a Mac environment I repartitioned and reinstalled MacOS with an amazing amount of ease. Sure the install hides a lot of things from me, but I don't care because I didn't buy a computer to spend my time administering it. I bought it specifically to be more productive.
Installing Linux on the other hand was a less than smooth experience. The biggest barrier for me was getting PPP up. After searching for directions on the web, I found myself less than impressed with the hoops I was expected to jump through to get a connection set up after taking all of a minute to do so under MacOS. Sure the flexibility built into Linux is an advantage, but the inability to surmount that complexity out of the box will hinder Linux's adoption by those who simply want to be more productive. (on a side note, I eventually found a program called EZNET that made setting up a PPP connection from the command line trivial. I only wish my OS had come with it).
Something to keep in mind: menu bars and such are often a great way of slowing down someone who knows how to use a tool (ie, if you are familiar with Emacs ctrl commands, are you going to use Xemacs pull-down menus all the time?), but they can also be a great way of flattening the learning curve on a new tool. Perhaps menu options will only be used for a short time during the time one learns an application. Perhaps menu options oversimplify that palette of options that are available under the covers and can eventually be accessed directly. Regardless, these aids can greatly improve the user experience as one familiarizes oneself with a tool or environment. This possibly temporary crutch can make or break the popularity of a computer tool when it comes time for users to "vote with their feet."
For many, computers and operating systems are tools and only tools. Not works of beauty that must be inspected down to the bone. Not the equivalent of performance vehicles to be tweaked and fine tuned down to the last ounce of performance. Instead, they are meant to make life easier, and the higher the bar of entry, that is, the greater the amount of overhead necessary to bear before benefit is reaped, the less likely the tool is to be used.
Whoever is interested in bringing Unix to the desktop in a manner that is truly competitive with Windows will need to provide abstractions that hide the details of the OS while still making those knobs available to the interested. I'm very curious to see how Mac OS X intends to do just this. Many lessons could be learned here by anyone willing to follow.
Those quoted recording costs do not always have to be the case these days!
When I'm not busy spending time in front of a computer, I spend the rest of my time playing in bands and recording them. My setup is rather modest, but I've managed to put together some pretty good cd's for friends bands and for my own. No one I've recorded has spent over $2000 for the complete process of duplication plus recording. My band's last cd cost $700 in all (and you can add an extra $200 if I actually charged myself for recording) split 3 ways. Besides myself, there are plenty of other small to medium studios out there with significantly better equipment and results than I generate and still accessible rates ($30-$50 per hour).
Part of the reason for this is the large boom in the consumer recording industry market. Take a look in the music periodicals section of Borders or Barnes and Nobles and see how many magazines cater to the home recording industry. And even in Mix magazine, one of the major professional recording magazines, you'll find ads for equipment a reasonably well paid schlep can afford.
Now, the product coming out of a smaller studio is obviously not going to sound like it was recorded at Abbey Road, but for many people who just like to listen to good music, it's not going to make a big difference how expensive the production is. Often you'll find the most involved productions on the lowest quality music as an attempt to compensate -- polished turds. There exist many anecdotes about mainstream cd's put out with tracks taken from a 4-track rather than the same song recorded on expensive equipment because the "energy and feel" were significantly better than a studio take.
Another point of importance: when an artist or group is given a large sum of money to work on a recording for a label, sometimes the artists actually spend the time in the studio working on composing the music itself. In some situations that's a necessity, especially with electronica, etc. But why would a "Led Zeppelin" of today need to compose songs in studio? And that's not even considering the time and money spent on digital editing equipment so your pop diva can record 12 versions of the vocals for one song from which you can extract and combine your favorite lines to create the perfect single take (note: this is the norm, not the exception). Talk about sanitized! "Look kids! Thanks to effects that can correct your pitch and rhythm, you don't have to be a competent musician anymore!" Bear in mind, I'm not against digital equipment, but using it to take the place of talent and skill is pretty pathetic.
The indie music scene has thrived on lower fidelity recordings. And that's not to mention that the media format du jour is the Mp3. Personally, I hate the way they sound, but that's more because I spend my spare time trying to make the best recordings I can. Your average joe doesn't seem to mind, as evidenced by Napster's popularity.
I'd just like to emphasize that in many cases, the cost of recording is NOT an issue anymore, thanks to newer cheaper recording technology and the grand majority of the population's less-than-audiophile fidelity standards.
This proposal does raise an interesting set of issues in regards to programming curricula. For example, here, the first language taught to all engineers when I started here was Fortran-90 -- the class was an introduction to engineering. IMHO, this wasn't too bad since the focus of our programs was solely on numerics, but that was a long time ago, so my memory is hazy. EE's and CompEng's and CE's moved on to C in the next programming class (Civil/Mechanical/Aero Engineers continue(d) to use Fortran-90 throughout their college career, along with some Matlab). Eventually, the CompSci's move on to Scheme to learn functional programming.
Part of the problem with the curricula is that given X semesters for each major to learn programming, along with industry pressure on graduates to learn C/C++, there isn't enough time it seems to use a simple language like Python in the beginning and later teach C. So the CS majors learn Scheme later down the line while the other engineering disciplines are taught to use the industry language of choice earlier on.
I question the necessity of this design consideration. IMHO most applications aren't so time-critical. I would have preferred it if I would have got more genericity, GC, a smaller language etc. for --say-- 50% more CPU usage.
As far as C++ is concerned, this is a necessary design consideration. GC is problematic in the context of realtime system design, which is one situation where C++ is used (remember where C++ was designed -- Bell Labs). Perhaps better hooks could have been added for GC, but there already exist GCs for c++, so I guess it wasn't too hard.
>re: Garbage collection > Purchase a copy? So, how would I go about GPL-ing my application?
That's hardly a language issue. And there already exist other free GC implementations, but Great Circle appears to be the best. If they're not good enough, write your own or use a different language (a perfectly reasonable option given a set of tradeoffs).
Personally, I've gotten by quite well without GC. That doesn't mean I won't look into it to see if it improves my code in the future. But bear in mind that GC is only a partial solution to a greater problem, that being "resource allocation" as a whole. Memory isn't the only thing that needs to be released. Think sockets, threads, etc. As far a code reuse, some component of the code must be responsible for ownership of these resources as well.
> I'd like to boldly say "I am flawed", but by now I am too well versed in C++.
Given your set of rules for using C++, I'd suggest that you could still be better versed in C++ (and I'll gladly admit that the same applies to me). Each of those features has its uses in the proper context. To simply write them off is not necessarily the proper decision. Learn the tradeoffs involved in using them and you can definitely find situations where they're useful. I personally use all the features you mentioned, but only where I see fit.
I don't mean to carry on a language war here, and I would not dare suggest that C++ is perfect...but I think I've developed a reasonable foundation in its use and dislike seeing misinformation passed around about what could possibly be a useful tool for someone. Given the number of opinions going either way about the language, I would suggest to anyone curious about the language to do some research yourself into the pros and cons. It's the only way you'll really know if it's right for you.
> The ownership of C++ CORBA's strings and objects are extremely convoluted.
Isn't that what the *_var wrappers are for? For example, using a String_var instead of a String_ptr takes care of ownership and memory management. Plus there exists a *_var for every CORBA object and pseudo-object. I suppose that in this manner, one could handle memory management oneself if so disposed...I personally use the var's for everything...makes for exception safe code too.
C++ is a huge language because Stroustroup, among others, believes that not just one programming metaphor (ie, OO, generic, imperative) suffices. C++ supports more than one style of programming.
> One could decide not to use the entire language, but that is likely to give longer and less efficient solutions
C++ was designed such that you don't pay for features you don't use. The only feature I'm aware of that will cost without being used is exceptions. That cost is compiler-dependent. As for longer less efficient solutions, anything you can do in C++ you can do in C (For evidence, look at the Kuck and Associates C++ compiler, which compiles to C, or cfront), but do you want to do it by hand? The question of efficiency in this case is again dependent on the compiler. The important point is that the size of the language does not affect the size of your programs.
> * The language lacks features that make it difficult to reuse code: for example
> - garbage collection
What does garbage collection have to do with code reuse? If you want garbage collection in your C++, there exist many implementations you can compile into your code. I'll admit that most are intrusive, but if that's a problem, purchase a copy of Great Circle, which isn't.
> - interfaces/signatures abstract base classes in C++ serve the exact same purpose. Having a separate interface construct would simply be syntactic sugar, which isn't a bad thing, but imho it's not worth the bother in this case, as opposed to operator overloading where it serves to create intuitive abstract data types.
> - standardised libraries The most recent C++ standard has a standard library including string, list, and array classes. Many compilers do not yet fully implement the spec, but third parties supply Add-ins for just this purpose. For example, before egcs provided the support that it does support (not yet complete, but it's coming), ObjectSpace offered an implemention of the Standard Library for g++.
Sounds to me like you don't like C++ because it's not Java. That's fine. Different strokes for different folks.
I once saw a quote somewhere that said something along the lines of "giving C++ to the average programmer is like giving a loaded.45 to a monkey." Perhaps this is true, and I've seen some cases of programmers shooting themselves in the foot with C++. But I don't believe it's because of a major flaw in the language. I'd suggest it's a flaw in the programmers...namely, failure to learn how to use the language properly, failure to separate what's "legal" C++ from what's "moral" c++ This happens in other languages all the time as well. C++ has a high learning curve to use it effectively, but I think that curve is well worth it.
If you're looking for a good introduction to CORBA concepts, check out this article by Steve Vinoski (here). It does a good job of explaining the "whys" of CORBA. Don't be intimidated by the "Advanced" in the title. The book goes into the basics of implementation, just not detailed coverage of why one would use CORBA.
For those of you who aren't fans of C++ but would like to learn CORBA, I still recommend purchasing this book. The explanation of features and architecture is simply splendid. A copy of this book and the chapter of the OMG CORBA spec corresponding to your preferred language will do wonders.
Slashdot Mirror
I tend to think that discussions along these lines generate significantly more heat than light. For starters, I would bet that many of the opinions that have been expressed with regards to learning computer science (higher level language versus lower level language, C versus Java, etc) are coming from people who probably did NOT learn what they know of computer science in the manner that they prescribe. I could easily suggest that scheme should be taught as the first computer science language followed by C then Ruby, then maybe a little Java or Smalltalk then haskell, but the fact of the matter is that this is not the progression that I made (nor do I know many of the languages that are prescribed above). For an example, I truly think that there is a lot to be learned from a language like scheme, but rather than the first, this is the LAST language I learned (having recently been T.A. for a class taught using the Wizard Book). Having already studied other programming languages, I discovered that there is a lot to learn about both the Structure and Interpretation of Computer Programs (pun intended) from that language. But what I found as a teaching assistant is that the concepts that were so clear to me from this language were not so simple for students with much less of a background in programming languages than I had.
This is part of the "expert" dilemma. If you already have a vast amount of knowledge from years of hard work, it isn't necessarily easy to prescribe how or in what order to pass this knowledge base on to others. Perhaps there does not exist an optimal starting point for everyone. Maybe you just have to start somewhere, collecting knowledge until enough connections can be made that all of a sudden you are an expert.
Another point that should probably be considered is the purpose of a computer science education. From this discussion, it's pretty clear that many people have different ideas of the purpose of a university or AP computer science education. Some seem to think that it is training for real-world programming in C or Java or whatever is the language du jour of industry. Other's consider it a ground for creating the code hacks of the future. Others in fact find it to be the place to teach computer theory for future computer science graduate students. And the replies posted here strongly reflect these biases. Perhaps different schools have a different leaning in their programs, some being theoretical schools, others trade schools. I think it's important to note that not only are there different programs, but different students, who may find different schools and classes more or less suited to their needs.
<blockquote>Sometimes I actually don't want every joe 6 pack to be running linux. The prideful part of me says, "learn the goddamn system and stop complaining. And if you can't, puleeze go back to windows. Grandma shouldn't be anywhere near a linux box anyway." The human part of me (oh, pride IS human, Doh) says, "*sniff*, try these:"
</blockquote>
I'd say that the above comment expresses a good portion of the state of the world of unix/linux/open source. Those who participate or simply lurk on slashdot alone represent a vast diversity of experiences and interests with respect to Linux, et al. Some here are power users and like to tweak every knob available to them. Some get great pleasure out of digging and digging and learning every nook and corner of their system. Customization is king. Others are simply looking for a free(as in beer)/cheap unix or unix-like operating system that feels more like home than a windows system will ever be.
Some people are plain not interested in being hardcore system administrators. Believe it or not there are programmers who couldn't give a hoot about the underlying details of linux or any other operating system. They simply want a platform upon which they can do interesting work, possibly NOT related to systems programming, maintenance, etc.
Just recently I picked up a laptop and began the process of making it fit for my use. I spend a good portion of time reading email, surfing the web, and programming. I happened to get a Mac Powerbook G3 and a copy of Yellow Dog Linux, and I got quite an education during the process of setting up my system.
MacOS installs and reinstalls like cake. Even being unfamiliar with a Mac environment I repartitioned and reinstalled MacOS with an amazing amount of ease. Sure the install hides a lot of things from me, but I don't care because I didn't buy a computer to spend my time administering it. I bought it specifically to be more productive.
Installing Linux on the other hand was a less than smooth experience. The biggest barrier for me was getting PPP up. After searching for directions on the web, I found myself less than impressed with the hoops I was expected to jump through to get a connection set up after taking all of a minute to do so under MacOS. Sure the flexibility built into Linux is an advantage, but the inability to surmount that complexity out of the box will hinder Linux's adoption by those who simply want to be more productive. (on a side note, I eventually found a program called EZNET that made setting up a PPP connection from the command line trivial. I only wish my OS had come with it).
Something to keep in mind: menu bars and such are often a great way of slowing down someone who knows how to use a tool (ie, if you are familiar with Emacs ctrl commands, are you going to use Xemacs pull-down menus all the time?), but they can also be a great way of flattening the learning curve on a new tool. Perhaps menu options will only be used for a short time during the time one learns an application. Perhaps menu options oversimplify that palette of options that are available under the covers and can eventually be accessed directly. Regardless, these aids can greatly improve the user experience as one familiarizes oneself with a tool or environment. This possibly temporary crutch can make or break the popularity of a computer tool when it comes time for users to "vote with their feet."
For many, computers and operating systems are tools and only tools. Not works of beauty that must be inspected down to the bone. Not the equivalent of performance vehicles to be tweaked and fine tuned down to the last ounce of performance. Instead, they are meant to make life easier, and the higher the bar of entry, that is, the greater the amount of overhead necessary to bear before benefit is reaped, the less likely the tool is to be used.
Whoever is interested in bringing Unix to the desktop in a manner that is truly competitive with Windows will need to provide abstractions that hide the details of the OS while still making those knobs available to the interested. I'm very curious to see how Mac OS X intends to do just this. Many lessons could be learned here by anyone willing to follow.
Those quoted recording costs do not always have to be the case these days!
When I'm not busy spending time in front of a computer, I spend the rest of my time playing in bands and recording them. My setup is rather modest, but I've managed to put together some pretty good cd's for friends bands and for my own. No one I've recorded has spent over $2000 for the complete process of duplication plus recording. My band's last cd cost $700 in all (and you can add an extra $200 if I actually charged myself for recording) split 3 ways. Besides myself, there are plenty of other small to medium studios out there with significantly better equipment and results than I generate and still accessible rates ($30-$50 per hour).
Part of the reason for this is the large boom in the consumer recording industry market. Take a look in the music periodicals section of Borders or Barnes and Nobles and see how many magazines cater to the home recording industry. And even in Mix magazine, one of the major professional recording magazines, you'll find ads for equipment a reasonably well paid schlep can afford.
Now, the product coming out of a smaller studio is obviously not going to sound like it was recorded at Abbey Road, but for many people who just like to listen to good music, it's not going to make a big difference how expensive the production is. Often you'll find the most involved productions on the lowest quality music as an attempt to compensate -- polished turds. There exist many anecdotes about mainstream cd's put out with tracks taken from a 4-track rather than the same song recorded on expensive equipment because the "energy and feel" were significantly better than a studio take.
Another point of importance: when an artist or group is given a large sum of money to work on a recording for a label, sometimes the artists actually spend the time in the studio working on composing the music itself. In some situations that's a necessity, especially with electronica, etc. But why would a "Led Zeppelin" of today need to compose songs in studio? And that's not even considering the time and money spent on digital editing equipment so your pop diva can record 12 versions of the vocals for one song from which you can extract and combine your favorite lines to create the perfect single take (note: this is the norm, not the exception). Talk about sanitized! "Look kids! Thanks to effects that can correct your pitch and rhythm, you don't have to be a competent musician anymore!" Bear in mind, I'm not against digital equipment, but using it to take the place of talent and skill is pretty pathetic.
The indie music scene has thrived on lower fidelity recordings. And that's not to mention that the media format du jour is the Mp3. Personally, I hate the way they sound, but that's more because I spend my spare time trying to make the best recordings I can. Your average joe doesn't seem to mind, as evidenced by Napster's popularity.
I'd just like to emphasize that in many cases, the cost of recording is NOT an issue anymore, thanks to newer cheaper recording technology and the grand majority of the population's less-than-audiophile fidelity standards.
This proposal does raise an interesting set of issues in regards to programming curricula. For example, here, the first language taught to all engineers when I started here was Fortran-90 -- the class was an introduction to engineering. IMHO, this wasn't too bad since the focus of our programs was solely on numerics, but that was a long time ago, so my memory is hazy. EE's and CompEng's and CE's moved on to C in the next programming class (Civil/Mechanical/Aero Engineers continue(d) to use Fortran-90 throughout their college career, along with some Matlab).
Eventually, the CompSci's move on to Scheme to learn functional programming.
Part of the problem with the curricula is that given X semesters for each major to learn programming, along with industry pressure on graduates to learn C/C++, there isn't enough time it seems to use a simple language like Python in the beginning and later teach C. So the CS majors learn Scheme later down the line while the other engineering disciplines are taught to use the industry language of choice earlier on.
As far as C++ is concerned, this is a necessary design consideration. GC is problematic in the context of realtime system design, which is one situation where C++ is used (remember where C++ was designed -- Bell Labs). Perhaps better hooks could have been added for GC, but there already exist GCs for c++, so I guess it wasn't too hard.
>re: Garbage collection
> Purchase a copy? So, how would I go about GPL-ing my application?
That's hardly a language issue. And there already exist other free GC implementations, but Great Circle appears to be the best. If they're not good enough, write your own or use a different language (a perfectly reasonable option given a set of tradeoffs).
Personally, I've gotten by quite well without GC. That doesn't mean I won't look into it to see if it improves my code in the future. But bear in mind that GC is only a partial solution to a greater problem, that being "resource allocation" as a whole. Memory isn't the only thing that needs to be released. Think sockets, threads, etc. As far a code reuse, some component of the code must be responsible for ownership of these resources as well.
> I'd like to boldly say "I am flawed", but by now I am too well versed in C++.
Given your set of rules for using C++, I'd suggest that you could still be better versed in C++ (and I'll gladly admit that the same applies to me). Each of those features has its uses in the proper context. To simply write them off is not necessarily the proper decision. Learn the tradeoffs involved in using them and you can definitely find situations where they're useful. I personally use all the features you mentioned, but only where I see fit.
I don't mean to carry on a language war here, and I would not dare suggest that C++ is perfect...but I think I've developed a reasonable foundation in its use and dislike seeing misinformation passed around about what could possibly be a useful tool for someone. Given the number of opinions going either way about the language, I would suggest to anyone curious about the language to do some research yourself into the pros and cons. It's the only way you'll really know if it's right for you.
> The ownership of C++ CORBA's strings and objects are extremely convoluted.
Isn't that what the *_var wrappers are for? For example, using a String_var instead of a String_ptr takes care of ownership and memory management. Plus there exists a *_var for every CORBA object and pseudo-object. I suppose that in this manner, one could handle memory management oneself if so disposed...I personally use the var's for everything...makes for exception safe code too.
Are there problems beyond memory management?
What do you dislike about the C++ mapping of CORBA? Just curious...
> * The language as a whole is too big.
C++ is a huge language because Stroustroup, among others, believes that not just one programming metaphor (ie, OO, generic, imperative) suffices. C++ supports more than one style of programming.
> One could decide not to use the entire language, but that is likely to give longer and less efficient solutions
C++ was designed such that you don't pay for features you don't use. The only feature I'm aware of that will cost without being used is exceptions. That cost is compiler-dependent. As for longer less efficient solutions, anything you can do in C++ you can do in C (For evidence, look at the Kuck and Associates C++ compiler, which compiles to C, or cfront), but do you want to do it by hand? The question of efficiency in this case is again dependent on the compiler. The important point is that the size of the language does not affect the size of your programs.
> * The language lacks features that make it difficult to reuse code: for example
> - garbage collection
What does garbage collection have to do with code reuse? If you want garbage collection in your C++, there exist many implementations you can compile into your code. I'll admit that most are intrusive, but if that's a problem, purchase a copy of Great Circle, which isn't.
.45 to a monkey." Perhaps this is true, and I've seen some cases of programmers shooting themselves in the foot with C++. But I don't believe it's because of a major flaw in the language. I'd suggest it's a flaw in the programmers...namely, failure to learn how to use the language properly, failure to separate what's "legal" C++ from what's "moral" c++ This happens in other languages all the time as well. C++ has a high learning curve to use it effectively, but I think that curve is well worth it.
> - interfaces/signatures
abstract base classes in C++ serve the exact same purpose. Having a separate interface construct would simply be syntactic sugar, which isn't a bad thing, but imho it's not worth the bother in this case, as opposed to operator overloading where it serves to create intuitive abstract data types.
> - standardised libraries
The most recent C++ standard has a standard library including string, list, and array classes. Many compilers do not yet fully implement the spec, but third parties supply Add-ins for just this purpose. For example, before egcs provided the support that it does support (not yet complete, but it's coming), ObjectSpace offered an implemention of the Standard Library for g++.
Sounds to me like you don't like C++ because it's not Java. That's fine. Different strokes for different folks.
I once saw a quote somewhere that said something along the lines of "giving C++ to the average programmer is like giving a loaded
If you're looking for a good introduction to CORBA concepts, check out this article by Steve Vinoski (here). It does a good job of explaining the "whys" of CORBA. Don't be intimidated by the "Advanced" in the title. The book goes into the basics of implementation, just not detailed coverage of why one would use CORBA.
For those of you who aren't fans of C++ but would like to learn CORBA, I still recommend purchasing this book. The explanation of features and architecture is simply splendid. A copy of this book and the chapter of the OMG CORBA spec corresponding to your preferred language will do wonders.