Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've been programming for a few years and I began in Java, and in my time I've found many different sources claiming Java to be an inferior language in some way or another. I'm well aware that each language has it's strengths and weaknesses, but a lot of things I've read about Java seem to be dated.

The most often cited reason for Java being inferior is that it is much slower than other natively compiled languages, like C++ for example. Many people criticize the game designer Notch (who developed Minecraft) for using Java because of its apparent lack in the performance department. I know Java was much slower back in the day, but there have been many improvements since, especially JIT compilation.

I would like to get some objective opinions of Java as a language today. So my question has 4 parts.

  1. Performance.

    a. How does Java's speed today compare to C++?

    b. Would it be possible to create a modern AAA title using Java?

    c. In what areas specifically is Java slower than C++, if at all? (i.e. Number-crunching, graphics, or just all around)

  2. Is Java now considered a compiled language or interpreted language?

  3. What are some major shortcomings of Java that have been addressed since the early days?

  4. What are some major shortcomings of Java that have yet to be addressed?

Edit:

Just for clarification purposes I'm not making this Java vs C++, obviously on average c++ will be a little faster than Java. I simply need something to compare Java to in terms of maturity as a language at this point in time. Since c++ has been around forever I thought I would be a good point of comparison.

share|improve this question

closed as primarily opinion-based by MichaelT, gnat, Jimmy Hoffa, GlenH7, Dynamic Jul 19 '13 at 21:14

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

8  
! –  cwallenpoole Aug 17 '11 at 0:48
4  
I like the fact that something 10 years old is no longer modern. –  cwallenpoole Aug 17 '11 at 0:52
4  
Java looks a lot different when you view it as a framework / platform instead of just a language. Maybe the problem is that the name is essentially "Java" for both. –  Joe Internet Aug 17 '11 at 2:29
1  
Just as a point of contrast - Minecraft recently hit 3 million sales. I don't think that Java's alleged shortcomings have hurt the game enough to affect sales very much. –  Michael K Aug 17 '11 at 3:47
3  
Absolutely any language is inferior "in one way or another". By definition. –  SK-logic Aug 17 '11 at 7:15

11 Answers 11

up vote 58 down vote accepted

a. How does Java's speed today compare to C++?

Difficult to measure. It's worth noting that a major part of the speed of an implementation, it's memory allocator, are very different algorithms in Java and C++. The non-deterministic nature of the collector makes it extremely difficult to obtain meaningful performance data in comparison to the deterministic memory management of C++, because you can never be certain what state the collector is in. This means that it's very hard to write a benchmark that might meaningfully compare them. Some memory allocation patterns run much faster with a GC, some run much faster with a native allocator.

What I would say, however, is that the Java GC has to run fast in every situation. A native allocator, however, can be swapped out for one that's more appropriate. I recently fielded a question on SO about why a C# Dictionary could execute in (0.45 ms on my machine) compared to an equivalent std::unordered_map which executed on (10ms on my machine). However, by simply swapping out the allocator and hasher for more appropriate ones, I cut that execution time to 0.34ms on my machine- a thirtieth of the original run-time. You could never, ever hope to perform that kind of custom optimization with Java. An excellent example of where this can make a real difference is threading. Native thread libraries like TBB provide thread-caching allocators which are massively faster than traditional allocators when dealing with many allocations on many threads.

Now, many people will talk about JIT improvements and how the JIT has more information. Sure, that's true. But it's still not even remotely close to what a C++ compiler can pull- because the compiler has, comparatively, infinite time and space in which to run, from the perspective of the run-time of the final program. Every cycle and every byte that the JIT spends thinking about how best to optimize your program is a cycle that your program isn't spending executing and can't use for it's own memory needs.

In addition, there will always be times where compiler and JIT optimizations cannot prove certain optimizations- especially in the case of things like escape analysis. In C++, then as the value is on the stack anyway, the compiler doesn't need to perform it. In addition, there are simple things, like contiguous memory. If you allocate an array in C++, then you allocate a single, contiguous array. If you allocate an array in Java, then it's not contiguous at all, because the array is only filled with pointers which could point anywhere. This is not only a memory and time overhead for the double indirections, but cache overheads as well. This kind of thing is where the language semantics of Java simply enforce that it must be slower than equivalent C++ code.

