Kirk Pepperdine, in "Why are we still dealing with C++ vs Java?," offers a quick rebuttal to those who compare the two languages. A few choice quotes:

Are there a lot of substandard developers in the world of Java? The obvious answer is, of course there are. In fact, a large percentage ( ~half???) of all Java developers are below average. But the exact same thing can be said about C++ developers. The question is; is the average level of competency higher for C++ developers then it is for Java developers? This is a question for which I have no data on which to base a judgment though my feeling is there isn’t enough of a difference to make a big deal about it. So what if C++ developers can use pointers better than Java developers can. Java developers can deliver functionality at a rate 2.5 times faster than those working in C++.

In my performance tuning course there are a number of examples where the application being tuned has an identical performance profile no matter the language of implementation. Bottom line, architecture is often a more the dominant factor in application performance. In these instance speed to market would seem to be a much more important factor in choice of languages.

What are your feelings? Some people still think C++ is "faster than" Java - despite a number of benchmarks showing that it's not, and other articles that stress Java's advantages in delivery quality (fewer bugs, shorter time to market) over many other languages. Alternately, of course, some languages and frameworks are now making the same claims as to their advantages over Java (notably, Ruby on Rails), so we're likely to see similar discussions with different players for years to come.

Are there a lot of substandard developers in the world of Java? The obvious answer is, of course there are. In fact, a large percentage ( ~half???) of all Java developers are below average.

I think thats stating the obvious assuming a normal bell curve distribution of developer capabilities :). The question is whether the developer capabilities are substantially below what is desired. My belief is that both Java and C++ are likely to suffer from the fact that the number of developers who can substantially leverage OO is likely to be fewer than desired. However I have seen Java developers get up the curve with all other language nuances faster than C++ developers (ie. as they progress from a trainee developer to a competent developer stage).

In my performance tuning course there are a number of examples where the application being tuned has an identical performance profile no matter the language of implementation.

For any application as a whole I believe that a very large part of the application (95%+) can be developed in Java or C++ with very similar performance profiles. However I have found that there are small portions of application (typically those that deal with complex datastructures or very complex algorithms) where I've wished I was working with C++. Dhananjay

My belief is that both Java and C++ are likely to suffer from the fact that the number of developers who can substantially leverage OO is likely to be fewer than desired.

I agree with this completely. I feel, however, that Java pushes developers to OO more than C++ because lacks a lot of the cool tricks that C++ has and the only way to really write effective code in Java is to use good OO. I actually credit Java for helping me to 'get' OO. Java interfaces really drive it home when you really think about what it going on. The other great advantage of Java in my opinion is that it's much easier to keep the entire syntax in your brain at any given time.

For any application as a whole I believe that a very large part of the application (95%+) can be developed in Java or C++ with very similar performance profiles. However I have found that there are small portions of application (typically those that deal with complex datastructures or very complex algorithms) where I've wished I was working with C++.

Can you explain why? For purely a performance gain or some other reason (pointers, etc)? I find myself wishing more that I was working in a higher level scripting language when working with complex data structures / algorithms. My reasoning is that Java is too verbose in certain situations compared to the brevity a scripting language like Groovy and Ruby can provide. Java has a lot of language overhead that tends to reduce the clarity of the actual business logic being modeled: Casting, anonymous inner classes, declarations, etc. Java BigDecimal amount = myBo.getAmount(); if (amount.compareTo(new BigDecimal(MAX_AMOUNT), 2) > 0) { amount = amount.multiply(new BigDecimal(DISCOUNT), 2); myBo.setAmount(amount); } VS. pseudo-script curr_amt = my_bo.amount my_bo.amount = DISCOUNT * curr_amt if (curr_amt > MAX_AMOUNT) Obviously, the Java code could have been written in one line but that isn't the point. The point is that with scripting you can reduce the code down to only what is needed to follow business rules. If needed, you can override operators or create a custom domain specific language to improve readability and maintenance. This is a simplistic example but anybody who has coded their share of Java will agree that it isn't the most compact language. For straight-forward processes that isn't that much of a limitation but for complex rules or algorithms I think Java's verbosity increases the maintenance overhead by reducing clarity. Would grabbing C++ have similar benefits? _______________ George Coller DevilElephant

I think numerics in general is probably the best reason to look at C++.

For straight-forward processes that isn't that much of a limitation but for complex rules or algorithms I think Java's verbosity increases the maintenance overhead by reducing clarity.

A lot of people argue that Java's verbosity improves clarity. I know that when I go back and look at old Python code, it takes a little while to figure out what types are being dealt with at any given point. It's not very self-documenting like good Java code, IMO. Also, you've set up a straw-man with your example. BigDecimal is one of the worst APIs in the JDK. It's clearly not representative of most Java libraries. It's also a poor choice for working with money. Good Java code would use a Money type. I think languages like Python are good for prototyping and for logic that changes often. But for more structural code, it seems less appealing.

A lot of people argue that Java's verbosity improves clarity.

Thank goodness for those casts, semicolons, generics, ... ;-)

I know that when I go back and look at old Python code, it takes a little while to figure out what types are being dealt with at any given point. It's not very self-documenting like good Java code, IMO.

Do you think that is inherit in Python or was the code written more obtusely than needed? I know many criticize Perl for being obtuse with its tightly compacted syntax. But isn't a language like Ruby touted as having a clean syntax without a lot of junk to add to the line noise? To me a clean script is easy to read and closer to English than Java. I'm not talking about replacing Java - just a critique of when it kind of breaks down.

Also, you've set up a straw-man with your example. BigDecimal is one of the worst APIs in the JDK. It's clearly not representative of most Java libraries. It's also a poor choice for working with money. Good Java code would use a Money type.

Agreed that my sample stinks - but even with Money I don't think the code would change much. You still have to do silly things like use .add() .multiply() .compareTo(), and convert from primitive to Object right? That was my point. All that stuff is overhead to make Java work - it takes away from the clarity of what is being programmed.

I think languages like Python are good for prototyping and for logic that changes often. But for more structural code, it seems less appealing.

I'm wondering if this is only true for people like you and me who do the vast majority of their work in Java (I'm assuming for you since you are posting on this site). I can crank out code in Java like nobody's business compared to Ruby but that doesn't mean that Ruby may not be a better language in certain situations. I'm just guilty of knowing how to use my Java hammer better than my Ruby (or other language) hammer. I'm wonder if we'd feel different after spending a few hundred hours of development time in a scripting language. Maybe we'd see Java in a whole different light? George Coller DevilElephant

A lot of people argue that Java's verbosity improves clarity.

Thank goodness for those casts, semicolons, generics, ... ;-)

