The Joel on Software Discussion Group

I have heard bad things about Java: slowness, lots of setters/getters to write, verbosity, "new cobol"ism (I don't even know what the old cobol looked like, and many new developers also don't). Even with all these received ideas, I'm starting to like Java.

Java is doing his job. If you code carefully you only get good results. I have used Java for 3 months. I have seen bad UIs and JGoodies. I have seen buggy applications and Eclipse/NetBeans. I have written hard to understand Qt/C++ code and easy to grasp Swing code.

So why the hatred? Isn't just a generation to generation thing?

One reason is that it's just so much work to get anything done in Java. Can anyone remember the code to open a file and read it's contents? It's one line using Python or Ruby.

Steve Yegge eloquently writes about another reason: http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

I hate the way Java tries to straitjacket you into one particular style of programming (e.g., google for kingdom of nouns). Also, I hate the slowness, and not being able to do system programming tasks. I hate the way it has commoditized programming.

That said, there are things that I just LOVE about Java. I like its clean syntax, extensive set of libraries, free high-quality developer tools, and so on.

I am pretty sure that C++ has its warts. But I love it for the kind of applications it lets me write.

For the very same reason "Platform Evangelist" exists in this industry.

cause php and ruby are newer, so they're cooler.

Java/C#/VB.Net thrive in the line-of-business WebCRUD coding world and are three birds of the same feather.  The Cobol/RPG comparisons are apt because they all have the same strong suit: the simple bizapps of their day.

But just as Cobol and RPG had their place so do these modern alternatives.  The economics weigh against cranking out WebCRUD in C++.  As has been stated many times you need to choose the tool for the job rather than going around hammering brads, planing boards, cutting dovetails, etc. with your motorized screwdriver.

The majority of coding work continues to consist of assembling cheap furniture though.  Mostly of the sort that is all screwed together with one fastener type holding the prefabbed components together.

Lots of people prefer the more interesting work like cabinetmaking.  They probably see the Java family of tools as inadequate for their needs and may fear the risk of being chained to such a prefab furniture assembly line themselves if they personally invest much in Java.

It doesn't mean you can't do more with Java and its clones.  I think it has more to do with those visions out of Metropolis.

http://www.youtube.com/watch?v=msL03b8_OfE

It's always funny to hear Ruby or Python mocked for being "cool".  Java made its way based on cool.  Only it wasn't a popular cool, it was more the corporate driven pop sensation cool of Sun dumping a billion (yes billion) dollars on marketing the language.

Java was sold as the solution to everything.  The one area where it has caught on is one area where it wasn't really promoted.

Java *is* slow for a language that constrains me the way it does.

The owners of the language are insulting.  They do things with the language that mere users are not allowed to do.  They tell us that we don't need things for years, then deliver them as features and tell us how great they are.

Oh well, I've given up on Lisp taking over.  I'm going to have to settle for 20 years down the road when all languages become Lisp.

When I did Java it felt like I was wearing shoes which were a size too small.

Yeah, I could get around the place... but it was such a relief to take them off again afterwards.


No multiple inheritance.
Horribly verbose syntax.
Really hard to use libraries which weren't built-in.
General feeling of being in a tightly closed system and unable to tweak it.

java, for what it is, is good; it's good at writing servlets/jsp (which replaced cgi/perl) and hitting the db.

it sucks at desktop, bean/container/ejb/crap-olla ware. All this extra stuff was added by the intellectual set telling us how great complicated oo source code is.

then along came php; which young dudes close to the front adopted, and started using cause...they wanted to escape all the crap oo complication philosophy instigated by the intellectuals. the guys using php were smarter.

here's a clue; less code between you and the use equals better app. java like everything else; over complicated itself.

take a look at google, use to be simple, now, huge complicated company. same thing with everything. once something gets popular, the retards have to reshape it in their own image. it has to be exploited to the fullest extent. it gets trampled on, ruined.

i played with Ruby in 1998. i thought it was shit, stupid; why replace perl? i worked in japan then; so...i thought, some japanese dude created a language, but, instead of creating one that made sense for someone who speaks japanese; he recreated perl.

anyway...to me, it's the same as c/c++ both are awesome; but if you don't know what your doing, you'll shoot yourself in the foot...and php, ruby are like wearing a condom.

It was designed for idiots.  Well that is perhaps a bit harsh but it was designed for mediocre programmers it wasn't designed to be expressive, good, it was designed to not confuse. As such it is a simple, not expressive, not very good language.  That they went and  made slow by putting it on the jvm.  Now the jvm has gotten much faster over the years.  It isn't that bad now, but it still has a long way to go if java is ever going to be considered a strong performer.

The real problem is that it was designed for one thing (adding dynamic content to a web page) but ended up being used for everything except that.

And it wasn't very good at any of them.

It makes me repeat myself.  A lot.

Well. My company successfully uses Java for writing Excel addins for financial analysts. It works. It's quite efficient. We can run the same JAR on Windows desktop PC and on a Linux server. We don't spend hours tracking weird memory bugs.

Sure, it's slower than C++.

"cause php and ruby are newer, so they're cooler."

Actually Ruby is older than Java.

My problem with Java has to do with the ideology, and the types of developers who are attracted to it.

I'm of the opinion that more architecture astronauts live in the land of Java than anywhere else.  Granted, many of their overarching designs are created as a means to get around the ideology of Java, but there it is.

Overloaded Operators can be abused, therefore you can't use them.
Multiple Inheritance can cause problems, therefore you can't use them.

Ad Nauseum.

What I think is strange is that people complain about java being slow and then suggest using php/python/ruby!? WTF...

>It's one line using Python or Ruby.


Same for Perl.

open MY_FILE, "<outfile.txt" or die "PROBLEM OPENING FILE: $!"

Throws exception if an error $! is the error reporting string.

You can also assign the file handle to an regular variable.

Change the > to < and you open for input instead of output.

Finer grained control is possible with other calls.

>the types of developers who are attracted to it.

Correct on the astronauts, also a lot of weak programmers who go to the Java schools that Joel does not like.

And J2EE doesn't help, because it encourages elaborate protocols and the nightmare that is the Enterprise Java Bean.

i love how ruby don't scale, i.e. twitter. and everyone flocked too it like a new religion.

>Sun dumping a billion (yes billion) dollars on marketing the language.

I was stunned.  One day I walked into the old Printers Inc. store on Castro Street in Mountain View and out of nowhere a display table had appeared with about fifteen titles on Java that had magically dropped from the sky the day Java was announced.