Ultimately, my personal experience is that Java could be about half the speed of C++, on average. However, there's realistically no way to back up any performance statements without an extremely comprehensive benchmark suite, because of the fundamentally different algorithms involved.

b. Would it be possible to create a modern AAA title using Java?

I assume that you mean "game", here, and not a chance. Firstly, you'd have to write everything from scratch yourself as nearly all the existing libraries and infrastructure target C++. Whilst not making it impossible per se, it could certainly contribute solidly towards unfeasible. Secondly, even the C++ engines can hardly fit in the tiny memory constraints of existing consoles- if JVMs even exist for those consoles- and PC gamers expect a little more for their memory. Creating performant AAA games is hard enough in C++, I don't see how it could be achieved in Java. Nobody has ever written an AAA game with significant time spent in a non-compiled language. More than that, it would simply be extremely error-prone. Deterministic destruction is essential when dealing with, for example, GPU resources- and in Java, you'd basically have to malloc() and free() them.

c. In what areas specifically is Java slower than C++, if at all? (i.e. Number-crunching, graphics, or just all around)

I'd definitely go for all-around. The enforced-reference nature of all Java objects mean that Java has far more indirection and references in it than C++ does- an example I gave earlier with arrays, but also applies to all member objects, for example. Where a C++ compiler can look up a member variable in constant time, a Java run-time has to follow another pointer. The more accesses you do, the slower this is gonna get, and there's nothing the JIT can do about it.

Where C++ can free and re-use a piece of memory almost instantly, in Java you have to wait for the collection, and I hope that piece didn't go out of cache, and inherently requiring more memory means lower cache and paging performance. Then look at the semantics for things like boxing and unboxing. In Java, if you want to reference an int, you have to dynamically allocate it. That's an inherent waste compared to the C++ semantics.

Then you have the generics problem. In Java, you can only operate on generic objects through run-time inheritance. In C++, templates have literally zero overhead- something Java can't match. This means that all generic code in Java is inherently slower than a generic equivalent in C++.

And then you come to Undefined Behaviour. Everyone hates it when their program exhibits UB, and everyone wishes that it didn't exist. However, UB fundamentally enables optimizations that can never exist in Java. Take a look at this post describing optimizations based on UB. Not defining behaviour means that implementations can do more optimizations and reduce the code required to check for conditions that would be undefined in C++ but defined in Java.

Fundamentally, the semantics of Java dictate that it is a slower language than C++.

Is Java now considered a compiled language or interpreted language?

It doesn't really fit into either of those groups. I'd say that managed is really a separate category on it's own, although I'd say it's definitely more like an interpreted language than a compiled language. More importantly, there pretty much only are two major managed systems, the JVM and the CLR, and when you say "managed" it's sufficiently explicit.

What are some major shortcomings of Java that have been addressed since the early days?

Automatic boxing and unboxing is the only thing I know of. The generics solve some issues, but far from many.

What are some major shortcomings of Java that have yet to be addressed?

Their generics are very, very weak. C#'s generics are considerably stronger- although of course, neither is quite templates. Deterministic destruction is another major lack. Any form of lambda/closure is also a major problem- you can forget a functional API in Java. And, of course, there's always the issue of performance, for those areas that need them.

share|improve this answer
9  
You seem to have some misunderstandings about how modern JITs work. Otherwise good information. –  Sean McMillan Aug 17 '11 at 16:05
6  
"More importantly, there pretty much only are two major managed systems, the JVM and the CLR" - um, Python? Ruby? Smalltalk? LISP? All of them use garbage collectors, lack pointer arithmetic and AFAIK have at least one implementation based on bytecode. –  Michael Borgwardt Aug 17 '11 at 20:16
3  
@Michael: Last time I checked, at least Python and Ruby fall pretty heavily into the "interpreted" camp. Their most common implementations neither pre-compile to bytecode in a separate phase nor include JITs. Not used Smalltalk or LISP but I'm not sure about putting them into the "major" camp- and I've never heard of a Smalltalk or LISP JIT either. –  DeadMG Aug 17 '11 at 20:49
16  
+1 nice answer. finally someone who understands why Java will always be slower than C++. –  da code monkey Aug 19 '11 at 5:41
2  
Do any of these points exibit any real world performance issues (accexdotal or benchmarked)? Is it noticable by most users? Saying that language X is 0.25% faster than language Y doesn't mean language Y is slow. With video games, are you talking strickly consoles or does that include PC games? –  TheLQ Aug 21 '11 at 15:20