I'm not arguing that ever part of Java improves clarity. But there is a key difference that does...

I know that when I go back and look at old Python code, it takes a little while to figure out what types are being dealt with at any given point. It's not very self-documenting like good Java code, IMO.

Do you think that is inherit in Python or was the code written more obtusely than needed?

I'm probably a pretty crappy Python coder at this point but I'm talking about something inherent here. There are no type declarations in Python. On one hand this is a great stregnth. However, for code maintenance, it seems problematic. If I need to modify a method, it's can be difficult to know what types are being passed in and what operations I can safely use.

I know many criticize Perl for being obtuse with its tightly compacted syntax. But isn't a language like Ruby touted as having a clean syntax without a lot of junk to add to the line noise? To me a clean script is easy to read and closer to English than Java.

I had a cat that was pretty good Perl programmer. He liked it because he couldn't type very fast. I agree with you to a point. Python code reads like psuedo code and is a lot faster to write. For tools, 'throw away' business logic, and testing, I highly prefer it to Java.

I'm not talking about replacing Java - just a critique of when it kind of breaks down.

I got that. We are pretty much on the same page here. I would actually go a step further to say Java vs. Python or Java vs. Ruby is a false dichotomy. The languages are really quite complimentary. More on this...

Also, you've set up a straw-man with your example. BigDecimal is one of the worst APIs in the JDK. It's clearly not representative of most Java libraries. It's also a poor choice for working with money. Good Java code would use a Money type.

Agreed that my sample stinks - but even with Money I don't think the code would change much. You still have to do silly things like use .add() .multiply() .compareTo(), and convert from primitive to Object right?

Well, it's really nether here nor there because I got your point but: curr_amt = my_bo.amount my_bo.amount = DISCOUNT * curr_amt if (curr_amt > MAX_AMOUNT) Money current = myBo.getAmount(); if (MAX_AMOUNT.compareTo(current > 0) myBo.setAmount(current.multiply(DISCOUNT)); Is the Java version harder to read? Sure. But there are much better examples that highlight where Java's verbosity becomes very cumbersome.

That was my point. All that stuff is overhead to make Java work - it takes away from the clarity of what is being programmed.

I think languages like Python are good for prototyping and for logic that changes often. But for more structural code, it seems less appealing.

I'm wondering if this is only true for people like you and me who do the vast majority of their work in Java (I'm assuming for you since you are posting on this site). I can crank out code in Java like nobody's business compared to Ruby but that doesn't mean that Ruby may not be a better language in certain situations. I'm just guilty of knowing how to use my Java hammer better than my Ruby (or other language) hammer. I'm wonder if we'd feel different after spending a few hundred hours of development time in a scripting language. Maybe we'd see Java in a whole different light?

Yes, I've only recently started using Python after reading and getting involved in agruments about static-typing vs. dynamic-typing and realizing that deep inside, I was favoring what I knew mainly becauase I knew it. Anyway what I found is that Python (Jython) and Java work great together. I love Python for testing and writing small pieces of glue code. However, for things that don't change much (big heavy structural elements), Java's verbosity becomes a benefit. And I also discovered something really cool (IMO). Nether Java nor Python support multiple-dispatch: Java because it's compile-time bound and Python because you can't overload by parameter types (no types!). But when you put them together: viola! double-dispatch on Java method calls from Jython. Actually, I just realized that I need to use Jython in a side project to really improve a piece of functionality.

I should give Jython another look. I attempted to use Groovy on a project a couple of years back but it was still too immature. You don't ever hear anything about Groovy anymore (at least not on ServerSide for quite some time). I do like the idea of JVM-based scripting JRuby, Jython, Groovy in general. Seems like you could get the best of both worlds. I can see resistance to this at the same time from those who may feel using two or more langauges within a project would be a terrible idea. My quick counter-argument would be that I'd kind of include HTML, JSTL, XML, CSS, SQL, HSQL, and all those config files loosely as "langauges" so adding scripting language support shouldn't be shied away from simply for the language-overload argument. Thanks for the posts. ______________ George Coller DevilElephant

I should give Jython another look.

One thing that might look sketchy is that it hasn't been updated for years. I found that a grant was awarded to someone to update Jython so that shouldn't be an issue forever. Personally, I haven't run into much that I missed in Jython (given I'm a total noob, of course.)

George- Another language I've been meaning to look at is Scala. It has a lot of the features of Python and Ruby but has static typing. I think it would be educational to see how much the typing changes the way you use it.

George-

Another language I've been meaning to look at is Scala. It has a lot of the features of Python and Ruby but has static typing. I think it would be educational to see how much the typing changes the way you use it.

Interesting - will Google it. Weirdly enough the scripting language I deal with most is ActionScript (based on ECMAScript) since I do a lot of Flash programming on the side. ActionScript leaves it up to you whether you want to use strong typing or not: var x:Number = 123 x = "ABC" //Error // OR var x = 123 x = "ABC" // Fine So basically, you conform static typing to your coding style. ______________ George Coller DevilElephant

Well, it's really nether here nor there because I got your point but: curr_amt = my_bo.amount my_bo.amount = DISCOUNT * curr_amt if (curr_amt > MAX_AMOUNT) Money current = myBo.getAmount(); if (MAX_AMOUNT.compareTo(current > 0) myBo.setAmount(current.multiply(DISCOUNT)); Is the Java version harder to read? Sure. But there are much better examples that highlight where Java's verbosity becomes very cumbersome.

Interesting. You hit the spot where C++ is superior to both Java and scripting languages: operators. In ruby or python, AFAIK, you can use a natural syntax for big number comparisons but you are limited to base types. In Java you have access to several numeric types as standard classes, and you can extend them to suit your needs, but you are forced to use an unnatural syntax like compare(), add(), multiply() etc. In C++ you can create/modify all the numeric types you like, and you always use a natural syntax like (a < b) or (c * d). The only problem is that you need a skilled programmer to use operator overriding to such an extension (not to simply use it, though). The real limitation that C++ suffered, compared to Java, is the lack of standard libraries that define important primitive types. Each of us has certainly written a BigDecimal or Date or Socket class in C++ that is better than its Java counterpart, given that you can use operators instead of methods, but having a standardized version is a clear advantage.

Well, it's really nether here nor there because I got your point but:

curr_amt = my_bo.amount
my_bo.amount = DISCOUNT * curr_amt if (curr_amt > MAX_AMOUNT)