My career mistake was not jumping on the bandwagon that moment.  Or jumping on the web bandwagon when knowing how to set a cookie was worth $100K/year.

Make hay while the sun shines.

It's a tool.  Like all tools, it can be misapplied.

I think people hate languages based on either their own biases, or because they once knew someone they didn't like that evangelized a particular technology.

"Java?  Ol' Fred always used to tell us we should program in Java, and that guy didn't know anything!"

If you live in a PHP world, or a C++ world, then using Java isn't going to make any sense to you.  It's not Java, it's you.  It's okay though, there's room for all of the popular languages, and a whole bunch of the unpopular ones, too.

Ooh, one more thing.  Java seems to suffer from "1.0 syndrome".  A whole lot of people tried Java a bunch of years ago, and it legitimately sucked pretty bad back then.  So now they assume it still sucks.

I've programmed AWT in Java 1.1, and I've used Java 6, and let me tell you, it's gotten a hell of a lot better.  Not only in the features of the language (esp. the Josh Bloch driven changes in Java 5), but also in the performance of the JVM.  On a modern PC, a Swing desktop app can perform just fine.

Java is the new COBOL - the languages have nothing in common, but the job you will gey is the same CRUD job that COBOL programmers had when it was called "card walloping". 

What's to hate about the language?  It frees you from most of the geeky concerns of programming, leaving you free to focus on the details of payroll and inventory databases, health care records management, or regulatory compliance -whee!  Really, we shouldn't hate the language itself, but it's a handy target.

@flatso
Even when restricted to interpreted languages it is not performant, c#, pascal, heck even Common Lisp kicks the jvm's butt when it comes to performance. 

Expressiveness well let's see how do you express a function say for a call back?  A dozen lines to setup a throw away class! of course wouldn't want to confuse the simplet.. I mean programmers by allowing them to define a function for a call back. Or heck the language is all about type safety so how do we define a fully type safe generic container? ooh, ooh, I know, I know! You can't, at all, in any way, shape, or form, but just to be nice we will add autocasting and wish real hard.

I'll be the first to admit - I am a newbie, but working hrad to improve.  I have experience only with the common languages used for CRUD:  VB.Net, C#, Java, and VBA.  But I have been exposed to a wide variety of peopl at school and at work, and in my limited experience, I have come to a strong conclusion that the language is less important than the developer.

I have seen developers do things in VBA that others couldn't do in Java.  Not because Java doesn't have the capability, but because the developer couldn't think outside the box to accomplish it.

Although there is definitely truth to using the right tool for the right job, in the hands of a skilled developer, I don't see how the language matters much.  As an analogy, handing me a hammer to drive a nail wouldn't accomplish much.  The nail wouldn't go in straight!  But hand my father a rock for the same purpose, and the nail would slide in perfectly.

Why bash Java?  I'm more concerned about some of the people I have taken classes with ever graduating, let alone getting a job in programming.  I don't think I'm the best, but at least I can logically work through a problem to get a solution.  Some students I know can't do the most basic stuff without someone holding their hands.

Java in their hands would be worthless.  I hope that in mine it will be better.

If you want a job with Java ... a real, corporate job, which is how most of us spend our lives ... you'll have to suffer through ordure like Websphere, JBoss, and every other architect-driver "framework".

Then you'll know why developers hate Java.

Java makes you sick! http://www.breitbart.com/article.php?id=D90IDMBG5&show_article=1

Java does its job (reliable corporate systems) well, but as a starting language it is really the Postmodernism of programming languages. The learning curve is so ugly that everyone just pastes and modifies until they get so used to imitation that they don't know whether they learnt it or not.

Java was invented due to the need for more programmers, due to the advent of the World Wide Web.

The problem was, there weren't enough programmers, because programming is hard and only a tiny percentage of folks can learn it.

Enter Java: "Programming for Dummies".

Sun mega-marketing it as the new enterprise sliced bread to all managers before it was even ready to do a decent "Hello World", and the few years of misery that followed from that.

Swing. Need I say more?

When there finaaly was a decent implementation, Sun "outlawed" it.

Architecture Astronout flytrap.

Design by committee.

....

At one point (sort of just before J2EE), it got even a quite enjoyable language, as long as you didn't have to do a GUI. Didn't last.

I still remember seeing applets running in HotJava for the first time in early '95 and getting a feeling like the time I'd seen Mosaic for the first time almost exactly two years earlier: "wow - this is going to change everything".

Running downloadable applications in browsers on different kinds of hardware was exactly the problem I had been looking at in '94 - so when I saw Java I recognised it was better than my efforts and had some awesome developers behind it (I was already familiar with the work of James Gosling and Arthur van Hoff).

So at that point things looked pretty good.

Fast forward a few years and things basically went off the rails (!) when Java went "enterprise" through no real intrinsic property of the language or runtime it was suddenly the platform of choice for your twenty-layer, four tier, dot-bomb architecture. Most systems I remember from those years seemed to be built largely as a CV padding exercise - Java has a lot of features and everyone seemed to be convinved that you had to use every single one of them (and every design pattern) in every single system.

These days, Java is pretty good and I can think of a lot of types of systems where it would be the obvious choice. But I can also think of a lot of systems where I suspect you would be better off using something else.

In my view it is probably the legacy of Java being associated with some of the development disasters of the dot bomb era that has prejudiced us old-timers against it. There isn't *that* much wrong with it although it does look a bit verbose and clunky at times.

I don't hate it, but thankfully I don't love it anymore either. It's just another tool to be used when appropriate.

"Java was invented due to the need for more programmers, due to the advent of the World Wide Web.

The problem was, there weren't enough programmers, because programming is hard and only a tiny percentage of folks can learn it."

Why exactly is that bad? If it makes solving business problems easier and cheaper, I'm OK with it. I guess the untold reason is that many programmers think "Java allows my unskilled competitors to solve many problems well enough (NOTE: not "optimally") to undercut my market position". Well, that's tough, but why should the world give a damn about it? There will always be applications where Java doesn't cut it and some hardcore C/C++ coding is needed. And if you're not into that, go get some domain knowledge.

Maybe Java will make programmers without any domain knowledge useless. Maybe that's not such a bad thing.

>> If you want a job with Java ... a real, corporate job, which is how most of us spend our lives ... you'll have to suffer through ordure like Websphere, JBoss, and every other architect-driver "framework". <<

Which is also why "Java portability" is a lie.  Anything non-trivial has to swim in a software ecosystem.  The rudimentary language-level skills may be portable but those are almost trivial.  We can bring a Mort up to speed on the language in weeks.  Doing much that's useful takes a lot more time and experience.