I'll start with the proviso that it's nearly impossible for anybody to give a truly neutral opinion about programming languages. If you know two languages well enough to comment on them meaningfully at all, it's nearly inevitable that you'll prefer one over the other. As fair warning, I prefer C++ over Java, which undoubtedly influences my comments to at least some degree.

1a. Speed: the speed you get from either C++ or Java will generally depend less on the language or its implementation than the skill of the programmer(s) using it. Ultimately, C++ probably can win for speed more often than not, but the differences in the code you write are what really matter.
1b. Yes, probably. At the same time, C++ is already well established, and I doubt most game studios see enough advantage to bother switching to Java.
1c. A thorough answer to this could probably fill a large volume. C++ will generally do better with more limited resources. Java benefits more from (for example) having a lot of "spare" memory available.
2. Slow execution and slow garbage collection would probably be the two most obvious. The early windowing library (AWT) was quite clumsy -- Swing was a major improvement.
3. Verbosity. Lack of operator overloading. Use of garbage collection. Lack of multiple inheritance. Java Generics are extremely limited compared to C++ templates.

I should add that some (all?) of those disadvantages (especially use of garbage collection, but the others as well) are seen by many as advantages of Java. The only possible exception would be its verbosity. The verbosity situation is slowly improving a little, but you certainly don't see Java winning code golf contests very often, and in ordinary code it tends to use quite a lot of code as well. I suspect there are at least a few who see it as more readable and understandable, so it can probably be seen as an advantage as well.

share|improve this answer
11  
Java generics aren't even comparable to C++ templates. Java templates are syntactic sugar to aid in compile-time type checking. C++ templates are a Turing-complete code generation system. –  kevin cline Aug 17 '11 at 1:33
10  
+1 for verbosity. Its up there with COBOL for long winded meaningless syntax. With all the "try" "catch" and with all ht e ExtrementlyLongClassName extremelyLongObjectName = new ExteremlyLongClassName() type code it can be quite a challenge to work out what a piece of code is actually trying to do. –  James Anderson Aug 17 '11 at 1:56
6  
@Martijn Verburg - please don't hijack other people's answers in this way. Your edits were far to extensive. Please post your own answer. –  ChrisF Aug 17 '11 at 11:35
2  
+1 For the operator overloading, something many people see as minor disadvantage, but for me a major one. And of course templates, but nearly everybody regards them as major. –  Christian Rau Aug 19 '11 at 13:55
2  
C++ templates were not intended to be Turing-complete -- that happened by accident, as a consequence of its design. Nevertheless, it is occasionally useful: look up C++ template metaprogramming. –  comingstorm Apr 25 '12 at 16:11
  1. Regarding performance;
    1. In pure code execution speed, Java is about equal to straightforward C++. But Java tends to use a lot more memory - partially because it's GC-based, partially because its design places more focus on simplicity and safety than on efficiency. Due to cache issues, more memory translates to lower speed. A lot lower when compared to highly-tuned C++.
    2. If you assume that an AAA title must work at the edge of what is possible using current hardware, no. At least not on the client side. I'd be willing to bet that some AAA titles already use Java for parts of the backend infrastructure.
    3. Anything where you work with large datasets and C++ can be optimized to access them in a cache-friendly manner.
  2. It's compiled to bytecode and JIT-compiled at runtime. Compiled vs. Interpreted is a false, outdated dichotomy.
  3. & 4. There's too many things to list them all, and there will be disagreement on most of them.
share|improve this answer
3  
Saying Java uses a lot of memory because it's GC-based is almost like saying an 18-wheeler uses a lot of gas because it has 18 wheels. I know next to nothing about Java, but I suspect the problem is runtime bloat and too many things being cached, less likely semantic garbage, and not at all a flaw in the garbage collection approach itself. –  Joey Adams Aug 17 '11 at 18:08
2  
At the most obvious level, garbage collection means that there is a delay between an object going out of use and the garbage collector actually reclaiming its space. In a manually-managed environment the space can be release immediately when the object goes out of use. The delay means the garbage collected environment uses more memory. And typically it performs better the more memory it can use since that reduces GC overhead. –  Michael Borgwardt Aug 17 '11 at 20:07
1  
@MichaelBorgwardt You may want to mention that the speed need time because most JVM's need to start from scratch every time. Profiling information from previous runs are not reused. –  user1249 Oct 29 '11 at 11:32

