I think you'll find you are the naive one. Those are the same MySQL "experts" that claimed referential integrity was a waste of time, and should be implemented in application layer code. That is, until they had some semblance of support for it, although you were still screwed if you needed full text indexing on one of your tables.
Standardisation has brought little benefit to C++. If anything, it has codified bad ideas in such a way that they can't be fixed for backwards compatability reasons (see the adoption of the STL for the best example of this, where various areas were simply not well thought out at the time of standardisation). Java on the other hand is not standardised by a independent body, as you point out, but this has not prevented development of alternative implementations - your mention of MicroSoft being "lititgated out of the market" is a misrepresentation, as they deliberatetely set out to create a non-compatible version. As for D, it's fighting against an entrenched predecessor.
So is this the best of both worlds for all of us? Adobe can still sell Flash authoring software, while the need for their buggy plugin fades away. End users benefit from portability and (given Adobe's track record with the plugin) security perspective. There must be a catch.
I'm sure you already know this, but for the benefit of other readers, Windows NT used to run on PowerPC and Alpha processors. My first employer even had a DEC Alpha server that arrived with a test install of Windows NT on it - rapidly nuked in favour of Unix. I've heard credible rumours that MS also had NT running on Sparc processors at one point, but whether that was just the kernel or included the userland as well I don't know. Many articles about the design and implementation of the NT kernel mention that it is very portable, so this comes as no surprise.
[1] http://hgbook.red-bean.com/read/how-did-we-get-here.html
(look for the comment by Ben Collins-Sussman under the comparison of Mercurial and Subversion, where he acknowledges that SVN branching and merging is "complicated and buggy").
At work we switched from Subversion to Mercurial last year, after repeated difficulties merging branches back into the trunk with SVN. The "killer feature" of SVN over CVS was supposed to be the ability to move files and directories around without doing it by hand in the repository itself. However, the moment you start doing this in a branched repository - or worse still, delete files and directories - you're into a world of hurt. The guy who wrote the existing branch/merge support has acknowledged it's inadequate[1], while the remaining SVN developers have been promising to fix it in the next version, for about the last four or five major versions. Since switching to Mercurial, we have had a reasonably large branch that was reintegrated into trunk with none of the problems we had with SVN. We've found the tools at least as good as those available for SVN, with various team members using the Mercurial command line client, NetBeans plugin and TortoiseHg.
This statement is absurd. Do you happen to know what any C++ programmer must do in order to get all the methods in a class to be virtual? Well, he only needs to state that they are virtual.
You've obviously not worked on codebases where a class that has non-virtual methods that it would be elegant to override where declared non-virtual, and the source cannot be modified - be it because it's in a binary, or policy dictates that you can't modify existing code. This has happened all too often in my experience, as well as programmers thinking they've overridden a method, only to have the object unexpectedly "sliced" when referenced as a superclass type.
If by "performance" you mean noticeable lag on your regular GUI operations then your comment is reasonable.
That tired claim? Most Java code is server side anyway, and the only GUI lag I've seen is when long running callbacks hog the main thread - an issue in C and C++ based GUI toolkits as well.
Isn't Java getting on in years and in need of being replaced by something more modern?
So says you. I'd guess that you don't actually work as a programmer.
Speaking as someone who started his programming career using a mix of C and Perl, Java is a pretty good balance between a systems programming and scripting language. With the increased speed of both hardware and the JVM since Java first arrived, it's got to the point where I can rarely justify using a language like C or C++ on the grounds of performance. As for paradigms, Java's implementation of OO is so much better than C++ (methods always virtual for example) - it's just a shame that Java's generics were bolted on later in a less than ideal way. In the real world don't really see functional programming taking off, but even if it does, Scala may offer the best of both worlds.
Hit finance.yahoo.com for YHOO and they list over thirteen thousand employees (can't possibly be correct? what could they all be doing?)
The figure was something like 14,300 employees before the layoff, so that sounds about right. The reason for the high head count is that there is no effective project management, a sprawling codebase and (amongst the US programmers) no awareness or understanding of coding for multiple locales.
Oil deposits in the North sea have been propping up the British economy for decades now.
which has rather annoyed the Scots
Truth is, their policitians are quite happy with the current status quo, where most of the money comes from the rest of the UK to be largely spent as the Scottish parliament sees fit.
Well, as the alternative idiom in "pure" Java is about the same number of lines of code, why bother with either the non-public API or native code via JNI?
I have one rule about C++ complaints; I don't listen to them unless the person behind them indicate that they've actually read "The Design & Evolution".
Well I've read Bjarne's apology / justification, and take it from me, C++ is still awful.
Isn't Objective C only available on the closed-source, proprietary Apple operating system?
No. Although they are transitioning to LLVM, Apple use GCC just as NeXT did before them. Although most Linux distros probably don't install the Objective C frontend and runtime support library by default, I've yet to encounter a popular one that doesn't have the necessary packages in their repositories.
If you want to do signal handling, then you could use the "non-public" classes sun.misc.Signal and sun.misc.SignalHandler, which as far as I can tell haven't changed since their introduction. The problem if you do use them you will not have a "pure Java" applications, as these classes are not required to be in all implementations of the Java class libraries.
Tomcat makes no assumptions about the JDK it's running on - the issue is the quality and consistency of behaviour of OpenJDK versus the Sun or IBM JDK. The latter two do not have any issues running Tomcat (or NetBeans, Eclipse, etc), whereas OpenJDK does.
The common examples are things like signal handling, which are not exposed as public APIs since they are not present on all platforms Java is targeted at. The solution in this, and many other cases, is usually to use a different approach - for instance Tomcat listens on a port for shutdown requests rather than requiring a signal, and in Java programming terms this is no more complex than signal handling in C.
It [OpenJDK] already is a drop-in replacement [for Sun JDK], unless you're dealing with software that makes remarkably stupid assumptions about the JDK it's running on.
I assume Tomcat is "stupid" software then? It has issues running under OpenJDK. Many other Java applications also become unstable or unpredictable under OpenJDK - soi much so, that I wouldn't trust openJDK on any platform or for any application.
The uncompacted soil absorbs most of the water which previously remained standing on a thick, compacted and sludgy lake bottom. The soil has also raised the lake bed, which allows the water to drain off more easily into the denuded land surrounding the lake - soil which is less tightly bound together thanks to the increasing absence of deep rooted vegetation.
Slashdot Mirror
Not sure, but an episode of Dr Who was filmed at the Alexandra Palace transmitter.
I think you'll find you are the naive one. Those are the same MySQL "experts" that claimed referential integrity was a waste of time, and should be implemented in application layer code. That is, until they had some semblance of support for it, although you were still screwed if you needed full text indexing on one of your tables.
There is really no reason to use arrays in C++.
Err, how about for performance? Especially seeing as that's one of the supposed reasons for wanting to use C++ over a better^W simpler language.
Standardisation has brought little benefit to C++. If anything, it has codified bad ideas in such a way that they can't be fixed for backwards compatability reasons (see the adoption of the STL for the best example of this, where various areas were simply not well thought out at the time of standardisation). Java on the other hand is not standardised by a independent body, as you point out, but this has not prevented development of alternative implementations - your mention of MicroSoft being "lititgated out of the market" is a misrepresentation, as they deliberatetely set out to create a non-compatible version. As for D, it's fighting against an entrenched predecessor.
So is this the best of both worlds for all of us? Adobe can still sell Flash authoring software, while the need for their buggy plugin fades away. End users benefit from portability and (given Adobe's track record with the plugin) security perspective. There must be a catch.
$ tar xzvf linux-2.6.nn.tar.gz
$ tar xzvf linux-redhat-2.6.nn-02.tar.gz
$ diff -Naur linux-2.6.nn linux-2.6.nn-02 > redhat-02.patch
$ diff -U redhat-01.patch redhat-02.patch | more
Even though the Z80 is extremely primitive compared to PowerPC and POWER, it still has more instruction opcodes.
I'm sure you already know this, but for the benefit of other readers, Windows NT used to run on PowerPC and Alpha processors. My first employer even had a DEC Alpha server that arrived with a test install of Windows NT on it - rapidly nuked in favour of Unix. I've heard credible rumours that MS also had NT running on Sparc processors at one point, but whether that was just the kernel or included the userland as well I don't know. Many articles about the design and implementation of the NT kernel mention that it is very portable, so this comes as no surprise.
[1] http://hgbook.red-bean.com/read/how-did-we-get-here.html (look for the comment by Ben Collins-Sussman under the comparison of Mercurial and Subversion, where he acknowledges that SVN branching and merging is "complicated and buggy").
At work we switched from Subversion to Mercurial last year, after repeated difficulties merging branches back into the trunk with SVN. The "killer feature" of SVN over CVS was supposed to be the ability to move files and directories around without doing it by hand in the repository itself. However, the moment you start doing this in a branched repository - or worse still, delete files and directories - you're into a world of hurt. The guy who wrote the existing branch/merge support has acknowledged it's inadequate[1], while the remaining SVN developers have been promising to fix it in the next version, for about the last four or five major versions. Since switching to Mercurial, we have had a reasonably large branch that was reintegrated into trunk with none of the problems we had with SVN. We've found the tools at least as good as those available for SVN, with various team members using the Mercurial command line client, NetBeans plugin and TortoiseHg.
This statement is absurd. Do you happen to know what any C++ programmer must do in order to get all the methods in a class to be virtual? Well, he only needs to state that they are virtual.
You've obviously not worked on codebases where a class that has non-virtual methods that it would be elegant to override where declared non-virtual, and the source cannot be modified - be it because it's in a binary, or policy dictates that you can't modify existing code. This has happened all too often in my experience, as well as programmers thinking they've overridden a method, only to have the object unexpectedly "sliced" when referenced as a superclass type.
If by "performance" you mean noticeable lag on your regular GUI operations then your comment is reasonable.
That tired claim? Most Java code is server side anyway, and the only GUI lag I've seen is when long running callbacks hog the main thread - an issue in C and C++ based GUI toolkits as well.
Isn't Java getting on in years and in need of being replaced by something more modern?
So says you. I'd guess that you don't actually work as a programmer.
Speaking as someone who started his programming career using a mix of C and Perl, Java is a pretty good balance between a systems programming and scripting language. With the increased speed of both hardware and the JVM since Java first arrived, it's got to the point where I can rarely justify using a language like C or C++ on the grounds of performance. As for paradigms, Java's implementation of OO is so much better than C++ (methods always virtual for example) - it's just a shame that Java's generics were bolted on later in a less than ideal way. In the real world don't really see functional programming taking off, but even if it does, Scala may offer the best of both worlds.
Bwahahaha you think anyone who doesn't have an MBA gets a bonus??
At least when I worked there, the bonus was linked to your share options - and everyone got those.
Hit finance.yahoo.com for YHOO and they list over thirteen thousand employees (can't possibly be correct? what could they all be doing?)
The figure was something like 14,300 employees before the layoff, so that sounds about right. The reason for the high head count is that there is no effective project management, a sprawling codebase and (amongst the US programmers) no awareness or understanding of coding for multiple locales.
Oil deposits in the North sea have been propping up the British economy for decades now.
which has rather annoyed the Scots
Truth is, their policitians are quite happy with the current status quo, where most of the money comes from the rest of the UK to be largely spent as the Scottish parliament sees fit.
Well, as the alternative idiom in "pure" Java is about the same number of lines of code, why bother with either the non-public API or native code via JNI?
But which behavior?
Locking up, crashing. Those trivial kinds of things that don't happen with Sun or IBM JDKs. Nothing to do with using non-public APIs.
I have one rule about C++ complaints; I don't listen to them unless the person behind them indicate that they've actually read "The Design & Evolution".
Well I've read Bjarne's apology / justification, and take it from me, C++ is still awful.
Linux (the kernel) is written in C. Not C++.
Isn't Objective C only available on the closed-source, proprietary Apple operating system?
No. Although they are transitioning to LLVM, Apple use GCC just as NeXT did before them. Although most Linux distros probably don't install the Objective C frontend and runtime support library by default, I've yet to encounter a popular one that doesn't have the necessary packages in their repositories.
If you want to do signal handling, then you could use the "non-public" classes sun.misc.Signal and sun.misc.SignalHandler, which as far as I can tell haven't changed since their introduction. The problem if you do use them you will not have a "pure Java" applications, as these classes are not required to be in all implementations of the Java class libraries.
Tomcat makes no assumptions about the JDK it's running on - the issue is the quality and consistency of behaviour of OpenJDK versus the Sun or IBM JDK. The latter two do not have any issues running Tomcat (or NetBeans, Eclipse, etc), whereas OpenJDK does.
The common examples are things like signal handling, which are not exposed as public APIs since they are not present on all platforms Java is targeted at. The solution in this, and many other cases, is usually to use a different approach - for instance Tomcat listens on a port for shutdown requests rather than requiring a signal, and in Java programming terms this is no more complex than signal handling in C.
It [OpenJDK] already is a drop-in replacement [for Sun JDK], unless you're dealing with software that makes remarkably stupid assumptions about the JDK it's running on.
I assume Tomcat is "stupid" software then? It has issues running under OpenJDK. Many other Java applications also become unstable or unpredictable under OpenJDK - soi much so, that I wouldn't trust openJDK on any platform or for any application.
The uncompacted soil absorbs most of the water which previously remained standing on a thick, compacted and sludgy lake bottom. The soil has also raised the lake bed, which allows the water to drain off more easily into the denuded land surrounding the lake - soil which is less tightly bound together thanks to the increasing absence of deep rooted vegetation.