I don't disparage Java or those clones like C# because for many purposes they're the only game in town anymore.

"programming is hard and only a tiny percentage of folks can learn it."

It's worse then that. Even quite good programmers are prone to writing very serious bugs in C and C++. Your attention wanders for a second, and blam, you have a buffer overrun that smashes the stack. I don't think Java keeps people from writing buggy software,  I think it just makes it less likely that they'll create one of those particularly nasty bugs that can end up executing  arbitrary code.

I'm a little dumber now, for having read this thread.

>> It's worse then that. Even quite good programmers are prone to writing very serious bugs in C and C++. Your attention wanders for a second, and blam, you have a buffer overrun that smashes the stack

Women have it even worse.  Their attention wanders and then they have an accidental pregnancy.  I can only imagine what it's like to trip and fall, and suddenly realize you've become impregnated.

"Even quite good programmers are prone to writing very serious bugs in C and C++. Your attention wanders for a second, and blam, you have a buffer overrun that smashes the stack."


Um, that'd be C, not C++.

In C++ we use container classes to avoid this.

Oh, Jimmy, that's so sweet and naieve.

You can use containers in C++ and "forget" to use the properly or "forget" to delete them properly and leak memory too.

I just find this assertion that there's a "magic bullet" for using C++ to be quite naieve is all.  Sure, in recent years, they've got "smart pointers" which auto-delete.  But the above assertion remains -- you gotta stay on your toes, even with C++.

"But the above assertion remains -- you gotta stay on your toes, even with C++."

Sure you have to stay on your toes, but memory management is not nearly as difficult in C++ as people make it out to be. RAII is not rocket science.

>"You can use containers in C++ and "forget" to use the
> properly or "forget" to delete them properly and leak
> memory too."

We were discussing buffer overflows, not memory management.

If you're getting buffer overflows in C++ you're definitely, positively Doing It Wrong.

I think Java got popular because:

a) It made teacher's lives easier. Compared to teaching C, teaching Java is a dream come true.

b) It was free and could be done with notepad/command prompt.  The price would be a big plus for educational establishments.

c) It had a standard GUI, C and C++ didn't.

d) It was very hyped and trendy - appealed to hippies and students who wanted to stick it to the boring old traditional programmers.

Believe it or not, I used to be a Java fanboy. I've got thousands of pro-Java posts in comp.lang.java.advocacy, I personally invented Java generics*.

I went to Java from C.

Comparing Java to C on paper, Java wins every time. After a year or so of trying to write real apps using it I finally realized that Java simply can't hack it for desktop apps and probably never will. It's not that there's any major problems, just a lot of little things which eventually bring things to a halt when the program starts to get big.

Eventually I gave up and tried C++ and haven't looked back since. Horrible syntax and dynamic class loading aside, C++ has had a solution for every problem. It just keeps on scaling and has never run out of steam in the ten years I've been using it.

[*] Sort of. When all the bulletin boards and newsgroups were discussing "how shall we do generics in Java" I was busy proposing my scheme to anybody who would listen. James Gosling, et. el. were going down a completely different path.

A year or so later, and... bingo! Java suddenly gets generics *exactly the same* as what I was proposing.

Were the powers-that-be watching the message boards and newsgroups for ideas...? I don't know, but in my mind I invented Java generics.

PS: I had some other proposals as well if anybody's still interested...

I cannot understand how Microsoft can use something like ':' to denote extension or inheritance. Totally confusing for a first-time user. Java, on the other hand, uses clear-cut literals like 'extends' or 'implements'.

> If you're getting buffer overflows in C++ you're definitely,
> positively Doing It Wrong.

Of course you are doing it wrong when it happens.  The problem is the language permits it.  You are just shifting the blame to the programmer, "You are too stupid to use C++."

Here are some C++ gems.

void foo() {
    char buf[80];
    wstring str(80, (wchar_t)' ');
    sprintf(buf, "%s", str.c_str());
}

Arrgh, the stack just blows up.

Or, how do you put object pointer into stl containers?  You can't directly.  Notice how all the Stl tutorial uses simple int or char types?  Because it's way too complicate to put a real object into containers.  To put an object into any Stl containers properly, you have to implement the copy constructor, the operator=, the default constructor.  Talk about poor expressiveness in Java; try that in C++.

Don't get me wrong I program in C++ extensively.  I like it a lot.  I also program in Java.  Each language has their advantage and disadvantage.  I don't know Cobol and I would keep my mouth shut about it.  I don't understand why people would bash a language without really understand it or using it.

"If you're getting buffer overflows in C++ you're definitely, positively Doing It Wrong."

Sure. There are good practices that will nip buffer overflows in the bud. But the language doesn't enforce those practices. They depend on the discipline and attentiveness of the developers. Big, sophisticated, development shops continue to issue plenty of security bulletins involving buffer overflows, so I think it's pretty clear that even very skilled programmers occasionally suffer from lapses of attention and discipline. Programming in a language like Java doesn't stop the lapses, but it's a lot more likely they'll cause a run time exception, rather then the execution of arbitrary code. This seems to me not a small consideration, and one that even very good programmers should think about.

"To put an object into any Stl containers properly, you have to implement the copy constructor, the operator=, the default constructor."

Nope. Normal objects will go in there just fine.

class foo {
 std::string a;
 std::vector<int>b;
 my_object c;
 ...
};

std::vector<foo>v;

Works just fine without any copy constructor, operator=, etc.

The only time you should really need to write a copy constructor, etc. is when you're using the "pimpl" idiom.

Even then you wouldn't need to write them to because you normally don't put complex objects directly into a vector, you make a vector of pointers instead.

>"You are just shifting the blame to the programmer."

Yep.

I also insist that my bridges and skyscrapers are designed by  qualified engineers. Is that wrong?

>"But the language doesn't enforce those practices."

Life is full of dangerous objects which we need to *learn* to use safely.

Are you saying we should all use plastic safety knives to "enforce" safe food preparation? I think the quality and variety of food would go down if we did.

"Big, sophisticated, development shops continue to issue plenty of security bulletins involving buffer overflows, so I think it's pretty clear that even very skilled programmers occasionally suffer from lapses of attention and discipline."

Typing 'char[100]' instead of 'std::vector<char>' isn't a "lapse", it's Doing It Wrong.

For the reasons why this happens, go look at the other thread where the C programmers say that "STL is a mess" or that "STL is slow" or any of the other tired list of excuses which mean that they never really bothered to learn STL.