Firstly some context, my C++ is very rusty, so most of my experiences with Java relate to my more recent experience with C#.

1. Speed

a. How does Java's speed today compare to C++?

I think this is best answered by the SO question Why did java have the reputation of being slow? but I also think this whole question is coloured by Jeff Atwood's blog post, Gorilla vs. Shark. Thanks to Péter & Christopher.

b. Would it be possible to create a modern AAA title using Java?

That depends on the developers priorities and the skills of the developers. Plus it's not an either/or situation, different parts of the title may require different different things of the language they are implemented in, leading to a heterogeneous language environment.

I've seen a number of games recently mentioning that they are loading a Python environment while they are loading and I suspect that horses for courses is a strong motivation if you want to get your title out in time for the holiday season (for example).

c. In what areas specifically is Java slower than C++, if at all? (i.e. Number-crunching, graphics, or just all around)

You can write poorly performing code in any language, but some languages make it easier to make good choices, while others are more likely to let yourself get hoist by your own petard. Java falls into the former category, C++ definitely falls into the latter.

With great power comes great responsibility as they say (not to mention the ability to completely screw up your heap *8').

2. Is Java now considered a compiled language or interpreted language?

I can't say what most people consider it to be, but many people know the difference between compiles and interpreted languages, and hadn't been living in a cave for the last 20 years, would also know that the JIT (Just-in-Time) compiler is an important part of the Java ecosystem, so is is probably more likely to be considered compiled these days.

3. What are some major shortcomings of Java that have been addressed since the early days?

I'm a fairly recent convert to Java, so I have little context as to how it has evolved. But it is interesting to note that there are books like Java: The Good Parts which seek to steer people in the direction of the parts of the language which should be preferred these days and steer people away from the areas which are, or should be, deprecated.

4. What are some major shortcomings of Java that have yet to be addressed?

To my mind, one problem with Java has been the slow adoption of new features.

Having come to Java from C#, and looking through the Wikipedia comparison page, these are the things that stand out for me:

Things I miss in Java, compared to C#

  • Properties, especially automatic properties. They make building and maintaining interfaces much easier.
  • Closures/lambdas. I was really disappointed when I heard that Java support was being pushed back again.
  • Type inference (var) may seem like syntactic sugar, but when you have complex generic types, it can make code much clearer by removing a lot of worthless duplication.
  • Partial classes really help to keep automatically generated code (say from a GUI builder) separate from programmer written code.
  • Value types, sometimes there is an argument for using a lightweight struct over a full class.
  • Extension methods can make systems complex if over used, but are great for indicating the canonical way of implementing something for a class if it is needed.
  • Unsigned types, sometimes that extra bit can make all the difference. *8')

Things I don't miss in Java, compared to C#

  • Operator overloading is great when it is used correctly, but when used badly can result in hard to find bugs and a disconnect between what an operator should obviously do and what it actually does.
  • Nullable value types always seemed to cause more trouble than they were worth.
  • Access to unsafe code. You have to be so careful with this that I've rarely found it worth the extra effort.

As such, even when comparing apples to apples, Java is considered to have fallen behind.

The other two big problems I see with Java are the egregious start-up delay and the fact that (for some JVMs) you have to micromanage your heap and even permanent generation heap. With C# applications always started immediately and I never once had to even think about heap, since it was allocated out of the system memory pool, not from a pre-allocated pool assigned to the virtual machine.

share|improve this answer
1  
That SO question that you linked, the accepted answer is incredibly, hilariously wrong. –  DeadMG Aug 17 '11 at 14:04
    
No, I meant stackoverflow.com/questions/2163411/… –  DeadMG Aug 17 '11 at 14:30
    
@Mark: Perhaps. Then again, it's probably just as well to drop it completely. I've already had my say in my own answer to the same question, so adding more in comments is unlikely to really add a lot of new knowledge. –  Jerry Coffin Aug 18 '11 at 10:23

I can point you a source that may help answer the first part of your question for you. Programming languages shoot out http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php is a pretty good source to see how fast languages compare to each other. They can even be filtered on different categories to see in which areas languages do better than others in. Java is much faster than it was several years ago.

share|improve this answer
2  
    
Yeah I probably should have linked straight to that page sorry. –  bschaffer13 Aug 17 '11 at 19:47

1) Strictly talking about the UX I get with Java, it feels slow. I can't tell you why really. I have yet to come across a Java based desktop application, that doesn't feel slow and has a faster non-Java alternative. That being said, Java can be very fast in pure computational speed and the internet is full of benchmarks to prove that. However the boot time of Java apps and the responsiveness of their GUIs has yet to improve IMHO. Maybe you could do it ;)
In the end, speed is not so much of an issue. Not only is hardware getting faster and faster, it's also that most people still care surprisingly little for it as long as the software does, what it should do and the ratio of time spent interacting vs. time spent waiting is reasonable.