Money current = myBo.getAmount();
if (MAX_AMOUNT.compareTo(current > 0) myBo.setAmount(current.multiply(DISCOUNT));

Is the Java version harder to read? Sure. But there are much better examples that highlight where Java's verbosity becomes very cumbersome.

Interesting. You hit the spot where C++ is superior to both Java and scripting languages: operators.

In ruby or python, AFAIK, you can use a natural syntax for big number comparisons but you are limited to base types.

That's not true, at least for Python and I suspect for Ruby too. Python allows you to create types and overload operators.

Do you think that is inherit in Python or was the code written more obtusely than needed?

The problem with Python, Ruby and other "loosely" typed languages is not so much the syntax, which is usually fairly easy to digest, even for beginners, but the lack of typing. When you need to make sense of chunks of code spanning over fifty lines, typing is primordial and without it, you will waste a lot of time trying to figure out what objects are being passed around and what methods you can invoke on these objects.

To me a clean script is easy to read and closer to English than Java.

Many have tried to create programming languages that are similar to natural languages, but all these attempts have been disasters. The reason is simple: all natural languages are ambiguous, but the human mind is very good at making up for these ambiguities. Not so for a computer.

I'm wonder if we'd feel different after spending a few hundred hours of development time in a scripting language. Maybe we'd see Java in a whole different light?

You definitely do, and I highly recommend it. Depending on your mindset, you might decide that one of these two languages is vastly superior to the other, but in general, you will simply gain a higher understanding of how both languages work and you'll apply this new knowledge to improve your skills in both. -- Cedric http://testng.org

When you need to make sense of chunks of code spanning over fifty lines, typing is primordial and without it, you will waste a lot of time trying to figure out what objects are being passed around and what methods you can invoke on these objects.

I get the argument for strong typing. I'm sort of on the fence right now whether it really helps or if it is simply a crutch. Maybe it would be better to say I'm in the discovery phase on hard-core use of scripting languages in general. I've heard Dave Thomas (Pragmatic Programmers), who I really respect, talk about how static typing is simply a language crutch that developers lean on because they are used to it but in reality do not really need. This was in a Ruby talk (surprise) but I felt that he had some really valid points about "line noise". It is easy to see how much of the Java language was cut and paste from C without a lot of new analysis on what should be changed for modernity. My guess is that the original designers of Java were more concerned with getting security and garbage collection down than improving syntax design. Take the semi-colon. It simply isn't needed unless you put more than one statement per line, which is considered bad style anyway. Or casting. It seems that a modern compiler should be able to check the type of the variable to which the cast is being applied in order to determine if it is a correct cast or not. Even your 50 line code-chunk example: If a scripting language compacts the line noise down so that those 50 lines become 10-20 then do you still have the same issues regarding type? I guess the argument should be made that any one chunk of code should not exceed X lines anyway so some refactoring could also take care of the issue. BTW: I apologize a bit to everyone for going so far off the original C++ vs Java topic. I just don't really hear the "Java is too slow" argument in my realm of influence anymore. No company I'm working with has C or C++ on their radar. COBOL? yes but not C. To me it seems that Java and C have carved out two large but separate niches in software engineering. Are they still battling? ______________ George Coller DevilElephant

I've heard Dave Thomas (Pragmatic Programmers), who I really respect, talk about how static typing is simply a language crutch that developers lean on because they are used to it but in reality do not really need.

I have a strong suspicion that all the "dynamic fans" out there have never worked on projects that involve more than four people in their dynamic language. Of course, it's a suspicion, so don't ask me to back it up, but in my experience, having strong typing for big projects with more than five developers coming from very different backgrounds and educations is not just a luxury, it's a necessity. The cute hack that takes 20 lines to write in Ruby while it would take 40 in Java becomes a liability when, two months down the line, one of your colleagues ponders your creative use of method_missing on multiple closures receiving three objects of unknown types. Your other points are well taken about the uselessness of the semi-colon, casting (I blogged about that quite a few times) or why C/C++ needs both "." and "->" (even my teacher back in school coudln't come up with a convincing response to that one). -- Cedric http://testng.org

Personally I never want to work without static type-checking. I believe that there are programmers on both sides of the fence, and that preferences from one to another have to do with how their brains function. I also suspect that a lot of programmers who prefer weakly-typed languages and scripting languages are working in environments where they can afford it - very small teams, simple web apps where code-by-convention is effective, and the code might not have significant longevity requirements. (Oops, I made an unspoken assumption there, which is that code-by-convention is only effective for relatively simple applications, or for those well-trodden parts of more complex apps.) I particularly like IDE support like code completion, which is generally much less effective without static typing.

You can have your cake and eat it too. Boo was inspired by Python but is statically typed via type inference. So you still get your code completion, but you don't have to type all those redundant type declarations for locals in methods.

You can have your cake and eat it too. Boo was inspired by Python but is statically typed via type inference. So you still get your code completion, but you don't have to type all those redundant type declarations for locals in methods.

Scala does this too, I believe.

The cute hack that takes 20 lines to write in Ruby while it would take 40 in Java becomes a liability when, two months down the line...

To be fair, my argument on this was that a scripting language would be naturally less verbose without doing anything crazy or "hacky" or overly clever. I don't think it is an exaggeration that you could take an average Java class and reduce the LoC simply by writing it in a modern scripting language using that language's standard coding conventions. I've experienced this with both Groovy and Ruby. If you allow the developer to be too clever then all bets go out the window on either side. I think the gauntlet has been thrown down to find a successful large application that has been written in a scripting language to prove/disprove that static typing is an asset/crutch. Sounds like many of us have only been exposed to small/med scripting projects. If anybody has any links to white papers or other discussions I think that would be interesting. Would the corollary question be "at what size project does it make sense to move from scripting to Java to benefit from all the built-in java sneeze guards"? ______________ George Coller DevilElephant

I think the gauntlet has been thrown down to find a successful large application that has been written in a scripting language to prove/disprove that static typing is an asset/crutch.

That's the thing. There just aren't many such programs (AFAIK) even though lanugages like Python have been around for about a decade. I believe the biggest app you will find in Python is Zope. I will also say that I don't think it's impossible to make a maintainable app in a dynamic typed language. You can add documentation to get around the lack of type information. But, to me, this kind of defeats the point. The work has shifted from writing types in code to writing types in comments and there's nothing ensuring that the comments stay up to date. You can't specify bogus type info in Java.

Sounds like many of us have only been exposed to small/med scripting projects. If anybody has any links to white papers or other discussions I think that would be interesting.

Would the corollary question be "at what size project does it make sense to move from scripting to Java to benefit from all the built-in java sneeze guards