Buffer overflow in 2008 is not a 'lapse', it's bad programming.

> sprintf(buf, "%s", str.c_str());
>
> ...the stack just blows up.


FWIW, if I try to compile that code I get:

warning C4996: 'sprintf': This function or variable may be unsafe. Consider using _snprintf instead.

>>"You are just shifting the blame to the programmer."
>
> Yep.
> I also insist that my bridges and skyscrapers are designed by
> qualified engineers. Is that wrong?

So you are bashing the programmers now instead of the language?  May be in the Java's case, it's because of bad programmers writing bad code?  Was that in your case in the past?  You don't have to over-architect in Java.  You don't have to write complicate code in Java.

>> sprintf(buf, "%s", str.c_str());
>>
>> ...the stack just blows up.
>
>FWIW, if I try to compile that code I get:
>
>warning C4996: 'sprintf': This function or variable may be
>unsafe. Consider using _snprintf instead.

So the latest version of MSVC can do a better Lint check, why is that not in the language?  Does foobar C++ compiler do the same check?

And how much extra time as a programmer I have to spent to count up the number of bytes I need for the _snprintf?  Oh, is that Unicode or Ascii now?  I wonder whether the code would compile in a 64-bit compiler.  Or should I spend the effort in writing macros and defines to ensure it can compile in all forms of compilers?

Every language has its little quirks.  If Java doesn't work for you, it doesn't mean it doesn't work for other people.  Other people would make it work and productive.

> A year or so later, and... bingo! Java suddenly gets generics
> *exactly the same* as what I was proposing.
>
> Were the powers-that-be watching the message boards and
> newsgroups for ideas...? I don't know, but in my mind I
> invented Java generics.

Please.  I am sure you are a smart guy but as you would find out there are a lot of smart people in this world.

Generic is not a new idea.  Many languages have it before Java - Lisp, Dylan, C++, etc.  And Gosling is a language guy and knows Lisp very well.  I suspected he knows about a thing or two about generics.  Java's generics are very similar to C++.  I would assume they pick that syntax and design to follow the familar-to-programmers route.

As you have demonstrated in your proposal, you borrow the C++ syntax.  So would the others.

@JimmyJones

"Typing 'char[100]' instead of 'std::vector<char>' isn't a "lapse", it's Doing It Wrong."

This alone does not make a buffer overflow happen.

Don't say that just using a std::vector is a shield against buffer overflows, because it isn't. If I have a std::vector<int> vec of 100 int's and do

vec[100] = 2;

I get a buffer overflow, because operator[] is not range-checked.

"Are you saying we should all use plastic safety knives to "enforce" safe food preparation? I think the quality and variety of food would go down if we did."

Asking somebody to carve a prime rib with a plastic knife would be silly. Handing out razor sharp filleting knives to airplane passengers so they can butter their dinner rolls would also be silly, even if everyone on the plane is a surgeon.

All I'm trying to say that if other engineering considerations permit, having a language that catches errors and forces them to a known state can be a really good thing.

I feel silly having to point this out, but when something fucks up it's *always* the developers fault.  It may be understandable or typical, but ultimately that's where the fault lies, and this doesn't change when going from C++ to Java.

Java doesn't change the number of things that can go wrong, all it does is change what those things are.  Any non-trivial Java application is going to force its developers to manage memory, Java didn't get rid of this necessity, despite what the marketing hype wants you to believe.  What it did do, however, is make it so any developer working in Java needs to understand how the Java GC works, when it will start collecting, the general behavior that it exhibits on the various JRM's, et al.

Anyone who believes Java requires less of the developer is _absolutely_ fooling themselves.


vec.at(100) = 2;  // this will throw an exception.

JRM = JRE.

time for bed...

"Java doesn't change the number of things that can go wrong, all it does is change what those things are."

I disagree. I think there is a clear difference between Java or C# and C/C++ and it's why I've kept harping on buffer overruns. Writing in Java or C# will not keep you from screwing up a buffer, but in many cases it can limit the damage that results. If you overrun a buffer in Java you will get a run time error and your program will come to a grinding halt. If you over run a buffer in C/C++, much of the time absolutely will happen, but sometimes you will stick garbage in the return pointer, and then you have no idea what will happen. You could format your hard disk, you could install a root kit, you could transmit your bank account to a database in Nigeria.

Software developers will inevitably screw up. To me it seems like an obvious engineering goal to try to limit the amount of damage that can be inflicted by common screw ups. It's obviously not the only goal, but I think it is too often overlooked.

Modern C++ compilers include buffer overflow detection:
http://en.wikipedia.org/wiki/Stack-smashing_protection
http://www.informit.com/articles/article.aspx?p=430402&seqNum=8

My opinion is here...

http://bijuthom.blogspot.com/2007/10/why-everything-sucks.html

http://reddit.com/r/programming/info/utqb/details

I asked the exact same question on reddit a while back.  200 responses.

You also have to look at the other side.  How many million developers like or work with java.

I'm a Java web developer (SCWCD).  As a language, I love Java, but to build any kind of enterprise application, you need to know a lot more, which gets annoying fast. 

