Java Generics are for all intents and purposes the same as C++ templates for most people. Inheritance is vertical generalisation. Generics/templates are horizontal generalisation. Combine the two and you have a 2D space of types. Use either one and you extend on one axis. Who uses template metaprogramming apart from time wasters?Who uses traits?Java has a lower entry level. Because of this the average is lower than C++. The top end though is the same as C++. This is definitely true from 15 years personal experience.Smart pointers, reference counting, writing new() to work off your own pool of memory, in C++. People have been doing that for years. And of course, i've had to work on many memory leaks in Java. Java is better because there are less ways to skin a cat. Reading code is the hard thing, not writing it. Reading poorly written C++ is hard due to macros, typedefs. Getting your head around someone elses style is half the battle. This is easier in core Java.You are not forced to do OO programming in Java. Class do not imply OO. You can make everything static if you like and follow a procedural style. You can write functional style in Java. You have functors/currying - anonymous inner classes.

QuoteOriginally posted by: brownie74Smart pointers, reference counting, writing new() to work off your own pool of memory, in C++ ... Java is better because there are less ways to skin a cat. I agree with most of what you said. But the above, I'm not so sure. Java is better in many cases (blotters, stp & back office booking systems etc... ), but there are many cases for example where you do care about memory and do want to use your own memory allocators. I've seen this internally in some libraries, specifically dealing with large data requirements, e.g. caching calibrated surfaces etc... and being quite precise about the lifetime of objects. Re: use of templates, I've yet to see anything as comprehensive and intuitive as uBlas, Bltiz++ in Java, specially where expression templates may yield significant performance gains.Picking the right tool for the job is important, frequently it will be Java, frequently it will not be... and I've found many Java developers find that difficult to accept.

QuoteYou are not forced to do OO programming in Java. Class do not imply OO. You can make everything static if you like and follow a procedural style. You can write functional style in Java. You have functors/currying - anonymous inner classes.Nope, no, nicht, ni hea, njet. You must do OO in Java, everything is a class. You must do OO.And statics are a load of junk, in any language (just use global, non-oo functions)The craziest I ever saw wasMath.sin(3.14)

QuoteOriginally posted by: CuchulainnQuoteYou are not forced to do OO programming in Java. Class do not imply OO. You can make everything static if you like and follow a procedural style. You can write functional style in Java. You have functors/currying - anonymous inner classes.Nope, no, nicht, ni hea, njet. You must do OO in Java, everything is a class. You must do OO.I think he way saying that you can (if you really want to) code in a non OO way in Java. Rather than a comment on it's desirability.

QuoteOriginally posted by: MichaelLQuoteOriginally posted by: CuchulainnQuoteYou are not forced to do OO programming in Java. Class do not imply OO. You can make everything static if you like and follow a procedural style. You can write functional style in Java. You have functors/currying - anonymous inner classes.Nope, no, nicht, ni hea, njet. You must do OO in Java, everything is a class. You must do OO.I think he way saying that you can (if you really want to) code in a non OO way in Java. Rather than a comment on it's desirability.In that case, I do _not_ agree. Java is OO and has no procedures. You _cannot_ program in a non-OO way in Java, with the exception of generics in 1.5!

QuoteOriginally posted by: CuchulainnIn that case, I do _not_ agree. Java is OO and has no procedures. You _cannot_ program in a non-OO way in Java, with the exception of generics in 1.5!Of course you can, I've seen awful non-OO Java code, A "class" full of statics and huge methods - its just (bad) procedural code.

QuoteOriginally posted by: MichaelLQuoteOriginally posted by: CuchulainnIn that case, I do _not_ agree. Java is OO and has no procedures. You _cannot_ program in a non-OO way in Java, with the exception of generics in 1.5!Of course you can, I've seen awful non-OO Java code, A "class" full of statics and huge methods - its just (bad) procedural code.In that case, I agree with you Once the director of a project demanded that all C programmers should write OO code. So, to be compliant one smart cooky did the following, a bit like the way Java does maths functions

Coding to interfaces: the most misused "OO" concept.You write a class, extract an interface and make your class implement the interface. Then, do you expect a second class to be able to implement that interface sensibly?You cannot generalise from a sample of 1. You will have to bend your new code to fit the interface. Unless your interface is so generic, its useless.

QuoteOriginally posted by: brownie74Coding to interfaces: the most misused "OO" concept.You write a class, extract an interface and make your class implement the interface. Then, do you expect a second class to be able to implement that interface sensibly?You cannot generalise from a sample of 1. You will have to bend your new code to fit the interface. Unless your interface is so generic, its useless.Almost any OO concept can/is abused in some form on most libraries/systems you'll come across. Simply because of the number of people that work on them. I work on a library that was started in 2000-ish and has the nutty idea of 'backward compatibility' , result, a pig's ear of different OO and design philosophies and a fat, bloated library.

On the subject of interfaces decoupling from implementation.You are merely removing an explicit coupling and replacing with an implicit one.Mapping code to/from canonical form is semantically the same as an API call.

QuoteOriginally posted by: brownie74On the subject of interfaces decoupling from implementation.You are merely removing an explicit coupling and replacing with an implicit one.Mapping code to/from canonical form is semantically the same as an API call.I'd recommend this book:Large-Scale C++ Software Design by John Lakoshttp://www.amazon.com/Large-Scale-Software-Add ... 201633620A little bit dated, but the rationale behind layering and interfacing on a library stack/system is excellent.