Well, according to you. Can you name a C coding style that according to you gives you significant gains over the standard K&R style? That's the question posed in the article. Could you fill out one of those forms at the end of the article? If so, here's a good place to do so.
To knock an argument because of its form is only valid if there are no important arguments for which the form is actually helpful. For example:
Premise 1. For chargeable things (cell phone, PDA, pager) there are only a few meaningful power ranges.
Premise 2. No one power connector is significantly better than the others.
Premise 3. It would be a good thing if there were one, or at worst a handful, of common power charging connectors.
Conclusion: It would be good to think of all chargeable things as falling into a few buckets and having a standard connector for each bucket so I don't have to buy a set of new adaptors for each different cell phone, etc., that I buy.
Aha! The same form, a good argument. Or do you like the connector conspiracy? If you do, here's another one:
Premise 1. For most Western European languages there are a finite set of useful symbols (letters, digits, punctuation).
Premise 2. No one common encoding of those (A = 1 vs. A = 63 vs. A = 31) is better than any other.
Premise 3. If there were one common character encoding it would make a lot of things simpler.
Conclusion: It would be good to think of all the computer-stored text in the world as members of a single class of files and have a standard encoding that we all follow.
Aha! The same form, and now we have ASCII trumping EBCDIC, which was a good thing. Or would you prefer if each group defined its own "better" cahracter mapping and we have a world of programs to translate between the common ones, have editors that can read ten or twenty or thirty styles, etc.? Think of all that effort! Couldn't it be better placed elsewhere. Isn't it better placed?
So you see, the argument form is fine, you just disagree with the weighting. Let's keep focused on your problem, shall we?
Most web sites ensure they work with IE. Many of these sites don't care much about other browsers.
This means that IE is the de facto standard of the web. If I go to a site that OmniWeb doesn't handle well (typically commercial sites), that's when I fire up IE on my Mac.
That's step one of the real threat. Step two is this: If IE doesn't run on the Mac, then there is no de facto standard browser on the Mac.
Step three: The Mac market is small enough that many of the mainstream sites may just not care. You know how much they care about Linux-based browsers right now.
Step four: With a seemingly flakey web experience, who besides the real die-hards would buy a Mac? This means that Apple is in a life-or-death race to be fully IE compatible.
Step five: Who controls what IE does? Do I even have to mention step five?
Checkmate.
Unless web sites chose to be more generally compatible and test with some Mac-based browser, they can easily and accidentally become incompatible with Macs. Currently they don't have to ask the question because Mac IE is almost the same as Windows IE. All they have to do is avoid ActiveX controls, which most do.
Yes, some will care to be careful. But many may not.
I agree that making a redundant close harmless works here. But another way to state the problem is that you still have to check for "write after close" problems. Which is true -- not all illegal things can be made impossible. But when they can, it's a good thing to do.
In this case it's not so bad because any write might fail, so you have to deal with failures anyway.
p7 - intro: Hmm... they contrast their method (persistent info) to menus (drop down, then disappear) & dialog
boxes (disappear after use). Menus get longer, dialogues more cluttered with greater info. Palettes will solve
this problem in user interface design.
Tear-off menus, anyone? Isn't a tear-off menu a vertical tabbed pane? Sure, it's not attached necessarily to the thing it's modifying, but the patent doesn't require that.
Isn't it a tad ironic? Here we have a language that's supposed to make it possible to write stuff that can be run anywhere, and you can't even read the spec on a non-Windows platform. (Well, of course you can if you hack around, but an.exe is pretty clueless.)
The user-level APIs are one thing. But if you can only use them with equipment you've specially constructed then there's a lot of the world that you can't interact with. Someone with voice recognition, for example, could use an ATM, but right now that requires an ATM that has a voice recognizer. If the ATM instead was looking for something that answered questions, you might have a VR system and I might have a keyboard wired to my wheelchair, with a CRT, but we can both answer questions. The ATM should be able to talk to either of us. Traditionally this is done via agreement on wire protocols, such as a standard XML DTD or a CORBA interface that translates into a particular set of IIOP bits. But that's very inflexible. The point of the Jini project is to allow agreement at the programming API level, and have each service (such as a question answering service) give the client (the ATM) code that executes the request. At least that's my view of interfaces for the handicapped. Otherwise your friend can get things working inside his house, but tomorrow when he goes to the bank or the move theater or wherever, that stuff is mostly useless because those places aren't set up for your X10/VR system. Ken
The article got this a bit wrong. Sun is willing to help shepard some important efforts. We don't require sheparding -- if you want to work on your own, feel free. In fact we usually turn down sheperding requests because we don't have very many engineers to do the work and most efforts aren't critical enough to the overall success of Jini technology. (It isn't that they aren't important, we just can't help everyone who asks.)
Slashdot Mirror
To knock an argument because of its form is only valid if there are no important arguments for which the form is actually helpful. For example:
- Premise 1. For chargeable things (cell phone, PDA, pager) there are only a few meaningful power ranges.
- Premise 2. No one power connector is significantly better than the others.
- Premise 3. It would be a good thing if there were one, or at worst a handful, of common power charging connectors.
- Conclusion: It would be good to think of all chargeable things as falling into a few buckets and having a standard connector for each bucket so I don't have to buy a set of new adaptors for each different cell phone, etc., that I buy.
Aha! The same form, a good argument. Or do you like the connector conspiracy? If you do, here's another one:- Premise 1. For most Western European languages there are a finite set of useful symbols (letters, digits, punctuation).
- Premise 2. No one common encoding of those (A = 1 vs. A = 63 vs. A = 31) is better than any other.
- Premise 3. If there were one common character encoding it would make a lot of things simpler.
- Conclusion: It would be good to think of all the computer-stored text in the world as members of a single class of files and have a standard encoding that we all follow.
Aha! The same form, and now we have ASCII trumping EBCDIC, which was a good thing. Or would you prefer if each group defined its own "better" cahracter mapping and we have a world of programs to translate between the common ones, have editors that can read ten or twenty or thirty styles, etc.? Think of all that effort! Couldn't it be better placed elsewhere. Isn't it better placed?So you see, the argument form is fine, you just disagree with the weighting. Let's keep focused on your problem, shall we?
Now I'm waiting for you to fill out the form...
This means that IE is the de facto standard of the web. If I go to a site that OmniWeb doesn't handle well (typically commercial sites), that's when I fire up IE on my Mac.
That's step one of the real threat. Step two is this: If IE doesn't run on the Mac, then there is no de facto standard browser on the Mac.
Step three: The Mac market is small enough that many of the mainstream sites may just not care. You know how much they care about Linux-based browsers right now.
Step four: With a seemingly flakey web experience, who besides the real die-hards would buy a Mac? This means that Apple is in a life-or-death race to be fully IE compatible.
Step five: Who controls what IE does? Do I even have to mention step five?
Checkmate.
Unless web sites chose to be more generally compatible and test with some Mac-based browser, they can easily and accidentally become incompatible with Macs. Currently they don't have to ask the question because Mac IE is almost the same as Windows IE. All they have to do is avoid ActiveX controls, which most do.
Yes, some will care to be careful. But many may not.
This puts Apple in a very bad position.
In this case it's not so bad because any write might fail, so you have to deal with failures anyway.
Huh? Ever heard of the "private" keyword? Only accessible within the class.
Tear-off menus, anyone? Isn't a tear-off menu a vertical tabbed pane? Sure, it's not attached necessarily to the thing it's modifying, but the patent doesn't require that.
Isn't it a tad ironic? Here we have a language that's supposed to make it possible to write stuff that can be run anywhere, and you can't even read the spec on a non-Windows platform. (Well, of course you can if you hack around, but an .exe is pretty clueless.)
The user-level APIs are one thing. But if you can only use them with equipment you've specially constructed then there's a lot of the world that you can't interact with. Someone with voice recognition, for example, could use an ATM, but right now that requires an ATM that has a voice recognizer. If the ATM instead was looking for something that answered questions, you might have a VR system and I might have a keyboard wired to my wheelchair, with a CRT, but we can both answer questions. The ATM should be able to talk to either of us. Traditionally this is done via agreement on wire protocols, such as a standard XML DTD or a CORBA interface that translates into a particular set of IIOP bits. But that's very inflexible. The point of the Jini project is to allow agreement at the programming API level, and have each service (such as a question answering service) give the client (the ATM) code that executes the request. At least that's my view of interfaces for the handicapped. Otherwise your friend can get things working inside his house, but tomorrow when he goes to the bank or the move theater or wherever, that stuff is mostly useless because those places aren't set up for your X10/VR system. Ken
The article got this a bit wrong. Sun is willing to help shepard some important efforts. We don't require sheparding -- if you want to work on your own, feel free. In fact we usually turn down sheperding requests because we don't have very many engineers to do the work and most efforts aren't critical enough to the overall success of Jini technology. (It isn't that they aren't important, we just can't help everyone who asks.)