Most Java shops use hibernate and spring and sometimes struts.  You must know Eclipse (it's free, but it sucks).  Along with that comes the ability to write build scripts, because your IDE can only do so much.  Don't forget about source control - we use CVS and VSS, but I also know Subversion.  Unless you have a narrow role, you'll probably also need to know JSTL and maybe Tiles.  Then of course you need something to run your application such as Tomcat or a complex containers such as JBoss or Weblogic.  Only after you have tackled all this, can you begin building an enterprise Java application. 

Most of the time I'm not writing Java, which is why I don't enjoy programming as much as I used too.

"And how much extra time as a programmer I have to spent to count up the number of bytes I need for the _snprintf?"

In C++ you shouldn't be using sprintf in *ANY* form. sprintf is a C idion from the 1970s and is Doing It Wrong.

My code would look something like this:

string s;
TextWriter(s) << "The value is: " << n;

> If I have a std::vector<int> vec of 100 int's and do
>
> vec[100] = 2;
>
> I get a buffer overflow, because operator[] is not
> range-checked.

So?

That's like saying, "If I type this I'll get a bus error":

*(int*)0 = 0x666;

The thing is ... I wouldn't type that code any more than I'd type "vec[100] = 2"

If I'm using untrusted input to access a vector I'll use "at()" instead of operator[]. Anything less would be Doing It Wrong.

>"If you overrun a buffer in Java you will get a run time
> error and your program will come to a grinding halt.
> If you over run a buffer in C/C++..."

Ummm....you can do *exactly* the same thing in C++ if you want to. It's not even difficult to do, the only thing standing in your way is a couple of weeks of learning.

>"Generic is not a new idea.  Many languages have it
> before Java - Lisp, Dylan, C++, etc. "

I'm not saying I invented generics, I'm saying that what I was proposing for Java ended up as reality. At the time there wasn't anybody else proposing the method (in fact many argued against it).

Most people were focusing on ways of removing type-checks in the JRE. My method doesn't do this but it does remove all the typecasts in the source code (which is what was annoying me).

Using Vector without this extension it was a godawful mess.

"Ummm....you can do *exactly* the same thing in C++ if you want to. "

But the difference between "can" and "must" is the heart of the argument here. Certainly, you can write robust and safe code in C++. However, the language does not it enforce it. You may never make typos or mistakes, but I certainly do. I have to switch back and for between Python and C++ every month or so. I can promise you that one of these days I'm going to be distracted and type vec[100] = foo, even though I know darn well that I should be typing vec.at(100) = foo. Kind of shame if that little mistake ends up turning somebody's home computer into a zombie on a bot net.

I'm not trying to take your sharp knife away from you. I'm just suggesting that in many cases the plastic knife is perfectly adequate, and using it avoids some stupid and needless injuries.

>"the language does not it enforce it."

There's nothing preventing it - operator[] can do range checking if you want.

In fact ...

<drumroll>

VC++ has "plastic knife" mode enabled by default. "vec[100] = foo" doesn't corrupt memory in VC++, it throws an exception.

To get it to corrupt memory you have to do this:

#define _SECURE_SCL 0
#include <vector>

vec[100] = foo;


>"Kind of shame if that little mistake ends up turning
> somebody's home computer into a zombie on a bot net."

a) Try typing "jvm exploit" into the little box at google.

b) Most people's machines end up on botnets because they run .exe files hoping for "free cursors!!" or some such. There's no defense against this.

Just dis ;)

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

"a) Try typing "jvm exploit" into the little box at google."

But clearly you are not trying to say that Java is responsible for more or even the same magnitude of exploits that C/C++ have caused over the years. No programming language is immune to exploits. But C/C++ is probably one of the worst offenders. Why? Because in the hands of novices, C/C++ is much more dangerous than Java is.

"b) Most people's machines end up on botnets because they run .exe files hoping for "free cursors!!" or some such. There's no defense against this. "

That doesn't mean that we shouldn't do everything that we can to fix exploits and program in a safe manner. The world is not black and white. Besides, I think that you are making an unsubstantiated claim. Do you actually know the percentage of computers that become botnets due to people running untrusted .exe's hoping for "free cursors/porn"? Do you know for certain that the number of computers turned into botnets from user error exceeds those turned into botnets by program exploits? I would think not.

It is a losing battle to try and argue that C/C++ is as safe as Java in the hands of the average programmer. Trying to do so simply shows the bias that the original OP is talking about.

>> "And how much extra time as a programmer I have to spent to
>> count up the number of bytes I need for the _snprintf?"
>
> In C++ you shouldn't be using sprintf in *ANY* form. sprintf
> is a C idion from the 1970s and is Doing It Wrong.
>
> My code would look something like this:
>
> string s;
> TextWriter(s) << "The value is: " << n;

Are you confused with your little library with standard language features again?  There's no such thing as TextWriter in standard C++.  We are talking about standard language features and standard libraries.

And I don't like C++ Stream classes.  Where's my standard formatter API?  I want to format a timestamp easily, not writing another huge class for it.

"Actually Ruby is older than Java."

Not in any meaningful sense.  Work on Java began in 1991; work on Ruby began in 1993.  Both languages had their first public release in 1995.

>>"Generic is not a new idea.  Many languages have it
>> before Java - Lisp, Dylan, C++, etc. "
>
> I'm not saying I invented generics, I'm saying that what I was
> proposing for Java ended up as reality. At the time there
> wasn't anybody else proposing the method (in fact many argued
> against it).

My point was that the Java Generics is very standard affair.  Most sane persons would do it that way given Java's history and design philosophy, and given C++'s template influence.

If you ask me to design class in Java, I would come up with a form similar to the current design because OO class is a well-known design and done many times in other language.

If your generic design was unique and different from any other languages and it ends up as the exact same thing in Java, then yes I would say they stole your design.  If not, please...

"And I don't like C++ Stream classes."

Amen. I/O streams is the one and only area of C++ where I revert back to good old C. I mean, really, how *do* you format a 32-bit unsigned integer as a zero-padded hexadecimal value with capital letter? Ah, yes: "%08X".

"Are you confused with your little library with standard
> language features again?"

Hey... I'm not the one saying that C++ is dangerous because sprintf() is dangerous.



I'll admit that C++ needs a bit more work to be complete:

* Standardized smart pointers
* Date/time classes
* Threading
* etc.

Most of this is being addressed in C++0x, along with new language features to make it easier to use.

If only we could deprecate a few things while we're at it - eg. arrays would be one thing I'd get rid of - that alone would make the whole language much safer when used by unschooled C hacks. Sadly, it'll never happen...

> "I don't like C++ Stream classes."

Neither do I - that's why I've developed my own over the years. C++0x could include a new set of stream classes without doing any harm.

"My point was that the Java Generics is very standard affair.  Most sane persons would do it that way given Java's history and design philosophy, and given C++'s template influence."

Yep. But in my mind I know I did it all by myself without copying anybody else, and I did it before the official version.

The only point I was making is that I used to be a big Java fanboy until real experience taught me better - that Java doesn't cut it for proper desktop applications.

>> But the difference between "can" and "must" is the heart of the argument here.

Now you're getting into ideology , which is the single most distasteful thing about Java (and the developers who push it).


>> If only we could deprecate a few things while we're at it - eg. arrays would be one thing I'd get rid of - that alone would make the whole language much safer when used by unschooled C hacks. Sadly, it'll never happen...

Oh please.  A large part of the identity of C++ is the fact that it's a mult-paradigm language.  Let's not start chopping off parts of C++ because some religious nut decided people shouldn't be using other parts of the language.

The last thing C++ needs is a Java religious nut turned C++ religious nut trying to enforce "The Right Way" on the rest of the "unschooled hacks" in the world.

"Steve Yegge eloquently writes about another reason:

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html "

Eloquently?  Not hardly.  This is exactly the kind of thing I hate.  Mental diarrhea.

