Software is not art, it is engineering. And since it is engineering, it must have strict laws. Art is something that does not have real world consequences when used; it is a totally different thing from software.

> I really can't imagine a world in which Java makes a set> of syntax changes that are that radical. IMHO, I think> you're better off giving it a new name, compiling it to> the JVM and announcing it as a new language.I agree with that. If its going to be radically different, then there is no point in mixing the two...a different language that...

> The language shall not be 'boring' but...I disagree. A language shall be as boring as possible. It is only then where reuse can be truly realized. Being boring means that there every possible problem has been already solved and the only interesting part is how to combine the existing stuff into solving a particular problem.

The 'not invented here' syndrome would be reduced if programming languages were more boring...i.e. if programming languages did not allow code to be like a painting but rather like a blueprint: paintings are all different and they have the personal touch of their creator, whereas blueprints are all the same and are created by specifications...

Personally I have no interest in using such syntax beautifications, and neither will my software team. Our aim is to have good and consistent design...these low level details are irrelevant to good code. Furthermore, I find syntactic exceptions dangerous: they make the code easier to write, but harder to read, especially if you go back a few...

Has anyone used the full spectrum of Hibernate's capabilities yet? or even J2EE? and if so, can someone share the experience?

Ehmm...what happened to the simple object-oriented language for the masses called Java? more bloat, more rules, more exceptions is not good for the language, is it?

Since each programming language provides different levels of abstraction, each object implementation is different: C++ objects are nothing more than hardcoded records of data and pointers , whereas Ruby objects are maps of fields and methods which is changeable at run-time; there can never be a co-operation between those objects in a...

> Joking aside, the fact is that a majority of developers> don't want to use GC with C++. How many real life projects> are there where C++ is used with GC?You are mistaking the effect for the cause. Real-life projects don't use GC with C++, because C++ does not have GC, libraries don't support GC, the STL does not support GC.I forgot to add to...

> The fundamental problem with Java is that it consumes "too> much" memory, and that inevitably slows down the system.Another problem is that C++ has a memory model which allows faster implementations; stack-based allocation can really speed up programs; and it is not the same as gc linear allocation, because the gc has to be locked for...

> > > Seriously, none of developers I know would ever use> GC> > > with C++.> > > > The perils of the self selecting survey! Those> developers> > that desperately needed GC have mostly gone elsewhere.> > :)> > Note that I say "would never use GC with C++". Many> developers use more than one programming language even> within a single project...

> > And not putting garbage collection in the standard is> not> > ignoring the needs of real C++ programmers?> > > > No, it is not :)> > Seriously, none of developers I know would ever use GC> with C++. If you need GC, use a GC enabled language - some> of them claim to be very performant, ie D, OCaml... > > IMHO, for the C++ community threading...

> > Many C++ programs suffer from manual memory management,> > and gc is a priority over threads. I have not used a> > single C++ application that has not crashed in one way> or> > another, due to some wild pointer or memory leak. > > Using boost::shared_ptr (or some other kinds of smart> pointers) can eliminate many (in some cases all) memory>...

> > But almost all C++ versions in almost all O/Ses provide> > threads, critical sections, mutexes and semaphores.> > Therefore I do not see where is the problem for the 99%> of> > the cases.> > But how do you port such code or write portable> applications? The current answer seems to be that> portability is restricted to the set of operating...

> > no way to write programs like Firefox, Word, Powerpoint> > and Visio in languages other than C++, because those> other> > languages do not allow the performance of C++. > > None of those applications would be in my list as> requiring C++ for performance reasons. Today, all could be> implemented in a number of other languages without>...