I think the 'sneeze-guard' argument is a waste of time because it misses the point on both ends. The value of dynamic typing is not the terseness of the code. The value of static-typing is not to keep people from making mistakes (it doesn't, not really). benefits (as I see it) static-typing: self-documents, allows for effective dependency searching, allows for optimization, allows for machine refactoring dynamic-typing: highly-flexible, makes reuse much easier, easier to read, higher logic-to-structural code ratio Some the other features of Ruby and Python have could be added to Java and have nothing to do with dynamic vs. static typing: Function pointers, overloaded operators. If a developer's main concern is how fast he or she can bang out code, I would be concerned that person is doing too much typing and not enough thinking. The main reason (from what I see) that Java code is lengthy is because a lot of it is unnecessary or unnecessarily complicated.

I think the gauntlet has been thrown down to find a successful large application that has been written in a scripting language to prove/disprove that static typing is an asset/crutch.

That's the thing. There just aren't many such programs (AFAIK) even though lanugages like Python have been around for about a decade. I believe the biggest app you will find in Python is Zope.

I will also say that I don't think it's impossible to make a maintainable app in a dynamic typed language. You can add documentation to get around the lack of type information. But, to me, this kind of defeats the point. The work has shifted from writing types in code to writing types in comments and there's nothing ensuring that the comments stay up to date. You can't specify bogus type info in Java.

Sounds like many of us have only been exposed to small/med scripting projects. If anybody has any links to white papers or other discussions I think that would be interesting.

Would the corollary question be "at what size project does it make sense to move from scripting to Java to benefit from all the built-in java sneeze guards

I think the 'sneeze-guard' argument is a waste of time because it misses the point on both ends. The value of dynamic typing is not the terseness of the code. The value of static-typing is not to keep people from making mistakes (it doesn't, not really).

benefits (as I see it)

static-typing: self-documents, allows for effective dependency searching, allows for optimization, allows for machine refactoring

dynamic-typing: highly-flexible, makes reuse much easier, easier to read, higher logic-to-structural code ratio

Some the other features of Ruby and Python have could be added to Java and have nothing to do with dynamic vs. static typing: Function pointers, overloaded operators.

If a developer's main concern is how fast he or she can bang out code, I would be concerned that person is doing too much typing and not enough thinking. The main reason (from what I see) that Java code is lengthy is because a lot of it is unnecessary or unnecessarily complicated.

You don't have to have manifest typing to have static typing. Manifest typing (Java's model--declare all variables) has invasive, but descriptive, syntax. Inferred typing (i.e. OCaml--compiler infers the type) to me makes a whole lot of sense. I do think that the implementations of autoboxing and generics show some of the limitiations that can occur when you have to fix a broken typing model after it's been in the wild for a few years.

I do think that the implementations of autoboxing and generics show some of the limitiations that can occur when you have to fix a broken typing model after it's been in the wild for a few years.

What's broken about it? Maybe you don't realize it, but you are using that exact typing system in Ruby, except that you never need to declare these types. I am a big fan of type inference and I wish we had it in Java, but you are confusing two very different issues here. Java: too many types Ruby: not enough -- Cedric

To be fair, my argument on this was that a scripting language would be naturally less verbose without doing anything crazy or "hacky" or overly clever.

Fair enough, George. You can definitely use loosely typed languages in a readable way and still get a very decent reduction in line count compared to Java. I have experienced this reduction fairly consistently on all the Ruby code I have written.

I think the gauntlet has been thrown down to find a successful large application that has been written in a scripting language to prove/disprove that static typing is an asset/crutch. Sounds like many of us have only been exposed to small/med scripting projects. If anybody has any links to white papers or other discussions I think that would be interesting.

Absolutely. I still stand by my claim that for big projects (> 50,000 lines of code, > 5 people), the absence of types is an absolute dealbreaker. -- Cedric http://testng.org

I think the gauntlet has been thrown down to find a successful large application that has been written in a scripting language to prove/disprove that static typing is an asset/crutch. Sounds like many of us have only been exposed to small/med scripting projects. If anybody has any links to white papers or other discussions I think that would be interesting. Would the corollary question be "at what size project does it make sense to move from scripting to Java to benefit from all the built-in java sneeze guards"?

The problem is that too many people think Python/Ruby instead of Smalltalk/Lisp/Erlang for examples of large systems that have been written in dynamic languages.

The problem is that too many people think Python/Ruby instead of Smalltalk/Lisp/Erlang for examples of large systems that have been written in dynamic languages.

Good point. I think I may have been mixing up "scripting languages" with "dynamic languages" in my posts. Certainly, large Lisp projects have been accomplished. In fact what makes a scripting language a scripting language? Dynamic interpretation? I think one of Cedric's main points is that Java lends itself better to junior programmers. From what I know about Lisp (not much) it is extremely flexible but it also has a steep learning curve. The main theme appears to be that dynamic languages require a better quality programming team than a statically-typed language given some reasonably large project. Does it follow that you need to be a better developer to program correctly in Python, Ruby, Lisp, etc than in Java or C++? It feels weird to suggest that moving to a higher level language requires more skill and maintenance. Or is calling a dynamically-typed language higher level not fair? ______________ George Coller DevilElephant

The problem is that too many people think Python/Ruby instead of Smalltalk/Lisp/Erlang for examples of large systems that have been written in dynamic languages.

Indeed. Very large projects have been built and maintained with Smalltalk and LISP (I have no knowledge about Erlang in this area). Although the debate about the relative merits of dynamic and static typing continues (and I remain on the side of static typing), there can be no doubt that Smalltalk and LISP have proved themselves suitable for very large applications. I don't believe that the same can be said for Ruby and Python.

I have a strong suspicion that all the "dynamic fans" out there have never worked on projects that involve more than four people in their dynamic language.

I'll back up your lack of experience with my wealth of experience on this point. My experience is that when teams (using dynamic languages) grow beyond some finite limit that is close to 4 then things can get a bit hairy. The exact limit depends on the background and experience levels of the developers. The problem is that even though the compiler may not enforce typing, the developers must! Parameters and return types must be consistant. So in that regard, explicit typing is a crutch. However it is one that just may well be necessary in large project teams. Now I'd temper this by saying that the large teams of smalltalkers were primarly made up of converted Cobol programmers. Nothing against a cobol programmer but dropping them into smalltalk project is like dropping a fish into the middle of the sahara ;-) - Kirk

I just don't really hear the "Java is too slow" argument in my realm of influence anymore. No company I'm working with has C or C++ on their radar. COBOL? yes but not C. To me it seems that Java and C have carved out two large but separate niches in software engineering. Are they still battling?

