"Plenty of businesses still own and run old hardware - it still works so why upgrade."
I'm sure that's true, but I doubt that the kind of business that uses old hardware is also the kind that does a lot of document interchange with others. It's probably been using the same non-FOSS word processor for a long time.
You may be saying this in the context of large FOSS projects, but for most projects, not allowing all the team members to commit changes seems like a really bad idea. If you don't trust them, why are they on your team?
Complaining about the occasional inefficiencies of file locking while forcing some developers to waste time waiting for permission to commit, seems really ironic to me.
If you have a project that has thousands of developers all of the world like Linux does, a SCM system that is focused on merging makes a lot of sense. Unfortunately, there is a tendency for some people to overdo merging on small projects when they don't really need to. If the application is designed in a modular fashion and developers are assigned specific modules, than merging is rarely needed. Of course, many control freaks don't like this approach because it makes it harder for them to "correct" other developer's code.
Gee, and I thought one of the big arguments in favor of the GPL was that the code would be available forever. How can it not be available at the time the vouchers are exercised if it's available forever?
As has been mentioned before, the legal argument over vouchers is mostly speculation. A court might very well rule that the expiration date is irrelevant and that MS is bound to the legal conditions at the time the deal was made, not the time that the vouchers were exercised.
The problem with your scenario is that IBM and MS probably have patent agreements that include things like FAT. So if MS sues Acme Devices over FAT, IBM doesn't care.
Intel and AMD have been coasting for a decade by making very modest performance improvements based on a technology they've known is reaching its limits. Multicore may turn out to be a short-term transitional approach until new technologies are developed that allow a return to true performance gains. Given how long MS takes to develop a new OS, they may release it just as multicore goes the way of other kludges like extended memory.
One would hope that most variables of types covered by HN (i.e. basic types, not classes) would be used within a short distance of their definition assuming modules/classes are of reasonable size and the application isn't using many global variables.
In practice, I don't think the lack of HN is going to have much impact on maintenance efforts. You should also consider that the HN name may be wrong, so you can't be sure of the type just by looking at the name.
The biggest problem with HN is the coupling of names and types. The most famous example is probably Windows Message parameters. In 16 bit Windows there were 2 types of parameters you could pass in a message: WPARAM which was properly named because it was a 16 bit value and LPARAM which was a 32 bit value.
When Windows was upgraded to 32 bits, all native types were 32 bits in size, so the "W" in WPARAM was superfluous and the "L" in LPARAM was incorrect. Rather than update all of their code and documentation to make it HN compliant they wisely decided to ignore the issue and live with inconsistent names.
I'm not sure I'd agree that your use matches either 11 or 9, but that's not really the point. Definitions of error "handling" that aren't relevant to the issue of making applications more robust I don't find very useful in comparing languages. The fact is that there's no compelling argument or real evidence that checked exceptions result in higher quality code than not using them.
My problem is with the claim that Java forces you do handle errors, which it does not. I don't blame Sun for not being to solve this problem (nobody else has), but I do have a problem with misrepresentation.
Perhaps the compiler should force you to write a short summary of each function's purpose, parameters, and return type. Otherwise you have no way of knowing, apart from looking at source code or documentation, what the function might do.
Seriously, if a compiler were capable of informing you that you haven't handled an exception properly, that would be great, but that's not what Java does. It merely looks to see if you appear to be handling it or that you've passed it up the call chain. For most GUI applications, 90% of the exceptions should be handled at the "top", so you have to add boiler-plate code all over the place to keep the compiler happy. Then if Sun adds or removes an exception from an existing library, all the code that is in the call chain is broken.
If refactoring can reveal intent than either there's a lot more refactoring possibilities than I ever imagined or the set of possible intents is surprisingly small.
If you're going to say something ironic about MS and clones, don't use WordPerfect or Lotus123 as examples. They're no more original than Word or Excel.
The core issue is patents. Under the agreement, MS has agreed not to sue Novell's customers for using Novell's distro even if it includes software they believe violates MS patents. But MS excludes "clone" products from this protection.
So MS isn't going to sue anyone simply for cloning, but for violating patents.
I think Wine's best defense is to demonstrate a dozen Windows applications that won't run properly under Wine. Given there are thousands to chose from, they shouldn't be hard to find.
No. They can still sue the crap out of Novell for any product if they believe it violates their patents. It's the customers who won't be sued in some cases. We've been talking about this for months, we do we still have to explain this distinction between the companies and the customers at this late date?
Try running X windows on a 8088 processor with 256KB of RAM and no hard disk and get back to us. In any case, X was created by MIT, not by AT&T, so there's no core UNIX intellectual property issue there. In addition, the only unique technological feature that X contributed was network transparency, which Windows 1.0 didn't implement, so it could hardly be a clone.
Slashdot Mirror
have anything to do with cracks in the G4 cube?
"Plenty of businesses still own and run old hardware - it still works so why upgrade."
I'm sure that's true, but I doubt that the kind of business that uses old hardware is also the kind that does a lot of document interchange with others. It's probably been using the same non-FOSS word processor for a long time.
You may be saying this in the context of large FOSS projects, but for most projects, not allowing all the team members to commit changes seems like a really bad idea. If you don't trust them, why are they on your team?
Complaining about the occasional inefficiencies of file locking while forcing some developers to waste time waiting for permission to commit, seems really ironic to me.
If you have a project that has thousands of developers all of the world like Linux does, a SCM system that is focused on merging makes a lot of sense. Unfortunately, there is a tendency for some people to overdo merging on small projects when they don't really need to. If the application is designed in a modular fashion and developers are assigned specific modules, than merging is rarely needed. Of course, many control freaks don't like this approach because it makes it harder for them to "correct" other developer's code.
Gee, and I thought one of the big arguments in favor of the GPL was that the code would be available forever. How can it not be available at the time the vouchers are exercised if it's available forever?
As has been mentioned before, the legal argument over vouchers is mostly speculation. A court might very well rule that the expiration date is irrelevant and that MS is bound to the legal conditions at the time the deal was made, not the time that the vouchers were exercised.
The problem with your scenario is that IBM and MS probably have patent agreements that include things like FAT. So if MS sues Acme Devices over FAT, IBM doesn't care.
How do you define "fantastically fast"? 2x, 3x, 4x as fast as the prior design?
It's hard to believe because it isn't true. Windows supported multiprocessors since NT.
Intel and AMD have been coasting for a decade by making very modest performance improvements based on a technology they've known is reaching its limits. Multicore may turn out to be a short-term transitional approach until new technologies are developed that allow a return to true performance gains. Given how long MS takes to develop a new OS, they may release it just as multicore goes the way of other kludges like extended memory.
"I would like to know when changes are made to the API such that an exception would be thrown so that I could at least handle it correctly."
And you think getting a compile errors is the way to figure that out?
"As it stands with VB, you have no way of knowing which exceptions are to be thrown.."
Of course you can, it's documented. How do you know what any method does if you're not checking the documentation?
One would hope that most variables of types covered by HN (i.e. basic types, not classes) would be used within a short distance of their definition assuming modules/classes are of reasonable size and the application isn't using many global variables.
In practice, I don't think the lack of HN is going to have much impact on maintenance efforts. You should also consider that the HN name may be wrong, so you can't be sure of the type just by looking at the name.
The biggest problem with HN is the coupling of names and types. The most famous example is probably Windows Message parameters. In 16 bit Windows there were 2 types of parameters you could pass in a message: WPARAM which was properly named because it was a 16 bit value and LPARAM which was a 32 bit value.
When Windows was upgraded to 32 bits, all native types were 32 bits in size, so the "W" in WPARAM was superfluous and the "L" in LPARAM was incorrect. Rather than update all of their code and documentation to make it HN compliant they wisely decided to ignore the issue and live with inconsistent names.
I was being facetious. Everything (selfishness, altruism etc) is in the wild.
I'm not sure I'd agree that your use matches either 11 or 9, but that's not really the point. Definitions of error "handling" that aren't relevant to the issue of making applications more robust I don't find very useful in comparing languages. The fact is that there's no compelling argument or real evidence that checked exceptions result in higher quality code than not using them.
My problem is with the claim that Java forces you do handle errors, which it does not. I don't blame Sun for not being to solve this problem (nobody else has), but I do have a problem with misrepresentation.
And as I said, merely satisfying the compiler isn't handling the error, poorly or otherwise.
Perhaps the compiler should force you to write a short summary of each function's purpose, parameters, and return type. Otherwise you have no way of knowing, apart from looking at source code or documentation, what the function might do.
Seriously, if a compiler were capable of informing you that you haven't handled an exception properly, that would be great, but that's not what Java does. It merely looks to see if you appear to be handling it or that you've passed it up the call chain. For most GUI applications, 90% of the exceptions should be handled at the "top", so you have to add boiler-plate code all over the place to keep the compiler happy. Then if Sun adds or removes an exception from an existing library, all the code that is in the call chain is broken.
"Java has the advantage that it *makes* you handle your errors, even if you choose to do so poorly."
You must have a very weak definition of "handle". An empty catch block is not any kind of error handler, it's an exception hider.
If refactoring can reveal intent than either there's a lot more refactoring possibilities than I ever imagined or the set of possible intents is surprisingly small.
If you're going to say something ironic about MS and clones, don't use WordPerfect or Lotus123 as examples. They're no more original than Word or Excel.
The core issue is patents. Under the agreement, MS has agreed not to sue Novell's customers for using Novell's distro even if it includes software they believe violates MS patents. But MS excludes "clone" products from this protection.
So MS isn't going to sue anyone simply for cloning, but for violating patents.
I think Wine's best defense is to demonstrate a dozen Windows applications that won't run properly under Wine. Given there are thousands to chose from, they shouldn't be hard to find.
No. They can still sue the crap out of Novell for any product if they believe it violates their patents. It's the customers who won't be sued in some cases. We've been talking about this for months, we do we still have to explain this distinction between the companies and the customers at this late date?
Try running X windows on a 8088 processor with 256KB of RAM and no hard disk and get back to us. In any case, X was created by MIT, not by AT&T, so there's no core UNIX intellectual property issue there. In addition, the only unique technological feature that X contributed was network transparency, which Windows 1.0 didn't implement, so it could hardly be a clone.
Unfortunately, they're all working on their own individual version of a ground-breaking text editor and extensible platform that will eclipse Eclipse.