2) This distinction has become so blurry lately, that there's really little value to it.

3+4) There have been quite some changes to Java actually. Some people argue already, that these changes have tainted Java's purely simplistic philosophy by bolting on alien features. It's really hard to say objectively, what a shortcoming is, and what a strength is. To me, Java is unnecessarily verbose, restrictive and poor in features, while other people consider these very traits as a pleasant unambiguity, safety and clarity.
So while it is these things, that personally make me not use Java, I do not think simply adding the things I miss in Java is a good idea. There's a lot of languages I like running on the JVM and bending Java to be closer to them would just defeat Java's purpose.

It's a matter of preference

The thing with Java is, that it is designed to prevent you from shooting yourself in the foot. A noble cause, but with all the restrictions it straps onto you, it is not unlikely, that you trip over one of your safe feet, can't brace yourself with your hands being tied behind your back for your own safety and finally die, because you break your skull. :D
In a way, Java was a response to C++, which gives you enough rope to not only hang yourself, but also the rest of the world. It's all that rope, which makes it so attractive for cowboys. All that freedom and all that power.

So simply put, this is really just a matter of preference.

But, a point is, with C++ as an alternative to Java, you're free to choose your own restrictions. Or to really go nuts with all the control you have, risking to utterly confuse your peers:

I saw `cout' being shifted "Hello world" times to the left and stopped right there.
— Steve Gonedes

Java chose not to offer operator overloading, for that very reason. Of course this prevents people from obfuscating their code by multiplying function pointers with lists. But at the same time it prevents other people to perform geometric/algebraic calculation with the usual operators. (v1 * v2 / scale) + (v3 * m) really is a lot clearer than v1.multiply(v2).divide(scale).add(v3.multiply(m)). I see why this can put off people who deal with 3d graphics and calculation.

Java chose to impose garbage collection, whereas in C++ you can choose. You can really dig all the way down and get close to the hardware. You can pack data densely into structs. You can perform dark magic, such as the fast inverse square root. You can perform some of the most convoluted and cryptic metaprogramming on earth using templates. But it also means, you can get lost and spend hours debugging all the mess you created or looking over absolutely unhelpful compiler errors.
But if you have the discipline to only use the parts of the language you really master, you can write C++ code just as safely as Java code, but you have the option of gradually pushing forward.

So while nothing technically prevents you from writing cutting edge software with Java, you will find that many developers really passionate about writing great software and having fun and evolving while doing so move on beyond what Java has to offer as a language.

But the world doesn't consist only of people set out do create the next big thing or only of people who will restrict the usage of the power given to them only as far as they control it. IMHO Java is the perfect match for people who want to produce stable results in a comfortable manner.

share|improve this answer
    
+1 For the fact that in C++ nothing prevents you from writing Java-like code, and likewise nothing prevents you from doing more than that. It's the programmer who makes a language unsafe or hard. –  Christian Rau Aug 19 '11 at 14:12

Garbage collection is the big thing. Every so often, GC will lock out everything else for several hundred milliseconds (depending on the size of the heap), and do a major collection. This is fine if you do not have any timing constraints, but if being late means failure, this is a show stopper. You can spend the money for real time Java, and a real time OS, but you can simply use GCC and standard Linux and you will not have these problems.

Without the unpredictable random pauses, Java is probably fast enough for most things these days. And if you spend months tweaking your GC settings and such, maybe, just maybe, you can get it to work long enough for teh customer to cut you a check.

share|improve this answer
    
Most modern garbage collectors do not stop the world. –  user1249 Nov 10 '11 at 21:44

I sort of reacted to this question because it will give misleading and largely irrelevant answers:

b. Would it be possible to create a modern AAA title using Java?

Everyone can agree that AAA titles would be difficult to produce using Java and that there are no actual examples that I'm aware of. However given the nature of AAA that would assume a lot of things (since it really is a confusing term coming from marketing) so it's better to ask the following instead:

Is it possible to create a modern title with reasonable success using Java?

The answer is "Yes, you can.". However the actual success part of the equation is more based on your persistence and luck (or adherence to zeitgeist) but that is outside the scope this site.

share|improve this answer

3) Shortcomings that were fixed.

A few years ago there was a lot of anger at Java. Most Java programmers are web/server programmers and they were going mad with the verbosity of Java. So some languages like Ruby became popular and Java started to wane. However, with the new annotations and frameworks like hibernate and Spring, people have stopped complaining and gone back to Java.

4) Current shortcomings

The hardware is all going multicore. Although Java can do multithread, it's based on C which is a sequential language and the functionality for making it multithreaded is not elegant, to say the least. By the way, that's not just a critcism of Java, but pretty much of all languages. Some completely different way of thinking about code is needed. Maybe functional programming is the way of the future.

share|improve this answer
1  
Going mad? Hardly think so. And apparently you have not had a look at the concurrent stuff in Java 6. –  user1249 Nov 10 '11 at 21:50

A certian area of speed comes down to compiler vs compiler. Not language vs language. There can be advantages to JIT compilation since it can optimize for the specs of the machine it's running on. Compare JIT compiled C++ vs Java for a more "apples to apples" compiler comparison.

But there are some things where the Java language itself limits it's own performance.

  1. allocation on the stack. Java can't do this. For small fixed size classes in a non-recursive solution this is often ideal. You can also avoid heap fragmentation.

  2. non virtual functions. Java can't do this. All method calls receive a permanent hit even when they are not planned to be overridden.

Probably some other stuff but that's all I can think off the top of my head.

share|improve this answer
2  
Modern JIT compilers can optimize both these cases. Java (as of 6) has stack allocation: en.wikipedia.org/wiki/Escape_analysis . As for non-virtual functions, the JIT compiler will resolve virtual method calls that only go to one destination (and sometimes can even inline it) into non-virtual calls. –  Steven Schlansker Aug 17 '11 at 1:22
1  
#2 is bogus: any decent JIT marks functions as virtual or non virtual based on whether they are currently being overridden. –  sparkleshy Aug 17 '11 at 3:05

1) irrelevant, and argumentative to boot.
Not only can major pieces of software be created in Java, such systems are delivered every day and run most major companies in the world by now.
2) ditto.
Read the JVM spec and you know. Java was never an interpreted language.
3) ditto.
Read the 15 years of release notes. Impossible for us to figure out what you consider "major flaws" to be addressed.
4) ditto.
The major flaw that has to be addressed is the JCP which is prone to meddle with the core language and libraries for no other apparent reason than to get somoene's name on a JSR so they can write a book with an authorative blurb that "they were the leader of JSR-666". Hopefully Oracle's restructuring of the JCP will take care of that.
You seem to just want to stir up a language war here, and get your prejudice against Java confirmed by others because you can't find any real justification for it yourself.

share|improve this answer
    
ah, I see people are already starting the wars by downvoting anyone not slagging Java. Well done, people! –  jwenting Aug 17 '11 at 10:49
9  
I think the reason for the downvotes is more the fact that your answer isn't really one. –  blubb Aug 17 '11 at 10:55
6  
This answer is just trolling. The OP had a good, well thought out, non-ranty question. Then you come in with "get your prejudice against Java confirmed by others because you can't find any real justification for it yourself". Yea, -1. Oh and no, I don't hate Java, its my current favorite language for a lot of things –  TheLQ Aug 17 '11 at 11:54
4  
The OP wrote a pretty well put together question and received well-phrased answers. There is really no need to accuse him of stirring up anything. –  Anna Lear Aug 17 '11 at 18:25
    
ah, I see people already starting the wars by taking serious questions (and answers) for rants and feeling themselves attacked personally. Too bad I cannot downvote yet. –  Christian Rau Aug 19 '11 at 14:20

Not the answer you're looking for? Browse other questions tagged or ask your own question.