To those who have no idea what the words theft and steal mean, these are considered theft or stealing. However, this ignorant view is gone once you learn what the words mean.
First, I don't understand why the distinction between
stealing and copyright infringement is so important to the slashdot herd.
The bottom line is that they are freeloading criminals. Second, here are some definitions of
"steal" that may be interesting:
1 a vt to take or appropriate without right or leave and with intent
to keep or make use of wrongfully
1 b vt to take away by force or unjust means
1 c vt to take secretly or without permission
I'd say that by this definition, copyright infringement does amount to stealing. I'd say that
all three of these definitions apply -- (b) may be debatable, but (a) and (c) clearly apply.
Don't statistics kinda lose their meaning if you hand pick the subjects?
Not if there's a reasonably objective basis for choosing the subjects.
Lets see, I'm going to carefully select a test group of people with cars and see what make they drive.
What is your selection
criteria ? Of course if you don't disclose your
selection criteria, the statistics are meaningless.
However, this is not what I was suggesting. My
suggestion was to select
open source projects on the basis of their significance. There are several different criteria
one could use to measure significance, but being listed on sourceforge certainly isn't one of them.
One of the biggest arguments for Open Source Software has been the "More Eyeballs" argument. Granted, if I use OSS I can view/edit the source myself, however, my company doesn't have the time nor the human resources to wade through the source code of even the smallest app.
Here's a free clue -- don't use software on sourceforge for security-critical functions (-;
Seriously, the "many eyeballs" benefit is one that deserves scrutiny-- some packages, like the kernel, ssh, and core utilities really do have "many eyeballs" watching them. Others don't. To simply assert open source implies "many eyeballs" is clearly nonsensical, but on the other hand, it is true that a lot of important open source software does benefit from community scrutiny.
he mode is merely the most common result, which just accounts for all the personal projects that are placed on ourgeforge and go nowhere for various reasons.
Except he selected the 100 "top mature" projects. So it was a select group of projects. I suppose it depends on what "top 100 mature projects" actually means. Though I suspect the largest projects
aren't on that sucky sourcefourge site, since they
usually have the resources to find another host.
What I would have liked to see is a carefully chosen selection of opensource projects. (XFree86, vim, kernel, koffice,..... )
I do not feel however that I am asking for more than I am paying for. 50$ / month should entitle me to 1.5 mbps.
On what grounds do you make this claim ? Why "should" you be "entitled" to a certain amount of bandwidth -- is bandwidth an inalienable right all of a sudden ? Any moral argument about being "entitled" to bandwidth is nonsensical. A more interesting question is whether or not it is feasiable to provide sustained downstream throughput comparable to a T1 for approximately the cost for a dialup. How do you suppose your ISP can provide you with this dedicated bandwidth ?
The difference between residential broadband (cable dsl) and commerical broadband (t1) is the upstream.
No, that is a difference. if that were the only difference, sDSL, with high upstream and downstream burst transfer, would cost as much as a T1. Clearly, it doesn't, and it is not the only difference.
Think about it for a moment. Do you suppose that the ISPs costs drop by an enormous factor simply by virtue of the fact that the bandwidth is downstream only ?
If someone else doesn't need as much speed, let them pay less, dont make me pay more.
What you don't realise is that what you are proposing is not economically feasible. Broadband is not a terribly profitable business. Sure, you'd like everything cheap, and like most slashdotters, it seems that you believe you're enetitled to hog resources and not pay for what you use.
There is a hard cap at 1.5 mbps, if I hit it fine, im getting the most out of my service, and I expect to be able to hit the cap when I need to.
Your argument is absurd. The fact that you have a
high burst transfer rate does not give the ISP any
sort of moral obligation to provide you with an equally high sustained transfer rate. If you want dedicated bandwidth, you can always buy it, but it costs money, which is the root of the problem here-- you basically want the downstream part of a
T1 for the cost of DSL.
A lot of people who are primarily using web and email might want the convenience of a connection that's fast, and up 24/7. It certainly makes downloading much more convenient.
The reason I pay for broadband is because I want lots of speed and bandwidth. Why should my price be increased because I am using what I signed up for in the first place?
The problem is that "lots of speed and bandwidth" means different things to different people. Basically, if the other users are subsidising you and the company are running on thin margins, then your prices should indeed be increased.
Broadband should give me 1.5 Mbps, and that is what it is capped at anyway, so I don't see how people are using too much bandwidth by getting what they should be.
"Should " this, "should" that. You can "should" all you like, but it's not going to alter the fact that you are not going to get a T1 for the price of a dialup. If you want or need that much bandwidth, pay for it. The problem here is that you want a T1 connection, but you don't want to pay for it.
Here's some news for you --
broadband as in cable modem or DSL is NOT
the same as a T1 connection. It gives you a good burst transfer rate at a low price, but in terms of sustained throughput, it doesn't give you a whole lot. The nice thing about broadband is that
it makes it possible for ISPs to offer very high transfer rates at a cost comparable to a dialup.
The problem is that sustained throughput is expensive (because it is reflected in the ISPs costs), and you have to pay for that. You can bitch about it all you like, but it's not going to alter the fact that what you're asking for costs
more money than you're willing to spend.
Let me put it this way. By putting a limit on my uplink and downlink, I have essentially bought an amount of bandwidth per month (as detailed above).
You haven't bought that amount of sustained bandwidth. I don't know about you, but I'd prefer to have the burst transfer rate that is comparable to a T1, while paying a cost that reflects my average transfer rate, which is what it is. Just look at the numbers, and tell me -- is broadband closer in price to a dialup, or to a commercial grade T1 connection ?
If they want to change to a different method of billing then they should take off my speed cap, because the speed cap defines the amount of bandwidth I am allowed to use per month/pay period.
Would you prefer they capped your speed at 14.4k ?
Because that's what they'd need to do to sell you service at dialup prices.
Distro A has the library, but it's a different filename since it's a newer version than the one in Distro B. Bah! The best tech that MS stole was COM objects. Just cram all the necessary versions into a single file, and let the runtime linker figure it out on the fly.
Actually, Linux also lets you install different versions of shared libraries. For example, check your system to see how many different versions of libstdc++ you have. I have 6. The main problem is that distributions often differ at the very core. For example, if the glibc versions are different, there's really not a whole lot of hope of any binary compatibility. And if the gcc versions are different, all of the C++ binaries will be incompatible.
The problem with "base level" differences is that you typically need a parallel set of libraries-- for example, if you have a program that needs an old libc and libjpeg, then you actually need a special libjpeg version that is compiled against the old libc. In other words, you can't just install an old libc, you need to install an old libc subsystem. I do this a lot because I need to have a gcc 3 based development platform. For me, the subsystem means gcc + qt (thankfully, the default glibc is OK, otherwise I'd also need glibc, libpng, libz, libjpeg, and the X11 libraries) The reason your simple command line apps run on most distributions is that most distributions have a minimal (libc + X11 + libstdc++) compatibility subsystem, but that subsystem doesn't include GTK. If you want your GTK apps to run on any distribution, you'll need to link statically to GTK and any other graphics libraries (jpeg, etc)
My suggestion as far as solutions are concerned is
to forget about running anything that's built against the wrong version of libc, and avoid running anything that's not built on your distribution.
I wouldn't call it a fringe compiler, the only sense in which it's "fringe" is that it's only used on Linux. That said, gcc 3.1 is likely to be widely used and deployed, because it really is a lot better than gcc 2.9x, and because it addresses the primary obstruction to gcc 3.0 becoming a mainstream compiler -- bugs. In fact, I suspect that even gcc 3.0 is used by a number of developers for testing purposes. I have used it to test ISO compliance and "std::-cleanliness" of my code.
Red Hat is not linux.
That may be so, but it's also true that Redhat and
Redhat based distributions make up a substantial
portion of Linux users.
Anything that has syntax designed for C compatibility is going to be hideous as far as syntax is concerned. So the short answer is, most other languages have cleaner syntax. The compatibility of C++ makes it very useful, and has advantages that should not be dismissed lightly, but it also is an obstruction to "clean" design.
Other compiled OO languages ? Yes, it never hurts to learn more. Take a look at Eiffel, and/or
or OCaml (this is a hybrid language, actually more functional than OO)
I believe this "system" rears its ugly head in politics too, at least to some minor extent. And I can't rule it out here. So, the real question is, did this behavior, this instinct, influence Feingold at all?
You'd need to look at his record, but he strikes me as being very principled, from what i've seen of him.
The problem is that it's not really a question, it's
an angry rant with a few questions thrown in to disguise
it as questions. I suppose it all depends
on whether you want to ask questions, or whether you
want to deliver a lecture.
Damn, you guys still talk cockney? Even after what 5 or six generations (possibly more) since your criminal (not intended as an insult) ancestors were shipped to australia?
Most Aussies arrived during the gold rush, not on prison ships.
Cheers,
The connection is shitty, with frequent lag spikes.
I wonder why ? Yes, it's because of the bandwidth hogs, ho use ten times what they are paying for. If you need more bandwidth. If not, you're going to be better off if the bandwidth hogs are required to pay more.
Considering that GCC 2.9x is still shipping with most distros, and is the only one that compiles the kernel yet, why not show some comparisons with it, in addition to GCC 3.x and ICC?
It's not true that 2.9x is the only compiler that compiles the kernel. gcc 3.0 and 3.1 also can, indeed kernel compilation was part of the release criteria (maybe you're mixing it up with "2.96" ?)
Comparisons would be nice, but FYI, 2.95 is not going to be any faster than gcc 3.0. (and probably slower)
Why only benchmark fringe compilers, when a vast majority of Linux users will be rocking the older compiler?
gcc 3.1 is not a fringe compiler. You are going to see it in the next Redhat release (as well as the distributions that follow Redhat)
I'm currently working on about 50k lines of C++ code, where a rebuild can take anywhere from 3.5s for one file (no problem) to 90s for a change that affects more code. I'm currently using gcc 2.95.3. gcc 3.1 is much slower.
But gcc 3.1 optimises more heavily. gcc 3.1 with -O1 compiles almost as fast as older releases with -O2, and the optimisation levels are comparable (that is, -O2 on gcc 3.1 should compare with -O1 on an earlier release)
You've still got all those temps. Better to have
a separate function that tests for empty:
if ( ! definedForThisUi(task.getInitializerName() ))
addToTaskBar(task);
But this isn't a very good example anyway -- the
original code was perfectly clear, and better than
your "fix".
Seriously, though. Hopefully this takes care of all those niggling bugs that made 3.0 unusable. Maybe this will encourage everyone to jump from the 2.x tree finally.
I think it has, and I think it will. There are a lot of very important bugfixes in this release, especially with respect to the C++ ABI. My bet is that this is going to be a distribution compiler.
More well informed commentary from the slashdot jihad !
And your point is?
That the other guys statement was dead wrong, and
is an exemplar of the sort of thing witnessed
in this discussion.
Since when did speaking english meant two people can automatically understand each other? When did communication become so easy and trouble free?
I made no such argument. Your argument here is
bogus-- you try to restyle the other guys comment
into something semi-coherent, and then pre-emptively rebut straw-men based on the bogus
assumption that I'll blindly oppose out at your
refined version.
Communication is more than just a written language, well unless it's coming from your mouth of course.
From what I understand about 6 out of 10 projects that try to use overseas programmers fail for one reason or another. Mostly not being able to convey the business logic to the overseas developers.
So what is the failure rate of the "control group"
of projects that don't take the same course ? I'd
be surprised if it's substantially better than 6/10.
Do you expect to get very much in the way
of insightful, well-reasoned, and objective comments
on this forum ?
Nope. You'll get a lot of mindless blithering along these lines:
Indian programmers
are inferior to their American counterparts; hell,
they lie, cheat, don't wash often enough, and don't
speak English ! Your project will go to hell --
Unless you hire Americans (and NOT H1Bs) .
There are a lot of serious issues to consider,
but you're not going to get much in the way of
answers on slashdot.
Might I add, however, that Python *does* have private variables, however little-used they may be.
I've tried using these. Unfortunately, they don't work properly with inheritance.
Not hard at all. Take an extra parameter on container instanciation that refers to the class name. Every time an Object is passed in, verify that it's a member of that class. Easy. Done.
Perhaps I'm not understanding... it looks like you're just doing an up-front runtime type check.
I suppose you've at least reduced the problem to something that could be detected with a backtrace.
You make that sound far worse than it is.
I don't mean to imply that it's the same thing
as a reinterpret_cast -- it's comparable to a dynamic_cast (which is still pretty hideous to a C++ programmer.)
Apart from the safety issues, it's also a substantial performance liability. (at least, my experience is that dynamic_cast is very expensive in C++.)
If you've got a test suite that runs on every compile, of course, this is less of a problem --
A lot of problems go away if you test properly, or
adopt a number of other sensible practices. Most of
the arguments against C++ boil down to what happens when an idiot uses it. The bottom line is
that no tool is going to allow idiots to develop
large scale applications.
Regarding speed, btw -- depends on what you're writing, of course, but have you tried particularly new Java runtimes? I've
been doing servlets lately, and have been very pleasently surprised by the performance.
If I were writing internet applications, I'd consider Java. As it is, I'm writing numerical analysis code, and that rules out java. Apart from anything else, bounds-checked element access is a performance killer in itself.
One doesn't even need any language support to do encapsulation -- one can do encapsulation in C, or
assembly for that matter; it's a matter of good design, rather than language features.
A language can either facilitate encapsulation, or
make it difficult. The whole argument against C++ in this thread has been that it's not idiot proof enough. So in this context, the fact that it may be possible to implement encapsulation via clever hacks is beside the point.
That said, there's still language
support for encapsulation in all those languages I mention.
Python does not have any access protection on class
members. Sure, you can write stub classes, but that requires more design, which eats away at this alleged "rapid development" advantage you're supposed to get from interpreted languages. And it doesn't alter the fact that you don't have private data.
Java on the other hand has good data protection, arguably better than C++. Good C programmers can and do encapsulate, but then, good C++ programmers
avoid the misfeatures of the language. C++ provides well-defined semantics for encapsulation.
If this were such a problem as you make it to
be, one could (easily!) build a container class in Java that checks the types of objects put into it at runtime against a type
passed in on its instanciation. (Heck, if it were a real-world problem, one would expect that Sun would have done it by
now). Why don't I do it?
Because solving this problem in the general sense is roughly equivalent to writing generic containers. It's not easy to come up with a general solution, and writing once-off hacks is painful after a while. So the result is that you have a culture of subverting type-safety.
Making up objections because
they seem like they'd be problems to you, however, makes you no better than those who c
... blah blah blah. You miss the point. I'm not canning these things. Java and Python have a lot of good points. So does C++. C++ has a lot of advantages over java and python. Java and Python have a lot of advantages over C++.
and presuming you have an automatic test suite running after every compile --
which everyone should, no matter the language
If you want to talk about what everyone "should" do, they "should" use C++ correctly, by avoiding the
dangerous features of the language (-; The language "should" avoid putting requirements on the user, such as developing test suites just to make sure the program is type safe.
Of course test suites are good, but they are not
a replacement for static checking. This is not an either-or proposition-- a test suite and static checking is more reliable than a test suite alone.
Moreover, you get static checking for free in C++, and you can do other things besides checking type safety with your test suites. The other problem with test suites is that when you develop a library, your test suite can't check client code-- so you're requiring your clients to develop test suites as well.
Slashdot Mirror
First, I don't understand why the distinction between stealing and copyright infringement is so important to the slashdot herd. The bottom line is that they are freeloading criminals. Second, here are some definitions of "steal" that may be interesting:
I'd say that by this definition, copyright infringement does amount to stealing. I'd say that all three of these definitions apply -- (b) may be debatable, but (a) and (c) clearly apply.
Not if there's a reasonably objective basis for choosing the subjects.
Lets see, I'm going to carefully select a test group of people with cars and see what make they drive.
What is your selection criteria ? Of course if you don't disclose your selection criteria, the statistics are meaningless. However, this is not what I was suggesting. My suggestion was to select open source projects on the basis of their significance. There are several different criteria one could use to measure significance, but being listed on sourceforge certainly isn't one of them.
Here's a free clue -- don't use software on sourceforge for security-critical functions (-; Seriously, the "many eyeballs" benefit is one that deserves scrutiny-- some packages, like the kernel, ssh, and core utilities really do have "many eyeballs" watching them. Others don't. To simply assert open source implies "many eyeballs" is clearly nonsensical, but on the other hand, it is true that a lot of important open source software does benefit from community scrutiny.
Except he selected the 100 "top mature" projects. So it was a select group of projects. I suppose it depends on what "top 100 mature projects" actually means. Though I suspect the largest projects aren't on that sucky sourcefourge site, since they usually have the resources to find another host.
What I would have liked to see is a carefully chosen selection of opensource projects. (XFree86, vim, kernel, koffice, ..... )
On what grounds do you make this claim ? Why "should" you be "entitled" to a certain amount of bandwidth -- is bandwidth an inalienable right all of a sudden ? Any moral argument about being "entitled" to bandwidth is nonsensical. A more interesting question is whether or not it is feasiable to provide sustained downstream throughput comparable to a T1 for approximately the cost for a dialup. How do you suppose your ISP can provide you with this dedicated bandwidth ?
The difference between residential broadband (cable dsl) and commerical broadband (t1) is the upstream.
No, that is a difference. if that were the only difference, sDSL, with high upstream and downstream burst transfer, would cost as much as a T1. Clearly, it doesn't, and it is not the only difference. Think about it for a moment. Do you suppose that the ISPs costs drop by an enormous factor simply by virtue of the fact that the bandwidth is downstream only ?
If someone else doesn't need as much speed, let them pay less, dont make me pay more.
What you don't realise is that what you are proposing is not economically feasible. Broadband is not a terribly profitable business. Sure, you'd like everything cheap, and like most slashdotters, it seems that you believe you're enetitled to hog resources and not pay for what you use.
There is a hard cap at 1.5 mbps, if I hit it fine, im getting the most out of my service, and I expect to be able to hit the cap when I need to.
Your argument is absurd. The fact that you have a high burst transfer rate does not give the ISP any sort of moral obligation to provide you with an equally high sustained transfer rate. If you want dedicated bandwidth, you can always buy it, but it costs money, which is the root of the problem here-- you basically want the downstream part of a T1 for the cost of DSL.
A lot of people who are primarily using web and email might want the convenience of a connection that's fast, and up 24/7. It certainly makes downloading much more convenient.
The reason I pay for broadband is because I want lots of speed and bandwidth. Why should my price be increased because I am using what I signed up for in the first place?
The problem is that "lots of speed and bandwidth" means different things to different people. Basically, if the other users are subsidising you and the company are running on thin margins, then your prices should indeed be increased.
Broadband should give me 1.5 Mbps, and that is what it is capped at anyway, so I don't see how people are using too much bandwidth by getting what they should be.
"Should " this, "should" that. You can "should" all you like, but it's not going to alter the fact that you are not going to get a T1 for the price of a dialup. If you want or need that much bandwidth, pay for it. The problem here is that you want a T1 connection, but you don't want to pay for it.
Here's some news for you -- broadband as in cable modem or DSL is NOT the same as a T1 connection. It gives you a good burst transfer rate at a low price, but in terms of sustained throughput, it doesn't give you a whole lot. The nice thing about broadband is that it makes it possible for ISPs to offer very high transfer rates at a cost comparable to a dialup. The problem is that sustained throughput is expensive (because it is reflected in the ISPs costs), and you have to pay for that. You can bitch about it all you like, but it's not going to alter the fact that what you're asking for costs more money than you're willing to spend.
You haven't bought that amount of sustained bandwidth. I don't know about you, but I'd prefer to have the burst transfer rate that is comparable to a T1, while paying a cost that reflects my average transfer rate, which is what it is. Just look at the numbers, and tell me -- is broadband closer in price to a dialup, or to a commercial grade T1 connection ?
If they want to change to a different method of billing then they should take off my speed cap, because the speed cap defines the amount of bandwidth I am allowed to use per month/pay period.
Would you prefer they capped your speed at 14.4k ? Because that's what they'd need to do to sell you service at dialup prices.
Actually, Linux also lets you install different versions of shared libraries. For example, check your system to see how many different versions of libstdc++ you have. I have 6. The main problem is that distributions often differ at the very core. For example, if the glibc versions are different, there's really not a whole lot of hope of any binary compatibility. And if the gcc versions are different, all of the C++ binaries will be incompatible.
The problem with "base level" differences is that you typically need a parallel set of libraries-- for example, if you have a program that needs an old libc and libjpeg, then you actually need a special libjpeg version that is compiled against the old libc. In other words, you can't just install an old libc, you need to install an old libc subsystem. I do this a lot because I need to have a gcc 3 based development platform. For me, the subsystem means gcc + qt (thankfully, the default glibc is OK, otherwise I'd also need glibc, libpng, libz, libjpeg, and the X11 libraries) The reason your simple command line apps run on most distributions is that most distributions have a minimal (libc + X11 + libstdc++) compatibility subsystem, but that subsystem doesn't include GTK. If you want your GTK apps to run on any distribution, you'll need to link statically to GTK and any other graphics libraries (jpeg, etc)
My suggestion as far as solutions are concerned is to forget about running anything that's built against the wrong version of libc, and avoid running anything that's not built on your distribution.
I wouldn't call it a fringe compiler, the only sense in which it's "fringe" is that it's only used on Linux. That said, gcc 3.1 is likely to be widely used and deployed, because it really is a lot better than gcc 2.9x, and because it addresses the primary obstruction to gcc 3.0 becoming a mainstream compiler -- bugs. In fact, I suspect that even gcc 3.0 is used by a number of developers for testing purposes. I have used it to test ISO compliance and "std::-cleanliness" of my code.
Red Hat is not linux.
That may be so, but it's also true that Redhat and Redhat based distributions make up a substantial portion of Linux users.
Other compiled OO languages ? Yes, it never hurts to learn more. Take a look at Eiffel, and/or or OCaml (this is a hybrid language, actually more functional than OO)
You'd need to look at his record, but he strikes me as being very principled, from what i've seen of him.
The problem is that it's not really a question, it's an angry rant with a few questions thrown in to disguise it as questions. I suppose it all depends on whether you want to ask questions, or whether you want to deliver a lecture.
Most Aussies arrived during the gold rush, not on prison ships. Cheers,
I wonder why ? Yes, it's because of the bandwidth hogs, ho use ten times what they are paying for. If you need more bandwidth. If not, you're going to be better off if the bandwidth hogs are required to pay more.
It's not true that 2.9x is the only compiler that compiles the kernel. gcc 3.0 and 3.1 also can, indeed kernel compilation was part of the release criteria (maybe you're mixing it up with "2.96" ?) Comparisons would be nice, but FYI, 2.95 is not going to be any faster than gcc 3.0. (and probably slower)
Why only benchmark fringe compilers, when a vast majority of Linux users will be rocking the older compiler?
gcc 3.1 is not a fringe compiler. You are going to see it in the next Redhat release (as well as the distributions that follow Redhat)
But gcc 3.1 optimises more heavily. gcc 3.1 with -O1 compiles almost as fast as older releases with -O2, and the optimisation levels are comparable (that is, -O2 on gcc 3.1 should compare with -O1 on an earlier release)
But this isn't a very good example anyway -- the original code was perfectly clear, and better than your "fix".
I think it has, and I think it will. There are a lot of very important bugfixes in this release, especially with respect to the C++ ABI. My bet is that this is going to be a distribution compiler.
And your point is?
That the other guys statement was dead wrong, and is an exemplar of the sort of thing witnessed in this discussion.
Since when did speaking english meant two people can automatically understand each other? When did communication become so easy and trouble free?
I made no such argument. Your argument here is bogus-- you try to restyle the other guys comment into something semi-coherent, and then pre-emptively rebut straw-men based on the bogus assumption that I'll blindly oppose out at your refined version.
Communication is more than just a written language, well unless it's coming from your mouth of course.
Cheap invective is not victory.
The speaking english is a big part, kind of hard to communicate without a common language.
Hey Dumbass, the Indian programmers do speak English.
So what is the failure rate of the "control group" of projects that don't take the same course ? I'd be surprised if it's substantially better than 6/10.
There are a lot of serious issues to consider, but you're not going to get much in the way of answers on slashdot.
I've tried using these. Unfortunately, they don't work properly with inheritance.
Not hard at all. Take an extra parameter on container instanciation that refers to the class name. Every time an Object is passed in, verify that it's a member of that class. Easy. Done.
Perhaps I'm not understanding ... it looks like you're just doing an up-front runtime type check.
I suppose you've at least reduced the problem to something that could be detected with a backtrace.
You make that sound far worse than it is.
I don't mean to imply that it's the same thing as a reinterpret_cast -- it's comparable to a dynamic_cast (which is still pretty hideous to a C++ programmer.) Apart from the safety issues, it's also a substantial performance liability. (at least, my experience is that dynamic_cast is very expensive in C++.)
A lot of problems go away if you test properly, or adopt a number of other sensible practices. Most of the arguments against C++ boil down to what happens when an idiot uses it. The bottom line is that no tool is going to allow idiots to develop large scale applications.
Regarding speed, btw -- depends on what you're writing, of course, but have you tried particularly new Java runtimes? I've been doing servlets lately, and have been very pleasently surprised by the performance.
If I were writing internet applications, I'd consider Java. As it is, I'm writing numerical analysis code, and that rules out java. Apart from anything else, bounds-checked element access is a performance killer in itself.
A language can either facilitate encapsulation, or make it difficult. The whole argument against C++ in this thread has been that it's not idiot proof enough. So in this context, the fact that it may be possible to implement encapsulation via clever hacks is beside the point.
That said, there's still language support for encapsulation in all those languages I mention.
Python does not have any access protection on class members. Sure, you can write stub classes, but that requires more design, which eats away at this alleged "rapid development" advantage you're supposed to get from interpreted languages. And it doesn't alter the fact that you don't have private data. Java on the other hand has good data protection, arguably better than C++. Good C programmers can and do encapsulate, but then, good C++ programmers avoid the misfeatures of the language. C++ provides well-defined semantics for encapsulation.
If this were such a problem as you make it to be, one could (easily!) build a container class in Java that checks the types of objects put into it at runtime against a type passed in on its instanciation. (Heck, if it were a real-world problem, one would expect that Sun would have done it by now). Why don't I do it?
Because solving this problem in the general sense is roughly equivalent to writing generic containers. It's not easy to come up with a general solution, and writing once-off hacks is painful after a while. So the result is that you have a culture of subverting type-safety.
Making up objections because they seem like they'd be problems to you, however, makes you no better than those who c
and presuming you have an automatic test suite running after every compile -- which everyone should, no matter the language
If you want to talk about what everyone "should" do, they "should" use C++ correctly, by avoiding the dangerous features of the language (-; The language "should" avoid putting requirements on the user, such as developing test suites just to make sure the program is type safe. Of course test suites are good, but they are not a replacement for static checking. This is not an either-or proposition-- a test suite and static checking is more reliable than a test suite alone. Moreover, you get static checking for free in C++, and you can do other things besides checking type safety with your test suites. The other problem with test suites is that when you develop a library, your test suite can't check client code-- so you're requiring your clients to develop test suites as well.