Much like Joel's "Martian Headsets" piece, Steve Yegge prattles on endlessly with a stupid story, when he could have made his point in a few sentences.  In fact, one of the replies does just that:

"the rant wasn't against OOP... the rant was against Java's interpretation of OOP. In their interpretation, actions are turned into verbs unnecessarily. Factories, proxies, and enablers litter the landscape with verbal garbage.  Other languages manage to be object oriented without spiraling down into object fetishism like Java has."

> "Let's not start chopping off parts of C++ because..."

"Arrays are evil" - the C++ FAQ.  :-)
 
http://www.parashift.com/c++-faq-lite/containers.html#faq-34.1

I agree with the above ... ripping the unsafe stuff out of C/C++ just makes it another Java.

How about *cough* cava *cough* a brand new c++/java clone that has the protections of java, but doesn't need a jvm ;)

I like java myself ... but the extra paraphenalia you have to deal with (frameworks, etc etc etc) is tedious. And the types of problems you typically get to solve when using java aren't too exciting either.

So, yeah, I recently decided to learn C++ much better (still working on my CS degree, while working days doing php web stuff --- oh yeah, PHP REALLY sucks!)

"ripping the unsafe stuff out of C/C++ just makes it another Java. "

Maybe I should be more specific...

In a cleaned-up C++ you could get rid of new[] and delete[] without any harm - it would just enforce use of container classes like vector (and that's a Good Thing).

Obviously C++ still needs pointer arithmetic, pointer[], etc.

I wonder if Bjarne would have added arrays to C++ if STL had existed before he added them. I'm guessing he wouldn't.

If arrays hadn't existed STL would have been impossible to write. Arrays and pointers in C are essentially the same thing, after all.

>> I wonder if Bjarne would have added arrays to C++ if STL had existed before he added them. I'm guessing he wouldn't.

I think what worries me the most is the increased pomposity of your posts if arrays are taken out of C++.  Gosling stole your ideas about Java Generics, and Bjarne stole your ideas about how to cripple C++.

You don't need new[] and delete[] to write STL.

"You don't need new[] and delete[] to write STL."

Then in what? Assemblers?

Java doesn't leave enough freedom to the programmer, IMO.

Why can' I use an unsigned int 32? Or an unsigned byte?
Why do I have to catch exceptions I'm not interested in?

C# behaves a lot better in that respect. It's a programmer's language. Heijlsberg's thinking is less academic and more practical than Gosling's and it shows.

"You don't need new[] and delete[] to write STL."

Soooooooooo, what would the implementation of std::vector look like, then?

We're not going to redesign C++ without all its C compatibility stuff this week, sorry.

We can write code as if new[] and delete[] didn't exist, though, and use the STL (I don't know you but that's what I do, use it, not implement it). Of couse the stuff is still "down there" but this is no problem.

>> We can write code as if new[] and delete[] didn't exist

Now there's a novel idea :)

Unfortunately, the likes of Charles, Jimmy Jones, et al, will tell you the mere fact that it exists is enough to condemn the language :)

Anominal, agree with you 100% on C#.  I don't like how MS is treating .Net as it's own personal stomping ground for 3.0/3.5 (2.0 was the sweetspot in the technology, imo), but C#, as a language, isn't bad at all.

"Now there's a novel idea :)"

I was merely trying to summarize :)

We shouldn't be discussing C++'s purity in 2008. When I want a beautiful, pure, virginal OO language, I choose Eiffel. But then nobody pays me :)

>> "You don't need new[] and delete[] to write STL."
>
>"Soooooooooo, what would the implementation of
> std::vector look like, then?"

Pretty much like it does now.


Think: How would you write vector::reserve() using new[]?

>"Unfortunately, the likes of Charles, Jimmy Jones,
> et al, will tell you the mere fact that it exists
> is enough to condemn the language :)"


Ummm... somebody said "doesn't enforce...".

I said that removing new[] and delete[] (for example) would help to stop bad practices - you don't need them for anything now we have vector<>.

How is that condemning?

> It was designed for idiots.  Well that is perhaps a bit
> harsh but it was designed for mediocre programmers it
> wasn't designed to be expressive, good, it was designed to
> not confuse.

Brian,

If your code confuses, then how could it hope to be either expressive or good?

"Coding in C is like sending a 3 year old to do groceries. You gotta tell them exactly what you want or you'll end up with a cupboard full of pop tarts and pancake mix."

:)

"It was designed for idiots."

I don't see why people see this as a weakness. I think there are too many software products/systems in this world that require you to hire from the top 10% of the developer population just to keep from having your programmers completely screwing up your app.

I've come to believe that you should design applications and frameworks such that anyone in the top 50% of the programming population can be successful with them. If not, you've completely failed in my opinion. Joel and the rest wouldn't have to extol the virtues of hiring top candidates if so many languages and tools weren't designed to require programmers to be rockstars just to use them.

To me the sign of a truly good language/framework is that it can be used and maintained by average programmers. If you need to hire from the top 10% to be successful then you've failed. 

But I guess some people are so insecure about their own abilities that they think providing languages and frameworks for the common programmer results in less job security. Go figure...

Java is for idiots? I think that spot is reserved for VB...

(Okay, just kidding...)

The problem with it being designed for idiots is that it locks out all sorts of possibilities that might map to your problem's domain.

For fun, let's pretend Java didn't have the String class.  Implement it.

The language designers work with a different set of abilities than the language users.  They see the need for operator overloading in the String class, but don't think you should be allowed.

Even if it were a good decision, it is condescending and insulting.

"The problem with it being designed for idiots is that it locks out all sorts of possibilities that might map to your problem's domain."

I disagree. There is a difference between having the "default way" provide capabilities that even idiots can use and not providing advanced capabilities in the first place. C++'s default way is virtually impossible for the average programmer to apply correctly without messing up in a big way. Java's default way is very "average programmer friendly". It is fine to provide advanced features that only advanced programmers can understand.

As for it being condescending and insulting, that sounds like a personal problem to me. Get over it. I don't know why you'd be offended by the idea that not all programmers are rock stars.

"When I want a beautiful, pure, virginal OO language, I choose Eiffel.  But then nobody pays me"

The French screwed up Ada so everyone became scared of anything that sounded French :-p

I think String is really special, given the design goal of Java: Security all the way.

And it's the only exception. Also most other languages have their own special string implementations different from other objects.

Even C++ doesn't allow you to implement object literals.

So, people just need to get over this one :)

