Ever wondered why slashdot has been looking the same for years? It's probably not because the owners don't want to change it but because their perl code base grew too ugly to change it radically.
Perl is good for shortlived projects (most websites change every few months). Since it is possible to produce code fast in perl it is ideal for the fast paced internet world where time to market is everything.
In an enterprise situation websites are complex, need to be reliable and contain lots of stuff that really does not change very much over time.
For such systems, you don't want to use ducktape type of languages like Perl. You want to use a language and development environment that helps you address these issues.
sigh, the old perl vs java debat again (zillionth time?).
"Since when do you need to have multiple server architectures run the same code?"
No vendor lock in. Ability to move your stuff to bigger platform should you need more horsepower. A
"PHP does that. Perl does that (I think.) Cold Fusion does that."
So, I bet you can list a number of other languages that can do that as well.
"Java IS slow. I'm on a AMD K6-2 350 and a Java Hello World took about 3 seconds to respond to a "destroy" request. Most programs take around 1 second. A slightly larger program is slow enough to be unusable."
So, buy some decent hardware, get the right JVM (and OS) and make sure you have enough memory (128 should be enough). Since we are talking webservers here there really is no excuse for crappy hardware and outdated software. Probably development/maintenance cost is much higher than the cost of the needed hardware for a website of decent size.
I worked with Java years ago on 66 Mhz HP-UX machines. I once managed to load and run the corel office demo on it. That was slow (and ugly). But hey, we are talking about a really crappy port of a 1.02 jvm here. I'm currently running JDK 1.3 Beta on my computer at work (PII350, 192 MB, winnt) and rarely have performance problems running such programs as TogetherJ, Forte and JBuilder.
For an OS developed by a relatively small company like BE, it sure is fast and stable. I've had it boot in 11 seconds on my pentium III 500 (correctly recognizing my voodoo 3 and turtle beach montego as well as my network card). All I had to tweak was the display resolution since it did not automatically recognize my pnp monitor.
The main issues with BEOS right now are lack of software and poor hardware support (luckily no problems for me though), otherwise it has everything I would like in an OS. If there would be a usable web browser on it I might consider using it on a more regular basis. Also I'd like to see proper Java support on it. My impression is that Java could run really well on this OS due to thread friendly nature of BEOS.
"First off you've got to determine what language the end user wants to view the site with. This can be done multiple ways: client hostname, browser version (language), server hostname (ie. japan.bigcorp.com), or by hitting a button or link on the page."
client/server hostname is a bad idea. I'm dutch but I live in sweden and when I visit www.lycos.com, I'm presented with the swedish version of this site. My browser settings are ignored (favors dutch above english and english above swedish). As a consequence I don't use lycos anymore. There is of course the alternative link which I can click to get the dutch or english version but that's too much trouble for me.
The best way I think is to just ask the user what language he/she prefers. Even if english is not your native language, it sometimes is the best option since the english version of a site is updated more often.
Trust me, it's more than 90%. In fact you just have to look at the numbers of processors sold to realize that the PC market is only a tiny piece of it -> most software does not run on PC's.
I think you are wrong about Java not replacing C. C right now is used for low level OS stuff and device drivers and of course embedded machines. right now C is being replaced with C++ in most of these areas. The embedded machine domain is subject to Moore's law so with some delay the same developments as on larger computers take place there. Time to market and C are a bad combination, so other languages will find their way there if chips get fast enough.
There's only one problem, many applications require root permissions for installation. So during installation of software, the virus can do it's thing.
But even without root permission a rm -rf on the user's home directory can be pretty annoying.
As the article noted however, replication is the real obstacle for a linux virus. Most linux users either install from CD or download from a well known ftp site. It is quite uncommon to mail somebody a rpm with a cool application (which would be the equivalent of sending an.exe file to someone under windows).
mozilla is the entire browser (mail, news, GUI, browser). Gecko is the component that does the actual browsing (displaying HTML, executing javascripts etc.). The html rendering component can be embedded in other environments, even IE would be no problem.
Actually, the latest incarnation of office uses a single document interface. MDI becomes confusing when you have more than a handfull of windows.
There's another reason why having a single menubar is better: you save screen space. Normally each open window wastes some space on the menubar, even though only one window can be active at the time. Moving the menu's to a single place solves this.
It's exactly this that is the bottomline. System administrators like linux not because it is good for their users but because it is good for them. In my opinion system administrators have way too much power in organizations right now. I don't want a maintenance mechanic to decide what a user should and shouldn't run. Linux is immature, has a lousy inconsistent GUI which is at best a rip off of the much hated MS windows. There's little hardware support and the few desktop applications available are all rip offs of popular apple and windows applications.
I recently installed linux (corel and redhat) on my machine and I must say I'm impressed by the smooth intstallation. Otherwise I'm not much impressed. Corel just hides the complexity of the OS behind a thin layer of nice looking widgets and redhat doesn't even bother to do so.
There's this guy on slashdot who uses the following signature: "people who don't understand UNIX are doomed to reinvent it poorly"
Replace UNIX by windows and you have the reason why linux is not ready for the desktop.
Of course having a separate DTD for each program is silly. But recognizing that a lot of configuration files actually look quite similar allows you to standardize on a particular DTD for a whole class of programs.
All apple did was bring some uniformity in the mess of anarchistic shell scripts. Uniformity is good for two reasons: It makes things easier to understand and it makes things more general.
Understandability is good because that lowers training cost and generality is good because that makes it possible to reuse (parsers, tools and even settings).
Aside from uniformity they also applied separation of concern. They removed hardcoded interdependencies between shell scripts. Unlike uniformity this improves flexibility.
All apple is doing here is apply good software engineering principles (uniform behavior, separation of concern). The unix community should be asshamed that they need apple to point that out. After all unix has been around for some time.
In Java, keeping a resource for the entire lifetime of an object is bad programming style since you cannot know for sure when the object is going to be destroyed or even when it gets out of scope (potentially a long time). That's why it would be bad style in Java to release resources in the destructor (you needlessly occupy resources).
You are probably right about C++. Though I know some of the language I never bothered programming in it. I learned C when I studied at the university and I've seen a host of other languages as well (some very exotic). Anyway judging from your post you misunderstand Java as least as much as I misunderstood C++.
I don't see how the destructor mechanism guarantees anything since you still have to make sure it is called yourself. Rather I think that this is a major source for bugs in C++ (people forgetting to destroy an object or doing it too early).
In Java it is typically a bad idea to release resources late (since A you don't know when the object will be destroyed and B you probably don't need the resource throughout the lifetime of an object. The try catch finally mechanism provides a great replacement since this captures the notion that using a resource is a bit like a trans action: book the resource, do your thing, handle possible errors, release the resource.
The only problem that I detect here is that someone is trying to do C++ style programming in Java. While it works it is probably a better idea to adopt the java style.
I think differences in programming style between Java and C++ are one of the reasons so many C++ to java porting projects fail. It's just sub optimal to program Java in a C++ style.
I'm not sure I follow you on the subject of "resource leaking". I never experienced any problems in that area. Obviously you are unaware of the finalize method you can declare to do exactly what you want. The whole point of garbage collecting is that you don't need to worry about it. As a consequence you don't control when an object is destroyed. Rather it becomes eligible for destructions when there are no references to it anymore. A manual destruction would make java unsafe since you no longer can enforce that objects need to be unreferenced before destruction. BTW you can tell the garbage collector to collect the garbage when you need to do so but usually it is a better idea to let the garbage collector figure out a suitable moment to do so.
I didn't know about the namespaces construct. I don't think it is exactly the same from what you said here.
Abstract classes can indeed be used to imitate java interfaces. Yet there is a subtle difference: abstract classes may contain implementation whereas interfaces do not contain any implementation. This explicit separation between interface and implementation is very usefull. C++ can provide a similar mechanism (with a small performance hit) but does not enforce the separation.
I protest against your qualification of Java as a 'dumbed down' language. I think it is a very smartly designed and elegant language.
Neither are standard, meaning that applications written for one are not written for the other.
Interoperability is not the point here but uniformity is. It is easy to copy the good looks of apple but it is very hard to copy its uniformity. Uniformity makes a system easy to use since you can reuse knowledge about using one program in another one.
Having and enforcing user interface guidelines is the only alternative to having a single source for all your programs if you want to achieve uniformity. Both KDE and Gnome are trying to do the latter by providing all sort of apps (I think there's even a browser component in KDE, where have we seen this before?).
The lack of standards in this area will maintain the status quo of non uniformity of applications for linux. Some will work better on Gnome, others will integrate better with KDE, some will ignore either and some will try to be compatible with both (thus limiting themselves to what is implemented in both).
So the user inteface for linux is doomed to be a wannabee MAC/Windows rip off. It may aquire the looks but is currently far from adopting the same uniformity.
If you look back in this interview, you'll notice that bjarne has very clear ideas about how multiple inheritance should be used. If you compare that to what Java supports you'll find that it actually supports this type of usage (namely multiple inheritance of interfaces). The problem with C++ is that it has no first class representation of interfaces (which is why you need multiple inheritance of classes to imitate this feature). Java has support for interfaces built into the language so it can prevent people like you shooting theirselves and the companies they work for in the foot by abusing MI. If you are still sceptical about this, I would like to point out that there have been empirical studies about the use of multiple inheritance and these studies make it pretty clear that the use of MI for inheriting code is a bad idea in most cases.
I don't really see the point of having operator overloading. The advantage of being able to overload them is fully consumed by the resulting confusing code. I don't want my + operator to be overloaded. I don't want to work on code where I have to look up what the + operator actually means. If assumptions I have about such simple things as + and - no longer hold true I can't do my work properly.
My main problem with C++ is not that it lacks features but that provides to much of them. Java as a language is much simpler and the only problem I see with it is that it doesn't have support for templates yet. On the other hand there are many features in it that you only get in c++ if you are a skilled and disciplined programmer. Take for instance a simple concept: package. The package construct allows you to group classes into packages. Packages can be nested and the package is part of the class name (which makes it possible to have class names with the same name in different packages). Of course this simple feature can (and should) be imitated for large C++ projects but its just not as straight forward as in Java. Another feature is that Java assumes that your functions are virtual rather than static (as in C++). C++ obviously can't do this without breaking compatibility with C so OO programmers are doomed to type virtual in front of every method they declare. Another thing is the C compatibility. I don't see the point of it. True, in isolated situations it may be handy to be able to quickly port old C code (but then why not redesign it while you are at it?). In most situations though you are better of resuing the old code base in the form of libraries (as you do in Java with native methods).
These little, well designed language features make life easy for a programmer. And that's exactly what a language should do. C++ programmers always complain about lack of features in Java but this is in sharp contradiction with actual productivity of programmers using C++ and Java.
Also the fact that C++ is so close to C prevents it from doing certain optimizations (according to Bjarne in this interview). I'm not in favor of a one size fits all language. Especially if that means making compromises all over the place. C++ is one big compromise towards C compatibility and performance. In many projects C compatibility is not essential or even redundant and performance is not the primary quality requirement. C++ therefore is not the most suitable language for this growing category of projects.
In many cases using C++ makes your programs needlessly complex and confuses the programmers. True, if you no what you are doing it can be a handy tool but unfortunately many programmers are not in that position.
In the interview I noticed some frustration with the fact that there are still hordes of programmers using C (for non valid reasons). I feel a similar frustration towards the use of C++ and Java. True there have been and there are performance problems with Java. But just like most of these issues resolved with C++, most current issues with java will be resolved over time.
"All reduce code, and is fast. I mean, who the hell would write a function to construct a DWORD from two WORDs - or a function to check MAX and MIN? You either have to resort to a function, or *ugh* maunally do it every time you need to. "
What's against using a function? You can let it inline if performance is an issue. Functions are typechecked an checked for syntax errors. Macros are not type checked or syntax checked (at least not until the're expanded by the preprocessor after which it is no longer possible to pinpoint their location in the sourcecode).
Contrary to what you are thinking I think this way of using macros illustrates exactly the main problem with using macros. You make your code unreadable by using macros (where you could have used fucntions instead). You break encapsulation by letting your macros use private variables (why the hell did you make them private anyway). And finally you use them to prevent copy/paste style reuse (which makes me wonder if you could design your code to be more reusable).
Macros are a nightmare if you have to do maintenance on code. The fact that they are usefull in C++ only shows that pure C++ is too limited for ordinary use, which BTW was the reason for asking the guy who created C++ what he thinks is missing from the language or could be done better.
a car driving on hydrogen with the same range as a normal car has a tank of 100 litres (very rough number based on a vague memory of something I read on this once). Of course the gas is stored under pressure (5 bar??) so lets assume we are talking about 500 litres H2 for a full tank.
given 0.333 litre of H2/litre alge/10 days, that gives you aproximately 1600 litres of alge to produce that amount of H2 in 10 days or 16000 to do it in one day. But given the 10 fold increase those people think is feasible in the yields we'll assume 1600 litre for 500 litre of H2 per 10 days.
The real question of course is how much litre of alge you can get to produce H2 per square metre of sunlight (i.e. how deep can the tanks be).
From this I conclude that the only purpose for macros is to cover up for language deficiencies. That is, you generally solve things with it that were apparently not easy to fix using pure C++.
Right now Java does not have templates. However there is a proposal to add parametrized classes to the language. Probably this feature will at some time be added to the language. From what I've understood SUN puts the following requirements on such an extension: it should be backwards compatible (both source and bytecode) and it should be usefull enough to justify the added language complexity. As I understood, the template feature in C++ is far from perfect. In fact SUN would probably opt out on a similar to C++ template feature in Java.
.. and would ignore backwards compatibility with C, would the resulting language resemble C++? It seems to me (I mainly do Java) that a lot of language features in C++ are less then optimal and heavily biased to performance rather than usability. Templates come to mind but also such things as macros (eeeww).
I hope you won't put this question aside like you do with most question asking you to compare C++ with <fill in your language here>. While I imagine that the latter type of question must have become a boring one for you, the fact remains that C++ is now more than 20 years old and other languages might exist that address some domains at which C++ was once targeted, better. So rather than asking you to do that I would like you to describe what a modern language should be able to do compared to C++.
I followed your link and you are right, towerj is on top. But what does that say really? IBM is a very close second and they don't compile to native code. Above all, this version of IBM's VM runs on NT and towerj runs on linux.
A closer examination of this benchmarks reveals that it tests socket IO and threads. The performance of both is very much dependend on the OS.
Furthermore, I think a benchmark that stresses the OO usage of Java a little more (i.e. creating destroying objects) would show a different picture.
This benchmark does not proof much to me. A benchmark that doesn't take typical OO behavior of a program into account is not realistic, even for server side programs.
Slashdot Mirror
Ever wondered why slashdot has been looking the same for years? It's probably not because the owners don't want to change it but because their perl code base grew too ugly to change it radically.
Perl is good for shortlived projects (most websites change every few months). Since it is possible to produce code fast in perl it is ideal for the fast paced internet world where time to market is everything.
In an enterprise situation websites are complex, need to be reliable and contain lots of stuff that really does not change very much over time.
For such systems, you don't want to use ducktape type of languages like Perl. You want to use a language and development environment that helps you address these issues.
sigh, the old perl vs java debat again (zillionth time?).
"Since when do you need to have multiple server architectures run the same code?"
No vendor lock in. Ability to move your stuff to bigger platform should you need more horsepower. A
"PHP does that. Perl does that (I think.) Cold Fusion does that."
So, I bet you can list a number of other languages that can do that as well.
"Java IS slow. I'm on a AMD K6-2 350 and a Java Hello World took about 3 seconds to respond to a "destroy" request. Most programs take around 1 second. A slightly larger program is slow enough to be unusable."
So, buy some decent hardware, get the right JVM (and OS) and make sure you have enough memory (128 should be enough). Since we are talking webservers here there really is no excuse for crappy hardware and outdated software. Probably development/maintenance cost is much higher than the cost of the needed hardware for a website of decent size.
I worked with Java years ago on 66 Mhz HP-UX machines. I once managed to load and run the corel office demo on it. That was slow (and ugly). But hey, we are talking about a really crappy port of a 1.02 jvm here. I'm currently running JDK 1.3 Beta on my computer at work (PII350, 192 MB, winnt) and rarely have performance problems running such programs as TogetherJ, Forte and JBuilder.
For an OS developed by a relatively small company like BE, it sure is fast and stable. I've had it boot in 11 seconds on my pentium III 500 (correctly recognizing my voodoo 3 and turtle beach montego as well as my network card). All I had to tweak was the display resolution since it did not automatically recognize my pnp monitor.
The main issues with BEOS right now are lack of software and poor hardware support (luckily no problems for me though), otherwise it has everything I would like in an OS. If there would be a usable web browser on it I might consider using it on a more regular basis. Also I'd like to see proper Java support on it. My impression is that Java could run really well on this OS due to thread friendly nature of BEOS.
"First off you've got to determine what language the end user wants to view the site with. This can be done multiple ways: client hostname, browser version (language), server hostname (ie. japan.bigcorp.com), or by hitting a button or link on the page."
client/server hostname is a bad idea. I'm dutch but I live in sweden and when I visit www.lycos.com, I'm presented with the swedish version of this site. My browser settings are ignored (favors dutch above english and english above swedish). As a consequence I don't use lycos anymore. There is of course the alternative link which I can click to get the dutch or english version but that's too much trouble for me.
The best way I think is to just ask the user what language he/she prefers. Even if english is not your native language, it sometimes is the best option since the english version of a site is updated more often.
Trust me, it's more than 90%. In fact you just have to look at the numbers of processors sold to realize that the PC market is only a tiny piece of it -> most software does not run on PC's.
I think you are wrong about Java not replacing C. C right now is used for low level OS stuff and device drivers and of course embedded machines. right now C is being replaced with C++ in most of these areas. The embedded machine domain is subject to Moore's law so with some delay the same developments as on larger computers take place there. Time to market and C are a bad combination, so other languages will find their way there if chips get fast enough.
There's only one problem, many applications require root permissions for installation. So during installation of software, the virus can do it's thing.
.exe file to someone under windows).
But even without root permission a rm -rf on the user's home directory can be pretty annoying.
As the article noted however, replication is the real obstacle for a linux virus. Most linux users either install from CD or download from a well known ftp site. It is quite uncommon to mail somebody a rpm with a cool application (which would be the equivalent of sending an
Sorry, I'm not an expert. Probably you can plug them in if you write some wrapper for it.
mozilla is the entire browser (mail, news, GUI, browser). Gecko is the component that does the actual browsing (displaying HTML, executing javascripts etc.). The html rendering component can be embedded in other environments, even IE would be no problem.
Actually, the latest incarnation of office uses a single document interface. MDI becomes confusing when you have more than a handfull of windows.
There's another reason why having a single menubar is better: you save screen space. Normally each open window wastes some space on the menubar, even though only one window can be active at the time. Moving the menu's to a single place solves this.
The IDE will work with other VMs than those coming from SUN as well. Try blackdown if you have to stay clear from non open source stuff.
It's exactly this that is the bottomline. System administrators like linux not because it is good for their users but because it is good for them. In my opinion system administrators have way too much power in organizations right now. I don't want a maintenance mechanic to decide what a user should and shouldn't run. Linux is immature, has a lousy inconsistent GUI which is at best a rip off of the much hated MS windows. There's little hardware support and the few desktop applications available are all rip offs of popular apple and windows applications.
I recently installed linux (corel and redhat) on my machine and I must say I'm impressed by the smooth intstallation. Otherwise I'm not much impressed. Corel just hides the complexity of the OS behind a thin layer of nice looking widgets and redhat doesn't even bother to do so.
There's this guy on slashdot who uses the following signature:
"people who don't understand UNIX are doomed to reinvent it poorly"
Replace UNIX by windows and you have the reason why linux is not ready for the desktop.
Of course having a separate DTD for each program is silly. But recognizing that a lot of configuration files actually look quite similar allows you to standardize on a particular DTD for a whole class of programs.
All apple did was bring some uniformity in the mess of anarchistic shell scripts. Uniformity is good for two reasons: It makes things easier to understand and it makes things more general.
Understandability is good because that lowers training cost and generality is good because that makes it possible to reuse (parsers, tools and even settings).
Aside from uniformity they also applied separation of concern. They removed hardcoded interdependencies between shell scripts. Unlike uniformity this improves flexibility.
All apple is doing here is apply good software engineering principles (uniform behavior, separation of concern). The unix community should be asshamed that they need apple to point that out. After all unix has been around for some time.
In Java, keeping a resource for the entire lifetime of an object is bad programming style since you cannot know for sure when the object is going to be destroyed or even when it gets out of scope (potentially a long time). That's why it would be bad style in Java to release resources in the destructor (you needlessly occupy resources).
You are probably right about C++. Though I know some of the language I never bothered programming in it. I learned C when I studied at the university and I've seen a host of other languages as well (some very exotic). Anyway judging from your post you misunderstand Java as least as much as I misunderstood C++.
I don't see how the destructor mechanism guarantees anything since you still have to make sure it is called yourself. Rather I think that this is a major source for bugs in C++ (people forgetting to destroy an object or doing it too early).
In Java it is typically a bad idea to release resources late (since A you don't know when the object will be destroyed and B you probably don't need the resource throughout the lifetime of an object. The try catch finally mechanism provides a great replacement since this captures the notion that using a resource is a bit like a trans action: book the resource, do your thing, handle possible errors, release the resource.
The only problem that I detect here is that someone is trying to do C++ style programming in Java. While it works it is probably a better idea to adopt the java style.
I think differences in programming style between Java and C++ are one of the reasons so many C++ to java porting projects fail. It's just sub optimal to program Java in a C++ style.
I'm not sure I follow you on the subject of "resource leaking". I never experienced any problems in that area. Obviously you are unaware of the finalize method you can declare to do exactly what you want. The whole point of garbage collecting is that you don't need to worry about it. As a consequence you don't control when an object is destroyed. Rather it becomes eligible for destructions when there are no references to it anymore. A manual destruction would make java unsafe since you no longer can enforce that objects need to be unreferenced before destruction. BTW you can tell the garbage collector to collect the garbage when you need to do so but usually it is a better idea to let the garbage collector figure out a suitable moment to do so.
I didn't know about the namespaces construct. I don't think it is exactly the same from what you said here.
Abstract classes can indeed be used to imitate java interfaces. Yet there is a subtle difference: abstract classes may contain implementation whereas interfaces do not contain any implementation. This explicit separation between interface and implementation is very usefull. C++ can provide a similar mechanism (with a small performance hit) but does not enforce the separation.
I protest against your qualification of Java as a 'dumbed down' language. I think it is a very smartly designed and elegant language.
Neither are standard, meaning that applications written for one are not written for the other.
Interoperability is not the point here but uniformity is. It is easy to copy the good looks of apple but it is very hard to copy its uniformity. Uniformity makes a system easy to use since you can reuse knowledge about using one program in another one.
Having and enforcing user interface guidelines is the only alternative to having a single source for all your programs if you want to achieve uniformity. Both KDE and Gnome are trying to do the latter by providing all sort of apps (I think there's even a browser component in KDE, where have we seen this before?).
The lack of standards in this area will maintain the status quo of non uniformity of applications for linux. Some will work better on Gnome, others will integrate better with KDE, some will ignore either and some will try to be compatible with both (thus limiting themselves to what is implemented in both).
So the user inteface for linux is doomed to be a wannabee MAC/Windows rip off. It may aquire the looks but is currently far from adopting the same uniformity.
If you look back in this interview, you'll notice that bjarne has very clear ideas about how multiple inheritance should be used. If you compare that to what Java supports you'll find that it actually supports this type of usage (namely multiple inheritance of interfaces). The problem with C++ is that it has no first class representation of interfaces (which is why you need multiple inheritance of classes to imitate this feature). Java has support for interfaces built into the language so it can prevent people like you shooting theirselves and the companies they work for in the foot by abusing MI. If you are still sceptical about this, I would like to point out that there have been empirical studies about the use of multiple inheritance and these studies make it pretty clear that the use of MI for inheriting code is a bad idea in most cases.
I don't really see the point of having operator overloading. The advantage of being able to overload them is fully consumed by the resulting confusing code. I don't want my + operator to be overloaded. I don't want to work on code where I have to look up what the + operator actually means. If assumptions I have about such simple things as + and - no longer hold true I can't do my work properly.
My main problem with C++ is not that it lacks features but that provides to much of them. Java as a language is much simpler and the only problem I see with it is that it doesn't have support for templates yet. On the other hand there are many features in it that you only get in c++ if you are a skilled and disciplined programmer. Take for instance a simple concept: package. The package construct allows you to group classes into packages. Packages can be nested and the package is part of the class name (which makes it possible to have class names with the same name in different packages). Of course this simple feature can (and should) be imitated for large C++ projects but its just not as straight forward as in Java. Another feature is that Java assumes that your functions are virtual rather than static (as in C++). C++ obviously can't do this without breaking compatibility with C so OO programmers are doomed to type virtual in front of every method they declare.
Another thing is the C compatibility. I don't see the point of it. True, in isolated situations it may be handy to be able to quickly port old C code (but then why not redesign it while you are at it?). In most situations though you are better of resuing the old code base in the form of libraries (as you do in Java with native methods).
These little, well designed language features make life easy for a programmer. And that's exactly what a language should do. C++ programmers always complain about lack of features in Java but this is in sharp contradiction with actual productivity of programmers using C++ and Java.
Also the fact that C++ is so close to C prevents it from doing certain optimizations (according to Bjarne in this interview). I'm not in favor of a one size fits all language. Especially if that means making compromises all over the place. C++ is one big compromise towards C compatibility and performance. In many projects C compatibility is not essential or even redundant and performance is not the primary quality requirement. C++ therefore is not the most suitable language for this growing category of projects.
In many cases using C++ makes your programs needlessly complex and confuses the programmers. True, if you no what you are doing it can be a handy tool but unfortunately many programmers are not in that position.
In the interview I noticed some frustration with the fact that there are still hordes of programmers using C (for non valid reasons). I feel a similar frustration towards the use of C++ and Java. True there have been and there are performance problems with Java. But just like most of these issues resolved with C++, most current issues with java will be resolved over time.
"All reduce code, and is fast. I mean, who the hell would write a function to construct a DWORD from two WORDs - or a function to check MAX and MIN? You either have to resort to a function, or *ugh* maunally do it every time you need to. "
What's against using a function? You can let it inline if performance is an issue. Functions are typechecked an checked for syntax errors. Macros are not type checked or syntax checked (at least not until the're expanded by the preprocessor after which it is no longer possible to pinpoint their location in the sourcecode).
Contrary to what you are thinking I think this way of using macros illustrates exactly the main problem with using macros. You make your code unreadable by using macros (where you could have used fucntions instead). You break encapsulation by letting your macros use private variables (why the hell did you make them private anyway). And finally you use them to prevent copy/paste style reuse (which makes me wonder if you could design your code to be more reusable).
Macros are a nightmare if you have to do maintenance on code. The fact that they are usefull in C++ only shows that pure C++ is too limited for ordinary use, which BTW was the reason for asking the guy who created C++ what he thinks is missing from the language or could be done better.
more calculation:
a car driving on hydrogen with the same range as a normal car has a tank of 100 litres (very rough number based on a vague memory of something I read on this once). Of course the gas is stored under pressure (5 bar??) so lets assume we are talking about 500 litres H2 for a full tank.
given 0.333 litre of H2/litre alge/10 days, that gives you aproximately 1600 litres of alge to produce that amount of H2 in 10 days or 16000 to do it in one day. But given the 10 fold increase those people think is feasible in the yields we'll assume 1600 litre for 500 litre of H2 per 10 days.
The real question of course is how much litre of alge you can get to produce H2 per square metre of sunlight (i.e. how deep can the tanks be).
From this I conclude that the only purpose for macros is to cover up for language deficiencies. That is, you generally solve things with it that were apparently not easy to fix using pure C++.
Right now Java does not have templates. However there is a proposal to add parametrized classes to the language. Probably this feature will at some time be added to the language. From what I've understood SUN puts the following requirements on such an extension: it should be backwards compatible (both source and bytecode) and it should be usefull enough to justify the added language complexity.
As I understood, the template feature in C++ is far from perfect. In fact SUN would probably opt out on a similar to C++ template feature in Java.
.. and would ignore backwards compatibility with C, would the resulting language resemble C++? It seems to me (I mainly do Java) that a lot of language features in C++ are less then optimal and heavily biased to performance rather than usability. Templates come to mind but also such things as macros (eeeww).
I hope you won't put this question aside like you do with most question asking you to compare C++ with <fill in your language here>. While I imagine that the latter type of question must have become a boring one for you, the fact remains that C++ is now more than 20 years old and other languages might exist that address some domains at which C++ was once targeted, better. So rather than asking you to do that I would like you to describe what a modern language should be able to do compared to C++.
I followed your link and you are right, towerj is on top. But what does that say really? IBM is a very close second and they don't compile to native code. Above all, this version of IBM's VM runs on NT and towerj runs on linux.
A closer examination of this benchmarks reveals that it tests socket IO and threads. The performance of both is very much dependend on the OS.
Furthermore, I think a benchmark that stresses the OO usage of Java a little more (i.e. creating destroying objects) would show a different picture.
This benchmark does not proof much to me. A benchmark that doesn't take typical OO behavior of a program into account is not realistic, even for server side programs.
With the coming mozilla version (beta in 60 days according to mozillazine), yes.