George... this is a good question. I run into C++ speed bigots all too often which means it isn't really a dead issue. Unfortunately these people don't seem to get that JITs can deliver native code that can run faster than what one can get from a static compilation. In the world of performance one must always be evaluating that what was true yesterday is still true today. I made a half serious joke about Cedric's 50 lines of code comment but I know that this is code that Cedric is dealing with and not producing himself. I also have seen and respect the effort that Cedric has put in to constantly re-evaluate and learn. It is disappointing to run into people who seem to be unwilling to do this.

When you need to make sense of chunks of code spanning over fifty lines

Well Cedric, this is the problem right here!!! If you are writing methods longer than 5 lines then you are probably doing something wrong. Cheers, Kirk

When you need to make sense of chunks of code spanning over fifty lines

Well Cedric, this is the problem right here!!! If you are writing methods longer than 5 lines then you are probably doing something wrong.

Cheers,
Kirk

I never said these fifty lines were in a single method. And anyway, this "methods must be as short as possible" is nonsense. Sometimes, longer methods are more readable than shorter ones, such as methods using a lot of primitive type locals or code that was generated. -- Cedric http://testng.org

When you need to make sense of chunks of code spanning over fifty lines

Well Cedric, this is the problem right here!!! If you are writing methods longer than 5 lines then you are probably doing something wrong.

Cheers,
Kirk

I never said these fifty lines were in a single method.

And anyway, this "methods must be as short as possible" is nonsense. Sometimes, longer methods are more readable than shorter ones, such as methods using a lot of primitive type locals or code that was generated.

--
Cedric
http://testng.org

I was teasing you a bit by dropping in such a low figure, make it 6! ;-) If you prescribe to the idea that variable names should reflect purpose and not type, then knowing the type shouldn't be that important. However I do take your point that not everyone will (or even can) follow that rule and in those cases the crutch is a necessary evil. But it still is a crutch. -- Kirk

If you prescribe to the idea that variable names should reflect purpose and not type, then knowing the type shouldn't be that important. However I do take your point that not everyone will (or even can) follow that rule and in those cases the crutch is a necessary evil. But it still is a crutch.

And one that's very error-prone since the compiler can't enforce it. It's a bit like people saying "I usually put the type name in comments, so I know what I am dealing with". Well, in that case... why not make it part of the source and rely on the compiler to validate it? By the way, I use this trick myself in Ruby quite a bit: // Map accounts = Hash.new but I can't even begin to tell you how much it irritates me... -- Cedric http://testng.org

And one that's very error-prone since the compiler can't enforce it.

Well, it is at this point that we part. My success using dynamic languages tells me that compiler enforcement isn't so important. In fact, it is a factor in the velocity figure that I quoted earlier. And yes, that velocity is for debugged code. One other point, I've found it especially useful when the language doesn't try to control a developer down to the nth degree. But then, that is just me. -- Kirk

The dynamic guys always use Java as an example of visually-cluttered, boiler-plate ridden crap that they want to avoid. But that has nothing to do with being dynamically typed. With type inference and a nice toplevel(REPL), you can have the vast majority of the benefits of dynamically typed languages with the great IDE support and safety of a statically typed language. Boo looks very close to Python, but has access to all the .NET libraries, macros, even ducktyping (if you want). But I can mouse over an object and get its type since its statically typed, and also get code completion. The best thing that Sun could do is to start working on an agile language like Boo, Nemerle, or Scala to ride on top of the JVM. But Sun seems to be stuck on stupid regarding Java (the language), and Java (the platform).

Alex Stepanov (creator of the STL) slams OOP over here

Yes. STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people. In a sense, I am unfair to AI: I learned a lot of stuff from the MIT AI Lab crowd, they have done some really fundamental work: Bill Gosper's Hakmem is one of the best things for a programmer to read. AI might not have had a serious foundation, but it produced Gosper and Stallman (Emacs), Moses (Macsyma) and Sussman (Scheme, together with Guy Steele). I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras - families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting - saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work.

Personally, I wouldn't say that OOP is useless, but I'm sure it's been oversold as a panacea.

It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms.

Independently of the fact that I disagree with Stepanov about OOP, he should probably brush up on his math. Mathematicians *start* with axioms. An axiom is a statement that you accept as obvious and that doesn't require any proof. And from these axioms, you build proofs. For example, one of Euclid's axioms from which he built his geometry was "For every point P and every point Q not equal to P there exists a unique line that passes through P and Q.". -- Cedric http://testng.org

Independently of the fact that I disagree with Stepanov about OOP, he should probably brush up on his math.

Oh, really?

I was born in Moscow, USSR, on November 16, 1950, and studied Mathematics at the Moscow State University. But I never became a mathematician. I could not really get excited about Tamagawa numbers, Coxeter groups and other things that I was supposed to specialize in. Hardy's hope that his mathematics is never going to be applied is not for me. I need to do something a little bit more real. I was fortunate, however, to see some great mathematicians at work and became totally immune to a pseudo-mathematical rigor that unfortunately is so common in Computer Science

Independently of the fact that I disagree with Stepanov about OOP, he should probably brush up on his math.

Oh, really?

I'm not math major but I have to say I am also not quite sure how you have proofs without axioms. My understanding is that there is no way to have a proof without axioms. Of course, I'm probably missing something but I'm curious to see Stepanov's explanation.

Of course, I'm probably missing something but I'm curious to see Stepanov's explanation.

I think at the end of Alex Stepanov's quote there is an explanation. It is more like iterative process when you discover axioms in math or classes in OOP. And all good OO books advocate such approach, as it is pretty rare that you can come with good classes from scratch. I sort of agree that OOP is overhyped but OOP doesn't automatically assume waterfall approach. There is a theorem, I believe in math logic, that from the false assumption you can prove anything and when Alex Stepanov substituted OOP with waterfall he came to conclusion that OOP technically unsound. I understand Alex Stepanov's position as there are some things that cut across different object hierarchies and doesn't belong to any, STL isn't strictly speaking OO, more like Object Based, could it be that AOP is another example? Maybe not everything in the world is OO after all :) Oleg

I understand Alex Stepanov's position as there are some things that cut across different object hierarchies and doesn't belong to any, STL isn't strictly speaking OO, more like Object Based, could it be that AOP is another example? Maybe not everything in the world is OO after all :)

The way I see it, OO is just one of many ways to describe the 'software universe'. One of the things that I find about functional programming is that a lot of the same concepts and approaches are exactly the same but OO is more rigid and structured (not always a good thing, IMO). OO is also easily described in procedural terms. I do this often when trying to explain OO to COBOL developers. I guess my point is that I don't find these approaches to be incompatible and I think it's foolish to become an ideologue, especially in such a young field as computer science. On the other hand I find Stephanov's arguments unsatisfying because I have used OO with excellent results. His assertions fly in the face of my personal experience. He might as well argue that gravity isn't reliable.