>"...given the design goal of Java: Security all the way."

How would operator overloading have weakened Java security?

>"C++'s default way is virtually impossible for the
> average programmer to apply correctly without messing
> up in a big way."

Can you explain to us what C++'s "default way" is?

malloc(), strcpy(), etc. are only the "default" for C programmers.

Anybody starting fresh should be learning vector and string, and they're no harder than Java.

I don't understand this belief that doing C++ 'correctly' is difficult. It isn't. std::vector and std::string make life easier, not harder.

I'm sure I'd leak/corrupt memory if I was constantly messing around with C-style strings and arrays or doing manual memory management - that's why I don't do it.

Java's only real advantage over C++ is a big class library for common tasks. The Java language itself is more a negative for anybody with the will to learn and improve their skills - you'll never learn to cook if all you ever allow in your kitchen is FTC-approved safety knives.

> "There's no such thing as TextWriter in standard C++.
> We are talking about standard language features and
> standard libraries."

Ok, so use std::ostringstream, that's an ISO standard for treating a string as a file.

The point is that there's no excuse for buffer overflow. Stop  guessing at "maximums", use a on object which grows as needed. That's Doing It Right.

Bottom line: Stop writing C code, start writing C++ code.

... and stop tarring C++ with C's brush. They're not the same language.

Jimmy Jones:
"Java's only real advantage over C++ is a big class library for common tasks."

Nonsense. Here are a few the reasons I prefer Java (though the language has somewhat gone to hell over the last few years):

* No undefined behavior. When you write erroneous code, you know that it'll either issue a compiler error or throw a RuntimeException. All other cases issue well-defined behavior.

* Context-free grammar. For one thing, the C++ grammar is so context-dependant that compiler implementors can't separate the lexical and semantic phases, making for eternal compile times compared to Java. But much more importantly, when I'm *reading* code, I have to parse it in my brain. Having a clean, context-free grammar means I spend less time mentally parsing the code.

* No header files. No macro preprocessor. Semantic imports rather than lexical #include. For one thing, that makes it much easier to follow along in the debugger, since the source files don't go through a bunch of text processing before hitting the compiler. Also: writing header files sucks. Hard. I prefer to write my code once. If the compiler needs to consume metadata to link with other libraries, it should be responsible for also *producing* that metadata (e.g., in the Java class files) rather than asking the programmer to type everything twice.

* Arrays know their own size. It's remarkable that, after 30 years of C and C++, the programmer still has to keep track of an array's length. In Java, an array is implemented like this:

struct {
  int length;
  void* data;
}

Brilliant!

......

By the way, Jimmy, if you're responsible for the Java generics implementation, I'd personally like to punch you in the face.

Implementing generics entirely in the compiler (with type-erasure), and leaving the casts in the JVM is actually, in my opinion, the worst language-design decision not made by Larry Wall.

>> By the way, Jimmy, if you're responsible for the Java generics implementation, I'd personally like to punch you in the face.

Implementing generics entirely in the compiler (with type-erasure), and leaving the casts in the JVM is actually, in my opinion, the worst language-design decision not made by Larry Wall.

Despite the fact that a few of your points are misguided, I'm going to have to give you 2 thumbs up :)  That last line really tickled me, lmao.

Really though, I think you should quit poking the monkey, maybe he'll quit flinging shit.

"It's remarkable that, after 30 years of C and C++, the programmer still has to keep track of an array's length."

If they still insist on using arrays, that is :)

"Arrays know their own size. It's remarkable that, after 30 years of C and C++, the programmer still has to keep track of an array's length."

How many time do I have to repeat?

"Arrays are evil, use std::vector!"

I've said it at least 37 times just in this thread.

"No undefined behavior. When you write erroneous code, you know that it'll either issue a compiler error or throw a RuntimeException. All other cases issue well-defined behavior."

Not "undefined", but Java has plenty of indeterminate bahaviour. Did you know that iterators aren't thread-safe?

"Having a clean, context-free grammar means I spend less time mentally parsing the code."

Swings and roundabouts. C++ is much terser so you get more code on a page. This makes it much easier to read the code if it's well written and the overloads logical.

This is where the Java folks say "but not all code is well written!!" True, but that's no reason for you or me to dumb ourselves down.


"Implementing generics entirely in the compiler (with type-erasure), and leaving the casts in the JVM is actually, in my opinion, the worst language-design decision not made by Larry Wall."

There's no other way. Java is all "Safety first!" and bytecode can be hacked with a hex editor. If you leave out the typecheck you can get undefined behavior.

BenjiSmith: "* No undefined behavior. When you write erroneous code, you know that it'll either issue a compiler error or throw a RuntimeException. All other cases issue well-defined behavior."

As far as I know, an integer overflow will not cause an error to be thrown.  I wish that any overflow would.  How does one get this?

Sincerely,

Gene Wirchenko

"How would operator overloading have weakened Java security?"

I am probably mistaken, but I am quite sure I read that String design is influenced a lot by security considerations, in particular for classloader.

At the same time I think that quite a few "design decisions" are just excuses for avoidances of implementation difficulties.

"How does one get this?"

I guess the performance penalty for checking native type operations is too high.

You might use Integer/Long/Floats if you want to be sure.

Jimmy Jones:
"How many time do I have to repeat? 'Arrays are evil, use std::vector!' I've said it at least 37 times just in this thread."

Yeah. I agree with you.

My point is that Java arrays are not evil, so there's no need to fallback onto a library implementation when the language feature works well as is. Of course, the List interface is there for when you want a growable collection, or when publishing/consuming a third-party API.

Jimmy Jones:
"Not 'undefined', but Java has plenty of indeterminate bahaviour. Did you know that iterators aren't thread-safe?"

Good point. Though I still think the precision of the Java language spec is a boon to both developers and compiler vendors. An unambiguous standard makes everyone happy.

Jimmy Jones:
"C++ is much terser so you get more code on a page. This makes it much easier to read the code if it's well written and the overloads logical. This is where the Java folks say 'but not all code is well written!!' True, but that's no reason for you or me to dumb ourselves down."

We'll just have to agree to disagree. Whenever I have to look at some C++ code, I think about how the language could have been *exactly* as terse, while still ironing out its lexical ambiguities and undefined behavior.

Expecting a language to have a concise, consistent, and well-defined set of rules isn't "dumbing down". Frankly, I wish Strousup had "dumbed down" a little less, and designed a language that's at least internally consistent.

Jimmy Jones:
"There's no other way. Java is all 'Safety first!' and bytecode can be hacked with a hex editor. If you leave out the typecheck you can get undefined behavior."

