So... I hope that once you've read them, you will let us know where you are going to post summaries of these books and what you thought of them and the validity of the specific arguments they contained? It would be nice to see a skeptical list and assessment of the strengths and weaknesses of the various arguments.
If I were using something like this, I wouldn't want AllPeers to crash every time FireFox did, or vice versa. I would prefer to keep them separate. Or at least separable.
Whedon is quite clear in the film that Firefly takes place in a single solar system, "With dozens of planets and hundreds of moons", which was colonized after the solar system containing Earth was abandoned (at least, by those who moved to the new system). We even get a picture of the solar system in which the film takes place at one point. It is unclear at what point terraforming technology was perfected, but it seems consistent with his series that it was considerably after they moved to the new solar system.
Despite your claim, I don't see any confusion on Whedon's part about the difference between a solar system and a group of stars with solar systems. His narrative is consistent throughout. I have some gripes with the way that he's laid his solar system out (for instance, IMHO the outer worlds should be CONSIDERABLY colder than the inner worlds, although some of that can be handled with a suitably chosen mix of gases for the atmosphere), but his description is at least consistent.
As to why you never see people making interstellar hops, the obvious reason is that, in general, they don't. Anymore than the average American keeps an ocean liner in his backyard so that he can take a trip to China if he needs to. They moved to the new solar system, and that's where they live now. Interstellar colonization at sublight speeds is not a fun or quick thing to do, and makes for poor movies.
The basic misunderstanding here is that you are used to science fiction which uses technobabble like "warp drives" and "hyperspace" to make faster-than-light interstellar hops in less than a human lifetime, but Whedon is restricting himself primarily to the actual known laws of physics, which suggest that such things aren't possible. (Also note that in his film, ships at a distance don't make noises in empty space, which is accurate but unfortunately quite uncommon in science fiction films).
Also, keep in mind that the crew of the Firefly is POOR. They don't get the neato toys. They can't afford laser pistols, etc. Those are for those with money, such as people that live on the Core worlds.
Please DON'T WAIT, and please DO see it at full price. The makers of this film have stated that they won't produce a sequel unless the film makes 80 million dollars. It will take quite a while before we know if that mark has been hit (including DVD sales, etc.), but it's clear already that it's going to be a tough goal to meet.
Please go see it. Bring some friends. The only way we'll get a sequel is if there's enough good word-of-mouth, especially from people who are not rabid fans of the series.
Besides, the film is excellent. Well worth the price of admission.
I recommend finding someone who has a copy of the DVDs and watching the whole set of 14 episodes in the proper order. You can see the long-term character development that way, and a lot of things that the characters will say and do will make much more sense when viewed in their proper context.
A friend of mine had the same reaction you did at first -- "I saw an episode and I didn't like it", but I loaned him my DVDs, and by the time I next saw him, he had changed his tune totally and was practically drooling over the prospect of a movie.
Serenity is an awesome film. Far better than even the fans had any right to expect. I wish the Star Wars Prequels had been that exciting. Orson Scott Card is going around claiming it's the best science fiction movie he's ever seen...
As someone who is a professional Java programmer from way back, who watched this whole thing unfold, I think that you are somewhat mistaken about this.
The problem with Microsoft's extensions to Java was not that they refused to grant Sun permission to implement them. The problem was that the extensions were a violation of the contract that Microsoft had signed, which stated that they needed to reproduce the Java language EXACTLY as it was stated in the Java Language Specification. This is needed in order to achieve binary interoperability between different implementations of the Java language.
The proper way for Microsoft to have added these extensions was to work with Sun (possibly paying them...) in changing the language standard, thus forcing all implementations of the standard to adopt the new features. Microsoft knew this (it's written quite clearly in the contract), but deliberately chose not to do so, and instead chose to violate their contract, presumably so that they could fragment the Java community with an incompatible version of Java (and encouraging people to write code that would only run on it) and thus prevent the community from achieving a consensus that could threaten Microsoft.
Java, by design, is not supposed to be extended piecemeal by individual JVM vendors. It's supposed to be extended by changes to the specifications, which are then implemented by ALL the vendors. Agreeing to support this principle is a requirement of becoming a Java licensee.
I think that Mozilla unilaterally adding features to Javascript creates exactly the same sorts of problems. I don't want to have to code web pages differently for every different kind of browser out there. Instead, the Mozilla folks should talk to the people who manage the ECMAScript standard and should get the new features added there. That way, everybody has a clearly specified, agreed-upon definition of exactly what the new feature is supposed to do, which is far preferable to everybody vaguely trying to reproduce Mozilla and other browsers bug-for-bug.
Re:Java checked exceptions suck, but how to fix th
on
Java 1.5 vs C#
·
· Score: 1
Folks, this really isn't that hard. If an exception is supposed to be impossible to trigger, then just propagate it to the caller like this:
try {
doSomething(); } catch (ImpossibleCheckedException ex) {
throw new RuntimeException("This is impossible", ex); }
Note the ",ex". That was added in JDK 1.4. It allows you to later retrieve the original exception from the "wrapping" exception.
With the above code, if the impossible exception actually occurs for some reason (because you made a coding error), the exception gets propagated up the call stack encased in a RuntimeException, which is unchecked. At the top of the call stack, you can, if you like, catch all the RuntimeExceptions, call their 'getCause()' methods to retrieve any possible ImpossibleExceptions or others stored within it, and do whatever you like with them (including rethrowing them). Or just print them out and exit, which is what is most commonly done.
In any case, please don't just catch and ignore an exception that you weren't expecting. This hides errors, and makes programs REALLY hard to debug later. If it's not supposed to ever happen, and it can't be propagated to the caller because it's a checked exception, then please catch it and throw a RuntimeException, AssertionError, UnsupportedOperationException, IllegalStateException, IllegalArgumentException, or whatever (all of which are unchecked) rather than silently hiding the error and pretending that nothing bad happened.
I agree completely. Well said. Not enough Java programmers (or C++ programmers, for that matter) understand this.
Re:I don't think so. Here's why.
on
How C# Was Made
·
· Score: 1
Actually, I was referring to the aziraphale article titled "what did they miss about checked exceptions", not the one immediately above my previous article, which appeared as I was posting it.
I don't think so. Here's why.
on
How C# Was Made
·
· Score: 1
I can't agree with you on that. I think you have seen code which uses exceptions incorrectly if you have reached this conclusion.
In your example, the error conditions that may cause method Q to fail should be part of Q's contract. Whether it is implemented in terms of P or not, it still has certain failure modes that may need to be handled differently by its caller. This is part of what you need to know to call that method correctly. Whether or not Q is implemented in terms of P is irrelevant. What matters is that Q's INTERFACE needs to be able to report certain kinds of exceptions.
Go read the post by aziraphale a couple of ones above this one. He lays it out pretty well. (I'd give him mod points if I could.)
In general, you shouldn't be propagating implementation-specific exceptions to your callers unless they are guaranteed to be essentially indistinguishable "failure" reports (and thus OK to make unchecked). The only exceptions you should be propagating in a checked fashion are interface-specific ones that explain what is happening in terms of the interface, not in terms of how the interface is implemented. It is perfectly reasonable to make those exceptions checked exceptions.
If I create a getTheWidget() method, it is quite reasonable to have it throw a WidgetNotAvailableException. I shouldn't be having it throw a FileNotFoundException that the caller is expected to know about and trap (and thus treat differently from other runtime exceptions that might also be thrown). If the widget is truly not available because a file could not be found, and I can't treat this as a fatal the-program-is-over kind of exception, then the right thing to do is throw a WidgetNotAvailableException. (There might be a FileNotFoundException wrapped inside, for use in debugging. JDK 1.4 and up provides a standard way to do this.) That way, the caller does not need to know the specifics of WHY the widget was not available. It only needs to know that this was the case, so it can handle that case differently than, say, WidgetIsDamagedException.
Unfortunately, I have met relatively few Java programmers who are aware of this design choice in the language, and misuse of exceptions is fairly rampant. I wish Sun would publish more how-to articles on this kind of design issue.
The Java version works this way too. Only one copy of the template code is generated.
Even C++ is allowed to work this way, by the specification. It's just that virtually no C++ compilers actually do it that way.
Well, the first image looks to me pretty clearly like a volcano which has blown its top (or a meteor that cut down into bedrock), and then is (was) being slowly rebuilt by a lava feed. For an example of this, look into the crater of Mount St. Helens, in Washington USA. Eventually, the lava dome will fill the crater and rebuild the top of the mountain. Of course, the dome could just be the remains of the actual comet which made the crater.
For the second image, I notice that the stripes in the material seem to point in the same directions as the prevailing direction of faded lines in other features on the image. This to me implies that the prevailing wind direction is northeast to southwest, and that these features are probably the result of wind erosion. Probably the ridge is composed of a soft material that was extruded through a hard material, and the wind blowing over the hard material picked up rocks and such which eroded the soft material. The regular intervals are probably due to the amount of air pressure that was relieved by a notch having been cut. When you get far enough away from a notch, it relieves more pressure to cut a new notch than for air to be redirected towards an old one. So you get a fairly regular pattern of notches, perpendicular to the wind direction.
There are a lot of pretty strange land features on Earth, too. Not all of them are the result of organic life. Take a look at Bryce Canyon sometime...
My favorite pen is the Fisher Space Pen. They are *expensive* ($40 or so), but the pen always consistently writes (on anything, upside down, on greasy surfaces, etc.), and I love the way the pen, with the cap on, is only about three inches long and fits nicely in the bottom of my pants pocket without stabbing me in the groin or becoming otherwise inconvenient. (The cap removes to fit on the back of the pen, doubling its length.)
If you get the silver one, it's easy to have it engraved. I carried one such for many years. When I lost it, I immediately bought another one.
The IDEA environment from IntelliJ (www.intellij.com, or www.intellij.net for the beta versions) finds a variety of coding errors as you type, underlining problem spots. It pretty much finds the same errors as the compiler would. (e.g. "this statement may throw exception Foo which is uncaught", "this variable may not yet have been assigned", etc.)
When working with other editors, I used to compile individual code files once in a while just to make sure that my full build would succeed. With IDEA, I find that once I have fixed all the things that the IDE is pointing out as I type, my build is almost guaranteed to succeed, with no need for intermediate compiles for syntax checking.
There are a LOT of other cool features (refactoring support, etc.) in this IDE as well. I'll never use JBuilder again...
(No, I don't work for IntelliJ. Just a happy customer.)
First of all, it is a mistake to assume that the only form of reuse is by class hierarchies. Lots of reuse is accomplished by actual non-inheritable classes which do specific things. ("Library routines", for instance, or classes like 'string' which are used to hold and manipulate data) Reuse doesn't need to create huge class hierarchies.
Second, if you have a real reuse program in place, then reusable components should come already with test code to exercise them. This has a major impact on the reliability of the code that uses them, not to mention time to market.
Third, Some kinds of projects benefit tremendously from reuse. The typical case is where a company has to do several not-quite-identical-but-highly-similar projects. Designing each one of these from scratch is tremendously wasteful. Furthermore, the result is likely to be unreliable due to the fact that each bug has to be tested for multiple times, whereas in a project with heavy reuse, fixing an error in one reusable component fixes that error in all projects that use it.
On the other hand, not all components should be expected to be reusable, since not every component in a project is a likely candidate for reuse. Designing something to be reusable when it is not likely to ever be reused is often a waste of time. Also, trying to reuse something that was not designed to be reused is likely to cause more problems than it solves. Still, in situations where reuse is beneficial, it can often be hugely beneficial, and can effectively reduce the effort required to build a project in half, a third, etc. so it should not be overlooked even despite these drawbacks.
Slashdot Mirror
So... I hope that once you've read them, you will let us know where you are going to post summaries of these books and what you thought of them and the validity of the specific arguments they contained? It would be nice to see a skeptical list and assessment of the strengths and weaknesses of the various arguments.
If I were using something like this, I wouldn't want AllPeers to crash every time FireFox did, or vice versa.
I would prefer to keep them separate. Or at least separable.
"Informative"...
Oops. Screwed up my cut-and-paste on that last one. Here's a corrected link:
t v=12&htv=12&htv=12
http://www.ifilm.com/ifilmdetail/2681478?htv=12&h
Here's a version that (I am told) is viewable under Linux:
t v=12&htv=12&htv=12&htv=12
http://www.ifilm.com/ifilmdetail/2681478?htv=12&h
Here's a version that (I am told) is viewable under Linux:
t v=12&htv=12&htv=12&htv=12
http://www.ifilm.com/ifilmdetail/2681478?htv=12&h
Whedon is quite clear in the film that Firefly takes place in a single solar system, "With dozens of planets and hundreds of moons", which was colonized after the solar system containing Earth was abandoned (at least, by those who moved to the new system). We even get a picture of the solar system in which the film takes place at one point. It is unclear at what point terraforming technology was perfected, but it seems consistent with his series that it was considerably after they moved to the new solar system.
Despite your claim, I don't see any confusion on Whedon's part about the difference between a solar system and a group of stars with solar systems. His narrative is consistent throughout. I have some gripes with the way that he's laid his solar system out (for instance, IMHO the outer worlds should be CONSIDERABLY colder than the inner worlds, although some of that can be handled with a suitably chosen mix of gases for the atmosphere), but his description is at least consistent.
As to why you never see people making interstellar hops, the obvious reason is that, in general, they don't. Anymore than the average American keeps an ocean liner in his backyard so that he can take a trip to China if he needs to. They moved to the new solar system, and that's where they live now. Interstellar colonization at sublight speeds is not a fun or quick thing to do, and makes for poor movies.
The basic misunderstanding here is that you are used to science fiction which uses technobabble like "warp drives" and "hyperspace" to make faster-than-light interstellar hops in less than a human lifetime, but Whedon is restricting himself primarily to the actual known laws of physics, which suggest that such things aren't possible. (Also note that in his film, ships at a distance don't make noises in empty space, which is accurate but unfortunately quite uncommon in science fiction films).
Also, keep in mind that the crew of the Firefly is POOR. They don't get the neato toys. They can't afford laser pistols, etc. Those are for those with money, such as people that live on the Core worlds.
Please DON'T WAIT, and please DO see it at full price. The makers of this film have stated that they won't produce a sequel unless the film makes 80 million dollars. It will take quite a while before we know if that mark has been hit (including DVD sales, etc.), but it's clear already that it's going to be a tough goal to meet.
Please go see it. Bring some friends. The only way we'll get a sequel is if there's enough good word-of-mouth, especially from people who are not rabid fans of the series.
Besides, the film is excellent. Well worth the price of admission.
I recommend finding someone who has a copy of the DVDs and watching the whole set of 14 episodes in the proper order. You can see the long-term character development that way, and a lot of things that the characters will say and do will make much more sense when viewed in their proper context.
A friend of mine had the same reaction you did at first -- "I saw an episode and I didn't like it", but I loaned him my DVDs, and by the time I next saw him, he had changed his tune totally and was practically drooling over the prospect of a movie.
Serenity is an awesome film. Far better than even the fans had any right to expect. I wish the Star Wars Prequels had been that exciting. Orson Scott Card is going around claiming it's the best science fiction movie he's ever seen...
As someone who is a professional Java programmer from way back, who watched this whole thing unfold, I think that you are somewhat mistaken about this.
The problem with Microsoft's extensions to Java was not that they refused to grant Sun permission to implement them. The problem was that the extensions were a violation of the contract that Microsoft had signed, which stated that they needed to reproduce the Java language EXACTLY as it was stated in the Java Language Specification. This is needed in order to achieve binary interoperability between different implementations of the Java language.
The proper way for Microsoft to have added these extensions was to work with Sun (possibly paying them...) in changing the language standard, thus forcing all implementations of the standard to adopt the new features. Microsoft knew this (it's written quite clearly in the contract), but deliberately chose not to do so, and instead chose to violate their contract, presumably so that they could fragment the Java community with an incompatible version of Java (and encouraging people to write code that would only run on it) and thus prevent the community from achieving a consensus that could threaten Microsoft.
Java, by design, is not supposed to be extended piecemeal by individual JVM vendors. It's supposed to be extended by changes to the specifications, which are then implemented by ALL the vendors. Agreeing to support this principle is a requirement of becoming a Java licensee.
I think that Mozilla unilaterally adding features to Javascript creates exactly the same sorts of problems. I don't want to have to code web pages differently for every different kind of browser out there. Instead, the Mozilla folks should talk to the people who manage the ECMAScript standard and should get the new features added there. That way, everybody has a clearly specified, agreed-upon definition of exactly what the new feature is supposed to do, which is far preferable to everybody vaguely trying to reproduce Mozilla and other browsers bug-for-bug.
You can get the JVM source code with a Sun Community Source License
Folks, this really isn't that hard. If an exception is supposed to be impossible to trigger, then just propagate it to the caller like this:
try
{
doSomething();
}
catch (ImpossibleCheckedException ex)
{
throw new RuntimeException("This is impossible", ex);
}
Note the ",ex". That was added in JDK 1.4. It allows you to later retrieve the original exception from the "wrapping" exception.
With the above code, if the impossible exception actually occurs for some reason (because you made a coding error), the exception gets propagated up the call stack encased in a RuntimeException, which is unchecked. At the top of the call stack, you can, if you like, catch all the RuntimeExceptions, call their 'getCause()' methods to retrieve any possible ImpossibleExceptions or others stored within it, and do whatever you like with them (including rethrowing them). Or just print them out and exit, which is what is most commonly done.
In any case, please don't just catch and ignore an exception that you weren't expecting. This hides errors, and makes programs REALLY hard to debug later. If it's not supposed to ever happen, and it can't be propagated to the caller because it's a checked exception, then please catch it and throw a RuntimeException, AssertionError, UnsupportedOperationException, IllegalStateException, IllegalArgumentException, or whatever (all of which are unchecked) rather than silently hiding the error and pretending that nothing bad happened.
This blog is quite interesting. I had no idea such a thing existed.
I agree completely. Well said. Not enough Java programmers (or C++ programmers, for that matter) understand this.
Actually, I was referring to the aziraphale article titled "what did they miss about checked exceptions", not the one immediately above my previous article, which appeared as I was posting it.
In your example, the error conditions that may cause method Q to fail should be part of Q's contract. Whether it is implemented in terms of P or not, it still has certain failure modes that may need to be handled differently by its caller. This is part of what you need to know to call that method correctly. Whether or not Q is implemented in terms of P is irrelevant. What matters is that Q's INTERFACE needs to be able to report certain kinds of exceptions.
Go read the post by aziraphale a couple of ones above this one. He lays it out pretty well. (I'd give him mod points if I could.)
In general, you shouldn't be propagating implementation-specific exceptions to your callers unless they are guaranteed to be essentially indistinguishable "failure" reports (and thus OK to make unchecked). The only exceptions you should be propagating in a checked fashion are interface-specific ones that explain what is happening in terms of the interface, not in terms of how the interface is implemented. It is perfectly reasonable to make those exceptions checked exceptions.
If I create a getTheWidget() method, it is quite reasonable to have it throw a WidgetNotAvailableException. I shouldn't be having it throw a FileNotFoundException that the caller is expected to know about and trap (and thus treat differently from other runtime exceptions that might also be thrown). If the widget is truly not available because a file could not be found, and I can't treat this as a fatal the-program-is-over kind of exception, then the right thing to do is throw a WidgetNotAvailableException. (There might be a FileNotFoundException wrapped inside, for use in debugging. JDK 1.4 and up provides a standard way to do this.) That way, the caller does not need to know the specifics of WHY the widget was not available. It only needs to know that this was the case, so it can handle that case differently than, say, WidgetIsDamagedException.
Unfortunately, I have met relatively few Java programmers who are aware of this design choice in the language, and misuse of exceptions is fairly rampant. I wish Sun would publish more how-to articles on this kind of design issue.
The Java version works this way too. Only one copy of the template code is generated. Even C++ is allowed to work this way, by the specification. It's just that virtually no C++ compilers actually do it that way.
Well, the first image looks to me pretty clearly like a volcano which has blown its top (or a meteor that cut down into bedrock), and then is (was) being slowly rebuilt by a lava feed. For an example of this, look into the crater of Mount St. Helens, in Washington USA. Eventually, the lava dome will fill the crater and rebuild the top of the mountain. Of course, the dome could just be the remains of the actual comet which made the crater.
For the second image, I notice that the stripes in the material seem to point in the same directions as the prevailing direction of faded lines in other features on the image. This to me implies that the prevailing wind direction is northeast to southwest, and that these features are probably the result of wind erosion. Probably the ridge is composed of a soft material that was extruded through a hard material, and the wind blowing over the hard material picked up rocks and such which eroded the soft material. The regular intervals are probably due to the amount of air pressure that was relieved by a notch having been cut. When you get far enough away from a notch, it relieves more pressure to cut a new notch than for air to be redirected towards an old one. So you get a fairly regular pattern of notches, perpendicular to the wind direction.
There are a lot of pretty strange land features on Earth, too. Not all of them are the result of organic life. Take a look at Bryce Canyon sometime...
If you get the silver one, it's easy to have it engraved. I carried one such for many years. When I lost it, I immediately bought another one.
Of course the author Frederic Brown had a bit of a different take on the subject...
:-)
http://www.ece.ubc.ca/~alia/Space/sci-fi.html
The IDEA environment from IntelliJ (www.intellij.com, or www.intellij.net for the beta versions) finds a variety of coding errors as you type, underlining problem spots. It pretty much finds the same errors as the compiler would. (e.g. "this statement may throw exception Foo which is uncaught", "this variable may not yet have been assigned", etc.)
When working with other editors, I used to compile individual code files once in a while just to make sure that my full build would succeed. With IDEA, I find that once I have fixed all the things that the IDE is pointing out as I type, my build is almost guaranteed to succeed, with no need for intermediate compiles for syntax checking.
There are a LOT of other cool features (refactoring support, etc.) in this IDE as well. I'll never use JBuilder again...
(No, I don't work for IntelliJ. Just a happy customer.)
A couple of comments:
First of all, it is a mistake to assume that the only form of reuse is by class hierarchies. Lots of reuse is accomplished by actual non-inheritable classes which do specific things. ("Library routines", for instance, or classes like 'string' which are used to hold and manipulate data) Reuse doesn't need to create huge class hierarchies.
Second, if you have a real reuse program in place, then reusable components should come already with test code to exercise them. This has a major impact on the reliability of the code that uses them, not to mention time to market.
Third, Some kinds of projects benefit tremendously from reuse. The typical case is where a company has to do several not-quite-identical-but-highly-similar projects. Designing each one of these from scratch is tremendously wasteful. Furthermore, the result is likely to be unreliable due to the fact that each bug has to be tested for multiple times, whereas in a project with heavy reuse, fixing an error in one reusable component fixes that error in all projects that use it.
On the other hand, not all components should be expected to be reusable, since not every component in a project is a likely candidate for reuse. Designing something to be reusable when it is not likely to ever be reused is often a waste of time. Also, trying to reuse something that was not designed to be reused is likely to cause more problems than it solves. Still, in situations where reuse is beneficial, it can often be hugely beneficial, and can effectively reduce the effort required to build a project in half, a third, etc. so it should not be overlooked even despite these drawbacks.