Oh, really?

Yes, really. At least, now we know why he didn't pursue his career as a mathematician... -- Cedric http://testng.org

It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms.

Independently of the fact that I disagree with Stepanov about OOP, he should probably brush up on his math.

Mathematicians *start* with axioms.

No, that's just how the results of mathematics (and science in general) are usually presented. Stepanov is talking about what's sometimes called the "order of discovery" versus the "order of explanation". When the real foundational work is being done, you go back and forth, back and forth between the axioms and the proofs, and in the end we choose axioms for the proofs that they generate. It's only afterwards that the whole effort is recast, for presentation purposes, as a dry working-out of consequences.
Saying "mathematicians start with axioms" is like saying "programmers start with their programming languages" -- it may be true some of the time, but it misses the point that programmers get to create their languages as well.
That said, I completely agree that Stepanov is mistaken about OOP.

Stepanov is talking about what's sometimes called the "order of discovery" versus the "order of explanation". When the real foundational work is being done, you go back and forth, back and forth between the axioms and the proofs, and in the end we choose axioms for the proofs that they generate. It's only afterwards that the whole effort is recast, for presentation purposes, as a dry working-out of consequences.


Saying "mathematicians start with axioms" is like saying "programmers start with their programming languages" -- it may be true some of the time, but it misses the point that programmers get to create their languages as well.


That said, I completely agree that Stepanov is mistaken about OOP.

OK, that makes more sense. Assuming your interpretation is correct (as I believe it to be) then Stepanov is really wrong about OOP. He's suggesting that OOP starts with classes? That makes no sense. "I know you said you wanted a accounting system but the classes I started with ended up producing pong... enjoy!" OOP doesn't 'start with classes'. Anyone who knows anything about OOP knows that and you rarely end up with the classes you first decided upon either.

That makes no sense. "I know you said you wanted a accounting system but the classes I started with ended up producing pong... enjoy!"

+1 whole thread (never got the +1 thing but what the hell) Very entertaining thread, a LOL came out of me due to this last "quote". :) -I

Personally, I wouldn't say that OOP is useless, but I'm sure it's been oversold as a panacea.

I think there are two major problems with OO: 1. A dogmatic approach that requires certain approaches without any evidence that they work or are necessary. 2. A very small percentage of developers really 'get' OO.

Personally, I wouldn't say that OOP is useless, but I'm sure it's been oversold as a panacea.

I think there are two major problems with OO:

1. A dogmatic approach that requires certain approaches without any evidence that they work or are necessary.
2. A very small percentage of developers really 'get' OO.

Personally, I've always felt a little strange about classes = methods + data fields. The CLOS (Dylan/Lisp) way of OO always seemed more natural to me. I guess it's because I always have this nagging feeling in the back of my head about coupling and cohesion issues. And with all the talk about refactoring, I'm probably not alone. I also wish that languages like Java and C# would just have modules for free-standing functions. Putting everything in a class with a static modifier never felt right. But like most people I probably don't really 'get' OO. There was an interesting dicussion over at Lambda about OO a while back. The original article wasn't very good, but I thought the discussion was interesting.

I've always felt a little strange about classes = methods + data fields.

Hmmm. I don't know if that's really how I would describe it. Classes represent concepts (ala Plato.) A Tree class represents the concept of a tree. A tree Object represents an actualy concrete tree. In real terms classes represent functionality: what can you do to a tree? Objects represent state: how tall is the oak, does it have leaves?

The CLOS (Dylan/Lisp) way of OO always seemed more natural to me. I guess it's because I always have this nagging feeling in the back of my head about coupling and cohesion issues. And with all the talk about refactoring, I'm probably not alone.

Can you elaborate on what you mean? In all honesty, I have no idea what you mean (my ignorance being the issue.)

I also wish that languages like Java and C# would just have modules for free-standing functions. Putting everything in a class with a static modifier never felt right.

I can see where you are coming from but it seems like a nit you are picking. I want to clarify by what I mean by 'not getting OO'. If you ask most developers what OO means, they say something along the lines of 'everything's an Object' or 'you use Objects': basically a non-statement. And their code is a bunch of procedural code associated with an Object and maybe inhereting some common functionality from a parent class. Someone who 'gets it' will say something about polymorphism, abstractions, and/or interfaces.

Hmmm. I don't know if that's really how I would describe it. Classes represent concepts (ala Plato.) A Tree class represents the concept of a tree. A tree Object represents an actualy concrete tree. In real terms classes represent functionality: what can you do to a tree? Objects represent state: how tall is the oak, does it have leaves?

See, the problem is that you're giving examples of real-world entities that are a small fraction of what really goes on in programming. But that's really a problem with the teaching methodologies (Circle derived from Shape...)

Can you elaborate on what you mean? In all honesty, I have no idea what you mean (my ignorance being the issue.)

Here is the wikipedia entry for CLOS. Functions and data structures are separated. There's multimethods to do deal with the Visitor pattern, and in the case of Dylan there's a module system for the functions/methods/data structures you want exposed to the public. So in response to your first question, I find it more natural and a cleaner way to reason about OO when your methods, data structures, and accessibility are separated. And of course like any sane language, functions are first class values.

I can see where you are coming from but it seems like a nit you are picking. I want to clarify by what I mean by 'not getting OO'. If you ask most developers what OO means, they say something along the lines of 'everything's an Object' or 'you use Objects': basically a non-statement. And their code is a bunch of procedural code associated with an Object and maybe inhereting some common functionality from a parent class. Someone who 'gets it' will say something about polymorphism, abstractions, and/or interfaces.

Yes, I should have expanded on that point. By not getting it I understand that some people use classes as just a way to partition methods and data, instead of reasoning about how objects collaborate. But my original point stands that I don't think it's very useful or even logical to shove every single thing that exists in a program into classes. In my mind, it almost encourages "not grokking" OO. I'd rather do like what nemerle does. Everything in a module is static and you just expose what you want via accessibility modifiers. Maybe I'm being anal about the whole thing, but each of us has our own idiosyncracies about how we read and then reason about code.

By not getting it I understand that some people use classes as just a way to partition methods and data, instead of reasoning about how objects collaborate.

