Forgetting a try-catch is not a problem -- worse case is your program crashes and you get a *nice* stack trace telling you all the state you need to do some debugging triage before pulling out a real debugger.
No, I had such a problem last week: in certain situations the app did not close the Database connection. There was only a limited number of sessions available in the pool, and after the situation occurred n times (where n is the size of the session pool) opening a new connection caused the app to freeze - because it would wait for a new connection. As it happened in a small application it was relatively easy to find out at which place the close wasn't called, but in a large app I could have searched for days...
Depends on how you use MI. There are certainly bad uses of MI, like you can misuse almost every feature. But there are also good ones, and he mentioned one of them: "interfaces with default implementations". They won't be more difficult to read than a UML diagram with regular interfaces, only with less duplicated code.
Redundant & ugly?
Redundant means that because of the lack of function templates, method pointers, macros and multiple inheritance (or an equivalent) you constantly create code similar to existent code.
Java forces you to do cut&paste programming, which is ugly. If you have two functions that are very similar, but differ in one or two subtle details (different datatypes, call different methods) you have to write them twice. If you find a bug in the first you must correct it in the second implementation, too.
It also hurts re-use. Re-use of algorithms is very complicated in Java. Even in simple cases, like sorting an array of integers/floats, it is not possible in Java unless you wrap everything in objects. Just compare the Java collection classes to the STL.
Redundancy is IMHO a more dangerous source of errors than memory leaks. Memory leaks are avoidable, because they are usually only a sign of a bad design. In a good C++ design you should avoid heap allocations, if you don't cant you still have smart pointers, and if you cannot use them you should create a simple but strict policy for memory management. Java's design flaws make classical human errors likely. Small errors that were made while doing copy&paste stuff, subtle errors in algorithms because you have to implement them over&over again, errors in resource deallocation when an exception occurs because the code paths of exceptions are hard to follow.
We use pointers (yes, there are sort of pointers in java) to objects, and invoke methods on the pointed-to objects. reflection is used for other purposes.
Many APIs use reflection as a convenient replacement for the lack of method pointers - it is so much easier to use a method name and a object reference than creating a new (inner) class for each method.
"We are too lazy to write the long static method invocations, so we just inherit from the class that contains the methods that we need".
I don understand your point here!
That there are people who are fed up with writing Classname.methodname for each invocation of a static method so they use inheritance to get rid of it.
You either have to write 20 or more characters for each invocation, which can make complicated code unreadable and is annoying to type, or you write wrappers for each
static method in your own class, or you inherit from the class that is providing the static methods.
What is your point here? The Bean pattern is useful but not for everything. Reflection is used for examining objects of unknown origin. It is generally not used for method invocation. Nobody does.
Actually many people do this, because it is by far the most convenient solution for many problems. Just look at the Jakarta stuff.
In C/C++, retrieving a function from a (previously unseen) DLL requires a method name too. In Java, reflection does this. However, once you have the method, Java can pass a reference to it around using the Method object, whereas C++ passes a function pointer.
Just look at the APIs of, for example, JUnit. Because they want to avoid creating a single class for each method they start messing around with method names. Many users of beans do similar things, for example the Jakarta Beanutils and Struts that uses it.
Preprocessors and macros are generally a bad thing. They are effectively cut-and-paste at compile time, and they are a pain at debug time.
Actually I wanted to say "Preprocessors and templates". I think that proeprocessors are very useful though, but more for initialization and testing. It is often much easier to write a few macros than to design you own file (/XML/etc) format to describe something, at least if the data is known to be stable.
That is either a gross generalisation, or a badunderstanding of design. Java allows objects to contain static methods, which can be invoked from anywhere else, without instantiating the object that contains the static object.
You can excplicitly see this in JUnit, they are to lazy to write Assert.assertTrue(), so they let the TestCase class inherit from Assert. There is no other relationship between those classes.
Then there is the stupid overuse of try/catch blocks because the style encourages this, leads to local error handling code all over the place and defeats the whole purpose of exception.
Even worse IMHO is the lack of stack-allocated objects. The garbage collection does a good job for memory management, but it does not help for other resources (like database connections that must be closed). So you clutter the whole code with try/finallys, and it is soo easy to forget one of them and get errors that are REALLY hard to find because they only happen very infrequently.
No, actually I was a writing Java full time for over 3 years before coming to that conclusion. There are so many things that I cannot express in Java without being redundant which always annoyed me. I didn't have any significant experience in C++ (or any other OO language) before.
I don't say that it is impossible to write bad code in C++.
I say that Java when using Java you have the choice of either writing ugly or redundant and error-prone code.
And I still don't get why those people who insist on Java programming cannot see how screwed up Java is. Just look at any of the well-known Java projects (JUnit, the Jakarta stuff) and watch how insane programming in Java is. "We don't have method pointers, so we use the method name and reflection". "We do not have preprocessors or macros, so we cut&paste the code and modify each copy a little bit". "We are too lazy to write the long static method invocations, so we just inherit from the class that contains the methods that we need". "Lets make everything a bean, use reflection to access it and separate the code in 5 layers - ok, we write 10 times the code of a simple solution, but look how easy it is to do this change"...
I admit that C++ is harder to learn, just because of its pure size, but it really pays off because it contains so many features that are really make your life easier without using all the ugly cludges that the Java guys must do (unfortunately I am one of them and do this 8hrs/d).
I doubt that telephone companies would care. They make money with long-distance calls and lose money on local calls, so they rather make more money if people use other networks for local calls.
Hopefully.. there's only so much you can do with a window manager, and 50 different should be enough for everybody, so people can now work on improving desktop environments or applications.
IMHO the only question for you should be: is there a market? Obviously the current linux games market won't justify the effort. Possibly the Computer Graphics people are interrested in such a compiler, or maybe for scientific stuff (after all a 30% speed increase in a 100 node beowolf cluster means that you could save 30 nodes).
A German court has ruled that you can even sell your OEM versions, and Microsoft can't do anything against it (even though they tried). But in the US this is probably different, thanks to the DMCA...
Actually the original Castle Wolfenstein has been forbidden in germany. Not because you shoot germans or general violence, but because of the display of Nazi-symbols which was considered as glorifying them. Don't ask why shooting Nazis means gloriying them, or why Indiana Jones 3 has been shown in german cinemas, there is no logic behind it.
IMHO the only way of financing OpenSource is by getting money for writing features. Features can be written by a company's developers in-house, or by paying a 3rd party for it. Unfortunately 'paying a 3rd party for it' is quite complicated for mainstream features. While a CPU-manufaturer may be willing to spend a few millions for a port of a compiler to his new architecture, no one will be willing to spent so much money for basic desktop features, so you would have to bundle people's money. I'm sorry things like Sourcexchange and CoSource did not work out, but from what I have seen the people just demanded unrealistic (large) projects instead of paying for single features for existing software.
I doubt that you can finance software with support, and I am quite sure that selling free stuff is not a good business model.
That isn't true at all. There are many individuals, companies, manufacturers, schools, and foreign governments to whom the low cost nature of free software is a huge incentive.
It's not only the cost itself, it's also the bureaucracy that non-free software causes. Say you work in a large company and want to buy a 1000$ piece of commercial software.
First you have to get the permission to order it, budgets have to be checked, you have to argue why you need it. Maybe you also need to evaluate it and some competing software. The next step is ordering it. If it is retail software you have to find a retailer that has the item on stock, otherwise you have to wait a few weeks. If you get the package by mail you need to wait a few days till the software arrives. And when you finally got the package and a colleague needs it too, you have to buy another license and everything starts from the beginning. (And I didnt even mention MS-style license audits, IT departments that want to manage all software licenses and so on).
Compare this to free software: download, install, work. In development departsments where people frequently need new software for their tasks the cost saving of free software is MUCH higher than only the license costs.
1. If you want to play (3D) games, make sure that you have a GeForce 2 Go chipset. It's the only one that allows you to play newer games at decent framerates
2. For Linux you should check whether your built-in modem is supported
3. Integrated WaveLan/WiFi is a cool feature if you know other people who have it, much better than an external PCMCIA card
4. If you want to use external drives (CD burner, faster harddisks (Laptops harddisks are slooow)), make sure you have a FireWire/iLink/ieee1394 port
You can even pre-compile your assemblies if you want to.
Some people claim this is what gives C# better performance. I'm not convinced.
The most important difference is that you cannot load any classes dynamically. AFAIK this is not possible in.net, but maybe I just overlooked it. This can reduce many virtual method invocations (and makes inlining possible).
How is the API defined? Is there a interface definition language like CORBA IDL?
I don't know how they describe it in the specification, but there is so-called meta-data in each assembly (the equivalent to a jar). This meta-data describes the classes, methods and so on.
Microsoft has promised to put C# and the virtual machine through the ECMA process. However, if most C# developers come from the Win32 background and heavily use libraries such as ASP.net, WebForms, ADO.net then how will those applications be portable?
You see it more from the compatibility-side than I do. I like C#, the CLR concept, the base libraries and that's it. I want some nice KDE-libraries for the CLR so I can write my KDE software in C# and/or Python. The possibility of executing Windows-software is only a side-effect for me. There will probably some company like Ximian doing it if there is a market for it, but I don't care too much about this. If MS starts making incompatible changes that's bad, but doesn't really affect my software.
You said you rarely need to use pointers yourself. I agree. And when I do, I don't want to do it inside the virtual machine and compromise it's stability or security. For any system programming I will use C.
But then you have whole categories of software that cannot be run by your VM, for example every piece of software that uses signal processing (video/sound stuff), probably also games. You cant get platform independent if you still have to use native code for 20% of the applications, even if only 1% of their code is native.
Beside that, using native code does certainly not improve your stability or security as long as it runs in the VM's process. The only secure way is to have it in a single process, and you can have that without native code, too.
Adaptive optimization of HotSpot really does make a difference in many cases.
The reason for all the complicated adaptive optimization stuff is the bad design (performance-wise) of the bytecode. Because in OO-software most methods are very small the best way to optimize a program is by inlining. Hotspot does exactly that. But because in Java every method is virtual (unlike CLR) and you can load new classes that override methods from existing ones at every time doing this is dangerous, and you may have to redo the inlining after you load a new class. This is quite a complicated and expensive process, so Sun tries to avoid for most methods it by making it adaptive.
They created a monster because their bytecode is a little bit too flexible. In the CLR this is not neccessary. You can even pre-compile your assemblies if you want to.
I dont think it is fair to bash.net because only it is from Microsoft.
Beside all the political stuff about Microsoft, Gnome and Ximian IMHO, the
ideas of.net and at least a large part of the specification are quite nice.
It solves many problems of the current systems:
you have a single API for all programming languages (which
admittedly all get quite similar because they all have to support various
OO-features, exceptions and so on). Currently it is only theoretical
possible to program for Gnome or KDE in a scripting language. In reality you
will get only half of the APIs and it means a lot of trouble for the end
user..net also comes with a unified format for things like API
documentation (that is written in XML and generated by the compiler itself).
You dont have trouble any more if you use a non-x86 platform. This could
bring real freedom in the platform choice.
Things like buffer overflows will be very rare (they are still possible
because you can use pointers, but you rarely have to use them and your code
is marked as insecure).
I think it is desirable to have something like this, and if MS releases the
specs for it and you get some interoperability for free this is a good
opportunity. Even the design of the CLR (Common language runtime) alone is
such a huge effort that the free software community just saves much time by
adopting it. And the base library looks very nice, they even have unix-like
things in it, for example support for perl-style regular expressions.
Something that is still missing in the Java (even if they announced regex
support for a future release)...
Speaking of Java, I dont think that it is an alternative:
It is definitely not more 'free' than the.net stuff (if MS really
submits the specs to ECMA)
The JavaVM is quite limited to Java as language. Yes, there are other
languages for the JavaVM, but the VM isnt really flexible enough and you
dont have things like pointers available which you need for system
programming.
Java's performance sucks because of several design mistakes (ok, they
are only mistakes if you see it from a performance point-of-view, you could
also argue that Java's design is cleaner). MS got several things right that
cause the bad performance of object-oriented Java projects:
they do
not make every method virtual
there is an alternative to heap-allocated
and garbage-collected objects (small objects can be allocated on the stack
and are passed-by-copy)
they made some restriction into their IL (intermediate language) that
Java's bytecode doesnt have and result in faster/easier code generation.
Both are stack-oriented, but in IL the stack must have the same depth at
every jump-point
Of course, there are also ugly parts in.net. This is basically everything
that is not in the core specs, like WebForms, ASP.net, ADO.net and so on.
But no one says that you cannot have your own, additional APIs...
I can understand him somehow as I have similar feelings about a german system called Fischer Technik that has almost disappeared from german toy stores in the last 10 years. While not as complicated as Meccano (no screws and stuff) the constructions were more stable, the motors bigger...
In other words, Fischer Technik allowed you to build larger and more complex things (after all the first sets were made for industrial models, and that's what it is still used for today). It also pioneered many things that Lego had done only years later: sets for pneumatic, electronic circuits and a programmable computer interface.
IMHO C++ is no language that is easy to learn, but if you are are writing software 40 hours a week you will soon appreciate its large feature set (and maybe even the compact syntax). Java's lack of features like templates/generic programming, macros or multiple inheritance has both advantages and disadvantages. The advantage is that the language is small, easy to learn and it does not have any features that an inexperienced or tasteless programmer can misuse.
The disadvantage is the lack of expressive power resulting of this. Basically Java encourages Cut&Paste programming, which is a maintanance nightmare, a major error source and the root of all evil.
In Java you cannot write something once and then use it for different types, so you start copying the code and modify it slightly for each type. In C++ you can write it once and use templates.
The same problem is code that repeats itself only with slight variations that cannot be expressed with functions. This mostly occurs in regression tests, and can easily done with macros in C++. In Java you will start to copy&paste...
When people need multiple inheritance with several non-abstract classes in Java they start to implement an interface and copy&paste the code. Sometimes this is also done using a code-preprocessor, like some CORBA implementations did. In C++ you just multiple inheritance.
As I see it, University (College) is about education not about industrial training. You shouldn't be taught specific tools at university rather you should be taught theory.
Many people see it this way, and I can understand it to a certain degree. But you should also consider that learning a programming language to a level where you are REALLY productive and wont regret what your wrote 6 months later takes years. I think I reached this point in Java after 1-2 years (fulltime programming), C++ probably needs much longer - I cannot claim that I reached this point.
Slashdot Mirror
No, I had such a problem last week: in certain situations the app did not close the Database connection. There was only a limited number of sessions available in the pool, and after the situation occurred n times (where n is the size of the session pool) opening a new connection caused the app to freeze - because it would wait for a new connection. As it happened in a small application it was relatively easy to find out at which place the close wasn't called, but in a large app I could have searched for days...
Depends on how you use MI. There are certainly bad uses of MI, like you can misuse almost every feature. But there are also good ones, and he mentioned one of them: "interfaces with default implementations". They won't be more difficult to read than a UML diagram with regular interfaces, only with less duplicated code.
Redundant & ugly?
Redundant means that because of the lack of function templates, method pointers, macros and multiple inheritance (or an equivalent) you constantly create code similar to existent code. Java forces you to do cut&paste programming, which is ugly. If you have two functions that are very similar, but differ in one or two subtle details (different datatypes, call different methods) you have to write them twice. If you find a bug in the first you must correct it in the second implementation, too.
It also hurts re-use. Re-use of algorithms is very complicated in Java. Even in simple cases, like sorting an array of integers/floats, it is not possible in Java unless you wrap everything in objects. Just compare the Java collection classes to the STL.
Redundancy is IMHO a more dangerous source of errors than memory leaks. Memory leaks are avoidable, because they are usually only a sign of a bad design. In a good C++ design you should avoid heap allocations, if you don't cant you still have smart pointers, and if you cannot use them you should create a simple but strict policy for memory management. Java's design flaws make classical human errors likely. Small errors that were made while doing copy&paste stuff, subtle errors in algorithms because you have to implement them over&over again, errors in resource deallocation when an exception occurs because the code paths of exceptions are hard to follow.
Many APIs use reflection as a convenient replacement for the lack of method pointers - it is so much easier to use a method name and a object reference than creating a new (inner) class for each method.
"We are too lazy to write the long static method invocations, so we just inherit from the class that contains the methods that we need".
I don understand your point here!
That there are people who are fed up with writing Classname.methodname for each invocation of a static method so they use inheritance to get rid of it.
You either have to write 20 or more characters for each invocation, which can make complicated code unreadable and is annoying to type, or you write wrappers for each static method in your own class, or you inherit from the class that is providing the static methods.
What is your point here? The Bean pattern is useful but not for everything. Reflection is used for examining objects of unknown origin. It is generally not used for method invocation. Nobody does.
Actually many people do this, because it is by far the most convenient solution for many problems. Just look at the Jakarta stuff.
Just look at the APIs of, for example, JUnit. Because they want to avoid creating a single class for each method they start messing around with method names. Many users of beans do similar things, for example the Jakarta Beanutils and Struts that uses it.
Preprocessors and macros are generally a bad thing. They are effectively cut-and-paste at compile time, and they are a pain at debug time.
Actually I wanted to say "Preprocessors and templates". I think that proeprocessors are very useful though, but more for initialization and testing. It is often much easier to write a few macros than to design you own file (/XML/etc) format to describe something, at least if the data is known to be stable.
That is either a gross generalisation, or a badunderstanding of design. Java allows objects to contain static methods, which can be invoked from anywhere else, without instantiating the object that contains the static object.
You can excplicitly see this in JUnit, they are to lazy to write Assert.assertTrue(), so they let the TestCase class inherit from Assert. There is no other relationship between those classes.
Even worse IMHO is the lack of stack-allocated objects. The garbage collection does a good job for memory management, but it does not help for other resources (like database connections that must be closed). So you clutter the whole code with try/finallys, and it is soo easy to forget one of them and get errors that are REALLY hard to find because they only happen very infrequently.
I say that Java when using Java you have the choice of either writing ugly or redundant and error-prone code.
And I still don't get why those people who insist on Java programming cannot see how screwed up Java is. Just look at any of the well-known Java projects (JUnit, the Jakarta stuff) and watch how insane programming in Java is. "We don't have method pointers, so we use the method name and reflection". "We do not have preprocessors or macros, so we cut&paste the code and modify each copy a little bit". "We are too lazy to write the long static method invocations, so we just inherit from the class that contains the methods that we need". "Lets make everything a bean, use reflection to access it and separate the code in 5 layers - ok, we write 10 times the code of a simple solution, but look how easy it is to do this change"... I admit that C++ is harder to learn, just because of its pure size, but it really pays off because it contains so many features that are really make your life easier without using all the ugly cludges that the Java guys must do (unfortunately I am one of them and do this 8hrs/d).
I doubt that telephone companies would care. They make money with long-distance calls and lose money on local calls, so they rather make more money if people use other networks for local calls.
Hopefully.. there's only so much you can do with a window manager, and 50 different should be enough for everybody, so people can now work on improving desktop environments or applications.
IMHO the only question for you should be: is there a market? Obviously the current linux games market won't justify the effort. Possibly the Computer Graphics people are interrested in such a compiler, or maybe for scientific stuff (after all a 30% speed increase in a 100 node beowolf cluster means that you could save 30 nodes).
A German court has ruled that you can even sell your OEM versions, and Microsoft can't do anything against it (even though they tried). But in the US this is probably different, thanks to the DMCA...
Actually the original Castle Wolfenstein has been forbidden in germany. Not because you shoot germans or general violence, but because of the display of Nazi-symbols which was considered as glorifying them. Don't ask why shooting Nazis means gloriying them, or why Indiana Jones 3 has been shown in german cinemas, there is no logic behind it.
IMHO the only way of financing OpenSource is by getting money for writing features. Features can be written by a company's developers in-house, or by paying a 3rd party for it. Unfortunately 'paying a 3rd party for it' is quite complicated for mainstream features. While a CPU-manufaturer may be willing to spend a few millions for a port of a compiler to his new architecture, no one will be willing to spent so much money for basic desktop features, so you would have to bundle people's money. I'm sorry things like Sourcexchange and CoSource did not work out, but from what I have seen the people just demanded unrealistic (large) projects instead of paying for single features for existing software.
I doubt that you can finance software with support, and I am quite sure that selling free stuff is not a good business model.
First you have to get the permission to order it, budgets have to be checked, you have to argue why you need it. Maybe you also need to evaluate it and some competing software. The next step is ordering it. If it is retail software you have to find a retailer that has the item on stock, otherwise you have to wait a few weeks. If you get the package by mail you need to wait a few days till the software arrives. And when you finally got the package and a colleague needs it too, you have to buy another license and everything starts from the beginning. (And I didnt even mention MS-style license audits, IT departments that want to manage all software licenses and so on).
Compare this to free software: download, install, work. In development departsments where people frequently need new software for their tasks the cost saving of free software is MUCH higher than only the license costs.
Things to consider when buying a laptop:
1. If you want to play (3D) games, make sure that you have a GeForce 2 Go chipset. It's the only one that allows you to play newer games at decent framerates
2. For Linux you should check whether your built-in modem is supported
3. Integrated WaveLan/WiFi is a cool feature if you know other people who have it, much better than an external PCMCIA card
4. If you want to use external drives (CD burner, faster harddisks (Laptops harddisks are slooow)), make sure you have a FireWire/iLink/ieee1394 port
5. built-in ethernet is always a useful feature
Some people claim this is what gives C# better performance. I'm not convinced.
The most important difference is that you cannot load any classes dynamically. AFAIK this is not possible in
I don't know how they describe it in the specification, but there is so-called meta-data in each assembly (the equivalent to a jar). This meta-data describes the classes, methods and so on.
Microsoft has promised to put C# and the virtual machine through the ECMA process. However, if most C# developers come from the Win32 background and heavily use libraries such as ASP.net, WebForms, ADO.net then how will those applications be portable?
You see it more from the compatibility-side than I do. I like C#, the CLR concept, the base libraries and that's it. I want some nice KDE-libraries for the CLR so I can write my KDE software in C# and/or Python. The possibility of executing Windows-software is only a side-effect for me. There will probably some company like Ximian doing it if there is a market for it, but I don't care too much about this. If MS starts making incompatible changes that's bad, but doesn't really affect my software.
You said you rarely need to use pointers yourself. I agree. And when I do, I don't want to do it inside the virtual machine and compromise it's stability or security. For any system programming I will use C.
But then you have whole categories of software that cannot be run by your VM, for example every piece of software that uses signal processing (video/sound stuff), probably also games. You cant get platform independent if you still have to use native code for 20% of the applications, even if only 1% of their code is native.
Beside that, using native code does certainly not improve your stability or security as long as it runs in the VM's process. The only secure way is to have it in a single process, and you can have that without native code, too.
Adaptive optimization of HotSpot really does make a difference in many cases.
The reason for all the complicated adaptive optimization stuff is the bad design (performance-wise) of the bytecode. Because in OO-software most methods are very small the best way to optimize a program is by inlining. Hotspot does exactly that. But because in Java every method is virtual (unlike CLR) and you can load new classes that override methods from existing ones at every time doing this is dangerous, and you may have to redo the inlining after you load a new class. This is quite a complicated and expensive process, so Sun tries to avoid for most methods it by making it adaptive.
They created a monster because their bytecode is a little bit too flexible. In the CLR this is not neccessary. You can even pre-compile your assemblies if you want to.
Yes, but you can use QT, but can you use all the KDE/Gnome libraries?
This does already exist, see this /. discussion about LBX&RX. It is included in XFree 4, unfortunately no one uses it.
It solves many problems of the current systems:
- you have a single API for all programming languages (which
admittedly all get quite similar because they all have to support various
OO-features, exceptions and so on). Currently it is only theoretical
possible to program for Gnome or KDE in a scripting language. In reality you
will get only half of the APIs and it means a lot of trouble for the end
user.
.net also comes with a unified format for things like API
documentation (that is written in XML and generated by the compiler itself).
- You dont have trouble any more if you use a non-x86 platform. This could
bring real freedom in the platform choice.
- Things like buffer overflows will be very rare (they are still possible
because you can use pointers, but you rarely have to use them and your code
is marked as insecure).
I think it is desirable to have something like this, and if MS releases the specs for it and you get some interoperability for free this is a good opportunity. Even the design of the CLR (Common language runtime) alone is such a huge effort that the free software community just saves much time by adopting it. And the base library looks very nice, they even have unix-like things in it, for example support for perl-style regular expressions. Something that is still missing in the Java (even if they announced regex support for a future release)... Speaking of Java, I dont think that it is an alternative:- It is definitely not more 'free' than the
.net stuff (if MS really
submits the specs to ECMA)
- The JavaVM is quite limited to Java as language. Yes, there are other
languages for the JavaVM, but the VM isnt really flexible enough and you
dont have things like pointers available which you need for system
programming.
- Java's performance sucks because of several design mistakes (ok, they
are only mistakes if you see it from a performance point-of-view, you could
also argue that Java's design is cleaner). MS got several things right that
cause the bad performance of object-oriented Java projects:
- they do
not make every method virtual
- there is an alternative to heap-allocated
and garbage-collected objects (small objects can be allocated on the stack
and are passed-by-copy)
- they made some restriction into their IL (intermediate language) that
Java's bytecode doesnt have and result in faster/easier code generation.
Both are stack-oriented, but in IL the stack must have the same depth at
every jump-point
Of course, there are also ugly parts inI can understand him somehow as I have similar feelings about a german system called Fischer Technik that has almost disappeared from german toy stores in the last 10 years. While not as complicated as Meccano (no screws and stuff) the constructions were more stable, the motors bigger...
In other words, Fischer Technik allowed you to build larger and more complex things (after all the first sets were made for industrial models, and that's what it is still used for today). It also pioneered many things that Lego had done only years later: sets for pneumatic, electronic circuits and a programmable computer interface.
IMHO C++ is no language that is easy to learn, but if you are are writing software 40 hours a week you will soon appreciate its large feature set (and maybe even the compact syntax). Java's lack of features like templates/generic programming, macros or multiple inheritance has both advantages and disadvantages. The advantage is that the language is small, easy to learn and it does not have any features that an inexperienced or tasteless programmer can misuse.
The disadvantage is the lack of expressive power resulting of this. Basically Java encourages Cut&Paste programming, which is a maintanance nightmare, a major error source and the root of all evil.
In Java you cannot write something once and then use it for different types, so you start copying the code and modify it slightly for each type. In C++ you can write it once and use templates.
The same problem is code that repeats itself only with slight variations that cannot be expressed with functions. This mostly occurs in regression tests, and can easily done with macros in C++. In Java you will start to copy&paste...
When people need multiple inheritance with several non-abstract classes in Java they start to implement an interface and copy&paste the code. Sometimes this is also done using a code-preprocessor, like some CORBA implementations did. In C++ you just multiple inheritance.
As I see it, University (College) is about education not about industrial training. You shouldn't be taught specific tools at university rather you should be taught theory.
Many people see it this way, and I can understand it to a certain degree. But you should also consider that learning a programming language to a level where you are REALLY productive and wont regret what your wrote 6 months later takes years. I think I reached this point in Java after 1-2 years (fulltime programming), C++ probably needs much longer - I cannot claim that I reached this point.