Nonsense. The .NET clr handles generics by including the parametric type-info in the assembly. Generic specialization occurs at runtime, producing new jitted code for each different type (a Foo<int> produces a different runtime class than a Foo<float>, however all reference types share the same code).

It's not that I object to the expense of the cast at runtime. I object that the Java type system is now essentially broken, since the JRE can't enforce the difference between a Predicate<String> and a Predicate<Double>.

"Frankly, I wish Strousup had "dumbed down" a little less, and designed a language that's at least internally consistent."

Have you read "Design & Evolution of C++"? There's many things Bjarne wanted to do with C++ but he had his hands tied by backwards compatibility with C. Without this compatibility, C++ would be a better language ... but a minority language - like Haskell or Smalltalk.

Damned if he did, damned if he didn't.

In the end it's better to have a powerful language with a bit of cruft than a dead language. The cruft can safely be ignored unless you're a C++-basher, in which case it shall be trotted out and paraded in every language flamefest.


>"My point is that Java arrays are not evil, so there's
> no need to fallback onto a library implementation when
> the language feature works well as is."

...and my point is that arrays have nothing to offer C++. They're worse than std::vector in every conceivable way.


>"The .NET clr handles generics by including the
> parametric type-info in the assembly."

ie. .Net has extra support in the virtual machine.

The same sort of thing was considered for Java but at the end of the day the decision was made to not change the JRE. The result is what we see.

"The cruft can safely be ignored unless you're a C++-basher..."

I just wonder could we keep these conversations civil without name calling?

He should open source the book D&E of C++. No one is going pay $70 to read it.

>> My point is that Java arrays are not evil, so there's no need to fallback onto a library implementation when the language feature works well as is.
--

It should be noted that the philosophy of C++ is different than that of Java.  Bjarne has stated time and time again that he would rather see a library implementation rather than direct language support.  The fact that this has been possible so far says great things about the expressiveness and flexibility of C++.  You could never write a direct array replacement in Java the way you can in C++ because Java doesn't allow operator overloading (at best you'll get a close approximation with a slightly different syntax).

Also realize that one of the goals of C++ was to give the developer control when he needed it (this is something Jimmy Jones doesn't fully understand either).  Array's are not "evil" in any sense of the word, they're just _possibly_ problematic (depending on their usage).  The great thing about arrays, however, is the ease with which you can allocate them on the stack (vector is completely heap based).  Sometimes this is an _advantage_.  When it is, C++ will let you do what needs to be done.


C++ can be treated as high level as Java, but it can also be treated as a much lower level language than Java ever could be.  If you take a close look at .Net/LINQ, you'll see that it's just a compiler frontend for a set of library calls, said library calls look something like so: my_set.where<my_class>(predicate).  C++ developers have been using this idiom for *years*, which is why we sometimes look at the 'new' features coming out in Java/.Net and laugh.

The problem is that Java people look at the ability of C++ to drop down as low as needed and hold it up as a fundamental problem with C++.  They don't work in the class of problems that require this type of control, but those classes of problems exist.  EA rewrote the STL because their requirements just weren't being met.  They claim most of their work fits directly into the standard algorithms, et al, which is a testament to the power of C++ as a language, and to the success of the philosophy of implementing as much as possible as a library.


So before you start demonizing C++ for having low level constructs, take some time to understand the philosophy of C++.  C++ isn't perfect, but it isn't the demon creature that Java people seem to imagine it to be.

"I just wonder could we keep these conversations civil without name calling?"

I thought it was a fair comment in a thread which is based mostly on "C++ is bad because I can do XXXX".

>"Also realize that one of the goals of C++ was to give
> the developer control when he needed it (this is
> something Jimmy Jones doesn't fully understand either)."

FWIW, this is what I'm referring to when I say "C++ never runs out of steam".

You don't even need to be writing a device driver, high things like OpenGL need them too.

Fake Programmer:
"...before you start demonizing C++ for having low level constructs..."

Jimmy Jones:
"I thought it was a fair comment in a thread which is based mostly on 'C++ is bad because I can do XXXX'."

Note: I never criticized C++ for having low-level construsts. And I never said C++ was bad "because I can do XXXX".

Quite the opposite. I said I dislike C++ because of the things it either can't or won't do:

* provide lexical unambiguity

* enforce semantic well-definedness for all constructs

* allow for multi-pass complation (which would eliminate the need for header files and forward declarations)

* semantically import rather than lexically #include

* supply a dirt-simple extension to array semantics (the .length field) that would save everyone a lot of trouble, cost practically nothing, and provide at least some meaningful distinction between pointers and arrays.

"How does one get this?"

Rick Tang: "I guess the performance penalty for checking native type operations is too high."

One instruction to check for overflow is too much of a performance penalty?

"You might use Integer/Long/Floats if you want to be sure."

No, that will not do.  I still will not be sure.  I want the overflow error trapped.

Sincerely,

Gene Wirchenko

>"* supply a dirt-simple extension to array semantics
> (the .length field) that would save everyone a lot
> of trouble, cost practically nothing, and provide at
> least some meaningful distinction between pointers
> and arrays.

Sorry to sound uncivil... but you seem to have missed one of the major themes of this thread.

In C++ you can define an object which behaves exactly like an array but carries the length around with it.

If you want to, you can also add range-checking, etc. to operator[] and you'll get the same safety as those other languages.

The difference with C++ is that *you* get to decide the exact behavior and the compromises made, not somebody else who thinks he knows what's best.

eg.

template <class T>
class my_array {
  int len;
  T* the_data;
public:
  int length() const {
    return len;
  }

  T& operator[](int n) {
  if ((n <0 or (n >= len)) {
    throw "an exception";
  }
  return data[n];
  }

  ...etc.
};

my_array<int>foo(100);
for (int i=0; i<foo.length(); ++i) {
  foo[i] = 2;
}

// Will throw an exception
foo[100] = 4;

It sounds ridiculous doesn't it, but that's the only probable reason. It shouldn't be bad if the hardware supports it, but as you know Java is supposed to be run on toasters...

Interestingly I just learn that C# gives you the option -- in checked context overflow is caught, and in unchecked context it is not.

http://msdn.microsoft.com/en-us/library/74b4xzyw.aspx

Benji, what you dislike about C++ is that it isn't Java.  And let's be honest about it, C++ _isn't_ Java.

And that's ok.

Just keep in mind that most of the items are more preferences than they are valid gripes about anything.