This is a very excellent point. People really think procedurally which is why the often don't grok OO. OO is often more about relationships then it is about things doing something. Ok, something maybe doing things but more often then not the doing is orchestrating activity in the relationships and that translates into delegating. Take the command pattern for instance. Commands should capture some intent at the time that intent is stated. Intent doesn’t really do anything except act to stimulate the system to do something. If the framework integrates the command in order to figure out what to do, then you’ve drifted back into procedural thinking. IOWs, your processing code is no longer delegating, it is trying to do something. People who blogged about the evils of get a while back were ones that got this point. Instead of interrogating, the framework should delegate the orchestration of the execution of the command back to the command. The missing piece that probably wasn’t known when the command was created was a hook back to the framework in which is asked to execute in. This is known as double dispatching. The command and the framework now form a complete execution context, each supplying each other with the information that each other is missing while using delegation to orchestrate flow through the framework. When you follow this model (not only with command pattern but as a way of writing code in general) you find that the context gives you the power to do without having to write a lot code to decide what needs to be done. Another thing, if you have context now that will be needed in the future, capture it in the form of an object. It maybe only state, it maybe only behavior, most likely it will be a bit of both. It most likely will not offer any useful functionality on its own. However captured state (or intent) will help orchestrate activity in the future without the need to rediscover the context in which you need to function. There are two metrics that you should use to get a feeling if you are heading in the right direction, lines of code, and reduction in the number of if and switch statements (one begets the other ;-)). As for functions without a home, this is a code smell that I have a missing element in my design. Here is a practical example, java.lang.Math is static, abstract and final. IOWs, it is a collection of functions with no home. The code smell is that int, float, double, etc…. are not objects and hence any functions that are directly related to these types have to be put into a utility class. This wouldn’t have to happen had int etc. been exposed in the language as objects (remember, implementation != representation).

But my original point stands that I don't think it's very useful or even logical to shove every single thing that exists in a program into classes. In my mind, it almost encourages "not grokking" OO.

I can't really say why many people don't grok OO however my list of suspects would not include this thought. It would include poor education or rather poor instructors. I was blessed by professors that really did understand OO. They beat us up on OO concepts. They expressed open disappointment when we didn't get it (expressed in the class not getting the "right" answers to problems). In retrospect I can see that my situration was extremely rare. There were only a few number of institutions on the planet at that time that was subjecting their undergrad students to this type of regime. Now it is more common however it is also more dilute has there are still plenty of reasonable professors that also don't get it and pass on this lack of getting it to all of their students. The smart students will survive this mis-teaching but I'm afraid that will leave many more with a broken view of OO. To give due credit, I attribute most of what I know about OO to Dave Thomas, John Pugh, Paul White, and Wilf Lalonde. Here is a little history of their contribution to the industry as a whole.

Hmmm. I don't know if that's really how I would describe it. Classes represent concepts (ala Plato.) A Tree class represents the concept of a tree. A tree Object represents an actualy concrete tree. In real terms classes represent functionality: what can you do to a tree? Objects represent state: how tall is the oak, does it have leaves?

See, the problem is that you're giving examples of real-world entities that are a small fraction of what really goes on in programming. But that's really a problem with the teaching methodologies (Circle derived from Shape...)

Conceeded. It was meant as an analogy more than an example. The point I was trying to make is that OO is an extension of the that humans interpret the universe.

Can you elaborate on what you mean? In all honesty, I have no idea what you mean (my ignorance being the issue.)

Here is the wikipedia entry for CLOS.

I don't know that I agree with this articles assertion that it's 'radically' different. More below...

Functions and data structures are separated.

Is this really that different? That's precisely what happens at runtime in Java. What's the advantage. I find that putting the methods in the same place as the fields they act upon helps keep things organized. I also feel that lack of encapsulation complicates an API. Hiding fields isn't as much about protecting data as it is about steering people down the proper path when using your class. If the developer can't see the field, they can't be confused about it or have to figure out whether it is important to them. They just don't have to care.

There's multimethods to do deal with the Visitor pattern,

To me this is just a feature that Java lacks. There's no specific reason that it couldn't be implemented in Java, it was an arbitrary decision based on performance consideration (to my knowledge.) I actually think it was a poor choice and many many new Java developers are confused when it doesn't use multiple dispatch. To my mind, method-overloading in Java is almost worthless.

and in the case of Dylan there's a module system for the functions/methods/data structures you want exposed to the public.

So in response to your first question, I find it more natural and a cleaner way to reason about OO when your methods, data structures, and accessibility are separated.

I see what you are getting at now. I can see how this would be useful in development but what about in maintenance? It seems to me that it would be kind of chaoic trying to figure out where the method is defined. But that's a completely uninformed assessment, I admit.

And of course like any sane language, functions are first class values.

Yeah, that's really a drag in Java. The 'Java solution' is to define an interface, but it's often cumbersome and discourages the use of this type of approach.

I can see where you are coming from but it seems like a nit you are picking.

I want to clarify by what I mean by 'not getting OO'. If you ask most developers what OO means, they say something along the lines of 'everything's an Object' or 'you use Objects': basically a non-statement. And their code is a bunch of procedural code associated with an Object and maybe inhereting some common functionality from a parent class. Someone who 'gets it' will say something about polymorphism, abstractions, and/or interfaces.

Yes, I should have expanded on that point. By not getting it I understand that some people use classes as just a way to partition methods and data, instead of reasoning about how objects collaborate.

But my original point stands that I don't think it's very useful or even logical to shove every single thing that exists in a program into classes. In my mind, it almost encourages "not grokking" OO. I'd rather do like what nemerle does. Everything in a module is static and you just expose what you want via accessibility modifiers. Maybe I'm being anal about the whole thing, but each of us has our own idiosyncracies about how we read and then reason about code.

I agree with you on a lot of these things. I guess now I am confused because you seem to really like OO, just not the way Java does it.

Java developers can deliver functionality at a rate 2.5 times faster than those working in C++.

In my performance tuning course there are a number of examples where the application being tuned has an identical performance profile no matter the language of implementation. Bottom line, architecture is often a more the dominant factor in application performance. In these instance speed to market would seem to be a much more important factor in choice of languages.

A typical application contains sub-optimal code and though JVMs and JITters have progressed a lot, the same kind of sub-optimal code would result in a tilt in C++'s favour. For a typical distributed enterprise application, it is likely that the majority of the wall clock time is spent in communication between tiers and/or in database interactions. In these cases, you would not see a huge difference between a C++ or Java equivalent. So, Kirk is probably right in this regard. However, if you focus only within one tier, a typical C++ equivalent is likely to be faster. A micro benchmark that contains a few dozen algorithms, or a few 1000 lines of code in C++ and Java is not likely to show the true performance characteristics of either one. Throw in a couple of hundred thousands lines of sub-optimal code, I/O, heavy threading, complex data structures, and graphical UIs and I believe C++ would win - quite easily at that. I've been a Java developer for about 8 years now, and I believe that its programming features and heavy use of OO are beneficial when used optimally. Use of low level techniques, while contributing to a performance gain are likely to result in a brittle, harder to maintain application. Then again, I've seen some horrible Java code (make that mostly horrible code ;) in 4 years of consulting, so the argument that competency/beauty is better on the Java side doesn't hold water - except maybe in (J)utopia. For example, I don't see any OS kernels/core database engine/core web server engines written in Java (or .NET). As an aside, I wonder where Kirk got his "develop 2.5 times faster in Java than in C++" figure? -krish

As an aside, I wonder where Kirk got his "develop 2.5 times faster in Java than in C++" figure?

Personal experience, your millage may vary ;) Kind regards, Kirk Pepperdine

Java is primarily a platform, not a programming language, comparable to MS.NET. OTOH, C++ is a rather complicated but effective general purpuse programming language. The 'Java' success is due to the Java platform not the overweight and verbose Java language. If you develop on the Java platform you need 10 times the resources (memory, CPU) compared to a lean C/C++ program (Sun probably invented Java to sell more expensive hardware). 'Java' is good for Web-applications because the Java platform provides good support (Servlets) for that kind of programming. For large scale and performance critical applications C++ still is (and will be) the best choice.

Java is primarily a platform, not a programming language, comparable to MS.NET. OTOH, C++ is a rather complicated but effective general purpuse programming language. The 'Java' success is due to the Java platform not the overweight and verbose Java language.

Too bad that Sun doesn't seem to realize that.

Java is primarily a platform, not a programming language, comparable to MS.NET. OTOH, C++ is a rather complicated but effective general purpuse programming language.
The 'Java' success is due to the Java platform not the overweight and verbose Java language.
If you develop on the Java platform you need 10 times the resources (memory, CPU) compared to a lean C/C++ program (Sun probably invented Java to sell more expensive hardware).

As far a memory goes, you are probably right. But in terms of CPU, this is no longer the case. Java actually surpasses C/C++ for certain types of applications in terms of speed. For example, Java can create Objects (on average) faster than C++ in modern VMs. In future VMs it will even support Objects allcations on the stack with no syntax changes. This is precisely the kind of unfounded FUD that this blog is about.

But in terms of CPU, this is no longer the case. Java actually surpasses C/C++ for certain types of applications in terms of speed. For example, Java can create Objects (on average) faster than C++ in modern VMs. In future VMs it will even support Objects allcations on the stack with no syntax changes.

C++ not only has fast stack based objects today but, unlike Java, also fosters stack based idioms.

This is precisely the kind of unfounded FUD that this blog is about.

Agreed. I'm against unfounded FUD. The Java performance advantage claims are mostly unfounded.

But in terms of CPU, this is no longer the case. Java actually surpasses C/C++ for certain types of applications in terms of speed. For example, Java can create Objects (on average) faster than C++ in modern VMs. In future VMs it will even support Objects allcations on the stack with no syntax changes.

C++ not only has fast stack based objects today but, unlike Java, also fosters stack based idioms.

That doesn't really make any sense. Sorry.

This is precisely the kind of unfounded FUD that this blog is about.

Agreed. I'm against unfounded FUD. The Java performance advantage claims are mostly unfounded.

Considering you haven't provided a single scrap of evidence, I find that pretty ironic. http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

The 'Java' success is due to the Java platform not the overweight and verbose Java language.

The Java language is hardly overweight. It has been cut back a lot from C++, indeed this is one of the most frequent complaints about it.

If you develop on the Java platform you need 10 times the resources (memory, CPU) compared to a lean C/C++ program>

Depends - do you count the memory used by the VM as well? If not, Java can be pretty small, as most implementations load individual classes on demand, not entire libraries. Sure, C++ will probably be smaller for a program of hundreds or a few thousand lines, but is it really the right language for that scale of development?

(Sun probably invented Java to sell more expensive hardware).

This is just plain FUD.

'Java' is good for Web-applications because the Java platform provides good support (Servlets) for that kind of programming.

The Java platform provides good support for a wide range of types of programming. Just consider the concurrency capabilities, the networking libraries, the GUI implementations, and so on. Simply to select Servlets is to take a very narrow view.

For large scale and performance critical applications C++ still is (and will be) the best choice.

I don't think so. Java really seems to be the main language for large scale development right now; at least that is my impression.

For large scale and performance critical applications C++ still is (and will be) the best choice.

I don't think so. Java really seems to be the main language for large scale development right now; at least that is my impression. I'd call this a tie. He said C++ is the best choice. Your reply was that Java was the main language used ... Both of you are correct. But just because Java is used more for large scale developments does not make it the best language for performance critical applications. If you did a survey of very high-performance applications running in banks and telcos, I'm sure you'd find much more C++ than Java. But this is at the very top of the market. The real question is going to be how to handle high-performance SOA applications!

For large scale and performance critical applications C++ still is (and will be) the best choice.

I don't think so. Java really seems to be the main language for large scale development right now; at least that is my impression.

I'd call this a tie. He said C++ is the best choice. Your reply was that Java was the main language used ... Both of you are correct. But just because Java is used more for large scale developments does not make it the best language for performance critical applications. If you did a survey of very high-performance applications running in banks and telcos, I'm sure you'd find much more C++ than Java. But this is at the very top of the market. The real question is going to be how to handle high-performance SOA applications!

But just because Java is used more for large scale developments does not make it the best language for performance critical applications.

No, but as Java is used for performance critical applications, and had major advantages over C++ in terms of development time and maintainability in that situation, it would seem to be the better of the two languages to me.

If you did a survey of very high-performance applications running in banks and telcos, I'm sure you'd find much more C++ than Java.

Of course you would - C++ has been around for a lot longer than Java, and certain a lot longer than Java with reasonable performance.

Part of the problem is that the design of Java is dumb, and I can tell you that are more that fifty percent of Java programmers are bad I will say close to seventy. I am working in Java now (moved from C++) and I hear in interviews questions as what is the difference between a HashMap and a HashTable, last time I got upset for such an stupid question and I ask why the default load is 75 If you are a C++ programmer, you understand what a hash is and what that means, a Java programmer will not know. This is because Java is a commercialized tool, where you have toolkits to do something you do not learn about programming you learn about the toolkits, and then not even that.

As a user of both C++ and Java, I was pleased to discover the D programming language (http://www.digitalmars.com/d/). It is a statically-compiled language but offers a lot of features that are more like Java and other modern languages. And it's fast :) I've seen other languages brought up in this discussion such as Python and Ruby, and thought that D might be a good topic for argument.

+1