"They also give a very good example of how to get kids to be creative --- a school where kids were asked to solve a problem, and they liked it."
Almost true, but sometimes you have to solve things even if you don't like. There are many reasons why you do not like solving a problem, and it being uninteresting is just one of them. School has an important task, that is increasing your confidence in problem solving. You should be never frightened by problems, and you should be able to close out distracting thoughts from your head and maintain focus.
"And yes, limitations stimulate creativity. But not if you don't see the limitations. How can you expect kids who don't need to use their imagination to realize that learning can be much more than data retention?"
I don't argue with this. What you should see, however, is the big business in the "creativity enhancing" techniques, trainings, schools, etc. Nowadays parents (especially rich ones) bring their dumb children (who are usually dumb because of the parents themselves) to these "creative" schools, because they cannot accept that their children perform poorly. It is a much more comforting explanation that they are "just too creative" and the "school hampers their self-expression". Authority of the teacher is important. It is not easy to set the right balance -- authority can be abused, but lack of authority means that the teacher is abused.
A teacher is a coach. He/she has to somewhat force the children to push them to their limits. Just like a runner. It is easier to run faster if there is a coach extending your willpower. Now parents tend to work against this and undermine teacher authority.
"And another fact: the same tests were given in the US and in the rest of the world. As I understand it from the article, the rest of the world did better. That means that the test is not completely ridiculous, because it sees a difference between specific sets of kids."
Well, if the test is defective, then these differences may not mean what you think they mean. I am very skeptic of these tests, albeit I had achieved high score in them.
"Frequently these limits are arbitrary, capricious and imposed post-hoc, and their violation comes with severe punishments."
Yes, those limits are bad.
But many of the whiners complain about limitations that are not like this. I knew people crying about mathematics problems as they are "hampering their creativity", but in fact, they were just not smart enough to solve the problem. Many of these people think about arts as the most creative thing on earth. While arts involve a lot of creativity, so does engineering.
Creativity tests... heh. Most of these tests are completely ridiculous.
I remember one of these tests where totally stupid answers were given points, just because they are "original". I hate people that think of themselves as "creative", yet, they cannot come up with something PRACTICALLY USEFUL. You can be "very original" and "totally irrelevant" at the same time. For me, creativity means original and usable (in a broad sense -- amusing, entertaining, enthralling, etc count as useful, too).
I hate even more those people that cry "all these rules just hamper my creativity". Again, bullshit! Limitations often stimulate creativity. Puzzles are all about limits on the solution space. Many writers, painters, poems made up artificial limits for themselves, just to see, what can they do within those limitations. Also, any engineer has to think inside some box, as the final result has to be useful and relevant to the problem at hand. Physicists are limited by the laws of nature -- still, many physicists are very creative -- especially because they have to use seemingly limiting laws to their benefit. Hacking is also a great example where the whole process is about seemingly bending the limits, but you really stay inside them, you just discover ways that were unexpected to be existing inside that "box". Logic is also a limitation. Are you original just because you deny logic? Sometimes yes (in these cases you end up with an augmented logic), but most of the times, no.
No, the OP is right, this is augmented reality, because the magnetic field information is superimposed over the vision of the bird's right eye. If it closes it's eyes, no magnetic information is perceived.
You have to see the larger picture. Pluto was just the beginning. They miscalculated however the public backlash and now they proceed more carefully. They take away now the other planets femtogram by femtogram, proton by proton, particle by particle!
Well, I really wanted to finish it here, as this thread starts to get really long, but I have to answer your points.
"I think if you want to argue that Java's exception handling is a better way of doing it"
If you had taken really care to read my comments, then you would not make such statement. I am pro-checked exceptions but I also stated that I find the Java implementation to be inflexible. I am not saying anything like "Java's exception handling is the better way".
"it would be good if you could point at some observations and some examples/research from other languages supporting your view."
If you do not have citations then you cannot have a good point, that's what you imply? Or are you stating that every important research is already done, and no new research will ever happen that deserves attention?
"(1) Java programs spew out uncaught exceptions more frequently than programs in other languages with exceptions"
What I see, is that people fuck up exception handling in ALL of the languages that have exceptions regardless of checked or not-checked. Also, a lot of people still avoid using exceptions at all.
It is also important to note that most of the exceptions coming out from Java programs are NullPointerExceptions.
"when I reviewed Sun's Java source code, a large percentage of exception handlers were incorrect,"
Sun messed up other things, too. If you want to see some nice exception handling, look at the code of the Guice framework.
"even religiously statically typed languages like ML do not use exception declarations (in fact, they tried it in early versions of the language and then removed them because they found that they don't make sense)."
I don't know ML specifically (although I learned SML long ago), but many functional languages adopt the two-state return type, like the Option[T] type in Scala. Now constructs like this with a strict type system ends up people writing almost the same code as with try...catch.
"Thinking like yours--namely driving recovery code through knowledge of where exceptions are raised--is why so many Java programs keep spewing out all those uncaught exceptions."
I totally disagree on this matter, but let's finish this thread.
"That is what "concerning themselves with exceptions they don't know how to handle" means."
Even if you don't know how to handle, you should be aware of the exceptional control paths of the code you use. Also, handling is not necessarily recovery, but also context and debug information collection.
"It's wrong handle exceptions just because you "could"."
Let's reword my previous statement then, to express myself more clearly: In the unchecked case I could get exceptions that I was completely unaware that could happen - even if I probably could _recover_ from them.
But because I am unaware that the given code could throw that exception I just don't write the handler.
"Checked exceptions make proper exception handling harder because they force people to concern themselves with exceptions they don't know how to handle and they should just leave alone."
No, they only force people to indicate that they let that exception propagate upwards. In the unchecked case I could get exceptions that I was completely unaware that could happen - even if I probably could handle them.
"That is, TreeSearch.search invokes some methods on FileSystemTree that may trigger an IOException, but TreeSearch doesn't and shouldn't need to know about that."
Ok, that is really a problematic case. However, if Java would allow to attach exception handler classes to other classes this would be easily solvable.
"The real problem with exception declarations is that they actually cause people to handle exceptions badly."
No, the real problem is that people don't give a damn about proper exception handling, checked or not. Checked exceptions just make them more annoyed, because they have to do some work to get rid of them - therefore they go to the unchecked language.
"In the sense I used the word convenience (less typing for the programmer) - I strongly disagree. (Hence) also strongly disagree for terseness."
Hm, I think we talk about the same, but maybe using different words. Convenience/terseness is useful if it improves readability, maintainability and helps reducing errors (duplications usually end up with bugs)
"I don't think you have a solution here."
No, I don't. In fact, I don't think there is a real possibility to solve this in Java. However, there are other languages, like Scala that I use -- pattern matching is natively supported there, so it is easy to use on exceptions as well. The problem is that most new languages (e.g. Scala) abandon the idea of checked exceptions, which I found to be sad. There were no attempts to take the idea to one step further.
"2. Now closures are coming. I think this is the syntactic sugar you are want. Though not exactly what you are asking for."
It helps somewhat, but does not solve everything. I think they will also introduce the resource handling construct that handles safe closing of resources. It is nice, but not generic enough.
"If you have followed Java languages' progress, you would have lost hope for terse constructs long ago"
I lost, too. My point was however about checked exceptions in general -- but the only example is Java that I know of, that uses them.
"According to anthropomorphized Java, that is what an IDE is for. But I guess closures is the solution from Java's side in this case too."
Well, they lost me already, although I'm interested in the new closures addition.
"I don't understand. Your other post seems almost to be arguing for java type exception handling. All those idioms are well supported in java."
You misunderstood me then. I am pro checked exceptions and contra try..catch control structure (or it being the only one).
"Only thing that java does not have is convenience/terseness."
Every syntax is about convenience/terseness. Otherwise go to binary code directly. While I agree that language designers are reluctant to introduce syntax sugar for each possible use-case, checked exceptions I think important enough to be supported by better syntax.
"If you mean string pattern matching, I am horrified at the disaster that it will be. But yeah, object patterns can and are matched in java exception handling."
String matching is obviously no go. I was talking about matching the exception chain that results from deeply nested exceptions. In several cases for correct recovery, you must traverse the exception chain, but some syntax sugar could really help here.
"This is the undesirable decoupling of 2 things that go together."
I agree with you on this matter, I think you misunderstood me a bit. I just don't want to repeat the same handling pattern every time but I want it to refactor it to one place. I stumbled many times into problems, when the handling/recovery part was almost the same, but with one parameter changing. In this case your best bet is to factor out some of the handler part into a method (or sometimes it's own class) and call it from the catch blocks. But the try..catch clutter will remain. Don't repeat yourself is violated here.
"IDE functionality. Java just provides a way to wrap. Doing it en-masse on the class is a problem of your IDE."
First of all, you cannot delegate every important stuff to the IDE. It makes sense in many cases, but not every time. Also, if I could declare the rethrow case at the beginning of the class, it would make the code more readable. Again, I am talking about syntax.
"Could be interesting. Any concrete example where this information would be useful? And how would the compiler / execution engine use it? It can't force the client developer to catch in all methods each of the exceptions that a package was going to throw, right?"
It was a draft idea, but basically it is matching the exception model with the modularity models of OSGi and Jigsaw. In those models, you can hide many aspects of the module behind the explicitly exposed interfaces. Of course if these interfaces declare the throwable exceptions, then my idea is completely unnecessary.
"then it's reasonable to expect that I can get and catch AX exceptions when calling methods on B. In Java"
It is reasonable if B also declares to throw that exception. Otherwise it must wrap it in XB. B must explicitly document that it is letting AX exception through. I don't see why is this a problem.
What I would like to see is more declarative exception handling.
Some examples:
- pattern matching on nested exceptions
- declaring that a class will simply wrap and rethrow all exceptions in a given higher level exception
- implementing common exception handler routines in a separate class and declaratively attaching them to other classes - AOP style would be handy
- chaining attached handlers
- package level declarations about the exception types that could be thrown to classes outside the package
Slashdot Mirror
I would say: mu
"They also give a very good example of how to get kids to be creative --- a school where kids were asked to solve a problem, and they liked it."
Almost true, but sometimes you have to solve things even if you don't like. There are many reasons why you do not like solving a problem, and it being uninteresting is just one of them. School has an important task, that is increasing your confidence in problem solving. You should be never frightened by problems, and you should be able to close out distracting thoughts from your head and maintain focus.
"And yes, limitations stimulate creativity. But not if you don't see the limitations. How can you expect kids who don't need to use their imagination to realize that learning can be much more than data retention?"
I don't argue with this. What you should see, however, is the big business in the "creativity enhancing" techniques, trainings, schools, etc. Nowadays parents (especially rich ones) bring their dumb children (who are usually dumb because of the parents themselves) to these "creative" schools, because they cannot accept that their children perform poorly. It is a much more comforting explanation that they are "just too creative" and the "school hampers their self-expression". Authority of the teacher is important. It is not easy to set the right balance -- authority can be abused, but lack of authority means that the teacher is abused.
A teacher is a coach. He/she has to somewhat force the children to push them to their limits. Just like a runner. It is easier to run faster if there is a coach extending your willpower. Now parents tend to work against this and undermine teacher authority.
"And another fact: the same tests were given in the US and in the rest of the world. As I understand it from the article, the rest of the world did better. That means that the test is not completely ridiculous, because it sees a difference between specific sets of kids."
Well, if the test is defective, then these differences may not mean what you think they mean. I am very skeptic of these tests, albeit I had achieved high score in them.
"Frequently these limits are arbitrary, capricious and imposed post-hoc, and their violation comes with severe punishments."
Yes, those limits are bad.
But many of the whiners complain about limitations that are not like this. I knew people crying about mathematics problems as they are "hampering their creativity", but in fact, they were just not smart enough to solve the problem. Many of these people think about arts as the most creative thing on earth. While arts involve a lot of creativity, so does engineering.
140+ if you don't take the test at all.
Creativity tests... heh. Most of these tests are completely ridiculous.
I remember one of these tests where totally stupid answers were given points, just because they are "original". I hate people that think of themselves as "creative", yet, they cannot come up with something PRACTICALLY USEFUL. You can be "very original" and "totally irrelevant" at the same time. For me, creativity means original and usable (in a broad sense -- amusing, entertaining, enthralling, etc count as useful, too).
I hate even more those people that cry "all these rules just hamper my creativity". Again, bullshit! Limitations often stimulate creativity. Puzzles are all about limits on the solution space. Many writers, painters, poems made up artificial limits for themselves, just to see, what can they do within those limitations. Also, any engineer has to think inside some box, as the final result has to be useful and relevant to the problem at hand. Physicists are limited by the laws of nature -- still, many physicists are very creative -- especially because they have to use seemingly limiting laws to their benefit. Hacking is also a great example where the whole process is about seemingly bending the limits, but you really stay inside them, you just discover ways that were unexpected to be existing inside that "box". Logic is also a limitation. Are you original just because you deny logic? Sometimes yes (in these cases you end up with an augmented logic), but most of the times, no.
Rant off.
I fully agree.
"And to top it all off, birds taste better."
Yes! Yummy birds...
No, the OP is right, this is augmented reality, because the magnetic field information is superimposed over the vision of the bird's right eye. If it closes it's eyes, no magnetic information is perceived.
"That's a joke that only the Slashdot crowd would and if you tell it at a party, a party that has cute girls. Nah, that won't happen."
Fixed that for you.
At least you do not need additional oil to fry them.
You have to see the larger picture. Pluto was just the beginning. They miscalculated however the public backlash and now they proceed more carefully. They take away now the other planets femtogram by femtogram, proton by proton, particle by particle!
... and now this! These scientists have no shame!
"Meine Ehre heißt Treue"
Well, I really wanted to finish it here, as this thread starts to get really long, but I have to answer your points.
"I think if you want to argue that Java's exception handling is a better way of doing it"
If you had taken really care to read my comments, then you would not make such statement. I am pro-checked exceptions but I also stated that I find the Java implementation to be inflexible. I am not saying anything like "Java's exception handling is the better way".
"it would be good if you could point at some observations and some examples/research from other languages supporting your view."
If you do not have citations then you cannot have a good point, that's what you imply? Or are you stating that every important research is already done, and no new research will ever happen that deserves attention?
"(1) Java programs spew out uncaught exceptions more frequently than programs in other languages with exceptions"
What I see, is that people fuck up exception handling in ALL of the languages that have exceptions regardless of checked or not-checked. Also, a lot of people still avoid using exceptions at all.
It is also important to note that most of the exceptions coming out from Java programs are NullPointerExceptions.
"when I reviewed Sun's Java source code, a large percentage of exception handlers were incorrect,"
Sun messed up other things, too. If you want to see some nice exception handling, look at the code of the Guice framework.
"even religiously statically typed languages like ML do not use exception declarations (in fact, they tried it in early versions of the language and then removed them because they found that they don't make sense)."
I don't know ML specifically (although I learned SML long ago), but many functional languages adopt the two-state return type, like the Option[T] type in Scala. Now constructs like this with a strict type system ends up people writing almost the same code as with try...catch.
"Thinking like yours--namely driving recovery code through knowledge of where exceptions are raised--is why so many Java programs keep spewing out all those uncaught exceptions."
I totally disagree on this matter, but let's finish this thread.
We need a "+1 Mean" moderation option.
"That is what "concerning themselves with exceptions they don't know how to handle" means."
Even if you don't know how to handle, you should be aware of the exceptional control paths of the code you use. Also, handling is not necessarily recovery, but also context and debug information collection.
"It's wrong handle exceptions just because you "could"."
Let's reword my previous statement then, to express myself more clearly:
In the unchecked case I could get exceptions that I was completely unaware that could happen - even if I probably could _recover_ from them.
But because I am unaware that the given code could throw that exception I just don't write the handler.
"Checked exceptions make proper exception handling harder because they force people to concern themselves with exceptions they don't know how to handle and they should just leave alone."
No, they only force people to indicate that they let that exception propagate upwards. In the unchecked case I could get exceptions that I was completely unaware that could happen - even if I probably could handle them.
"That is, TreeSearch.search invokes some methods on FileSystemTree that may trigger an IOException, but TreeSearch doesn't and shouldn't need to know about that."
Ok, that is really a problematic case. However, if Java would allow to attach exception handler classes to other classes this would be easily solvable.
"The real problem with exception declarations is that they actually cause people to handle exceptions badly."
No, the real problem is that people don't give a damn about proper exception handling, checked or not. Checked exceptions just make them more annoyed, because they have to do some work to get rid of them - therefore they go to the unchecked language.
You lucky bastard, you live in a real democracy!
"In the sense I used the word convenience (less typing for the programmer) - I strongly disagree. (Hence) also strongly disagree for terseness."
Hm, I think we talk about the same, but maybe using different words. Convenience/terseness is useful if it improves readability, maintainability and helps reducing errors (duplications usually end up with bugs)
"I don't think you have a solution here."
No, I don't. In fact, I don't think there is a real possibility to solve this in Java. However, there are other languages, like Scala that I use -- pattern matching is natively supported there, so it is easy to use on exceptions as well. The problem is that most new languages (e.g. Scala) abandon the idea of checked exceptions, which I found to be sad. There were no attempts to take the idea to one step further.
"2. Now closures are coming. I think this is the syntactic sugar you are want. Though not exactly what you are asking for."
It helps somewhat, but does not solve everything. I think they will also introduce the resource handling construct that handles safe closing of resources. It is nice, but not generic enough.
"If you have followed Java languages' progress, you would have lost hope for terse constructs long ago"
I lost, too. My point was however about checked exceptions in general -- but the only example is Java that I know of, that uses them.
"According to anthropomorphized Java, that is what an IDE is for. But I guess closures is the solution from Java's side in this case too."
Well, they lost me already, although I'm interested in the new closures addition.
(puppy eyes)
"I don't understand. Your other post seems almost to be arguing for java type exception handling. All those idioms are well supported in java."
You misunderstood me then. I am pro checked exceptions and contra try..catch control structure (or it being the only one).
"Only thing that java does not have is convenience/terseness."
Every syntax is about convenience/terseness. Otherwise go to binary code directly. While I agree that language designers are reluctant to introduce syntax sugar for each possible use-case, checked exceptions I think important enough to be supported by better syntax.
"If you mean string pattern matching, I am horrified at the disaster that it will be. But yeah, object patterns can and are matched in java exception handling."
String matching is obviously no go. I was talking about matching the exception chain that results from deeply nested exceptions. In several cases for correct recovery, you must traverse the exception chain, but some syntax sugar could really help here.
"This is the undesirable decoupling of 2 things that go together."
I agree with you on this matter, I think you misunderstood me a bit. I just don't want to repeat the same handling pattern every time but I want it to refactor it to one place. I stumbled many times into problems, when the handling/recovery part was almost the same, but with one parameter changing. In this case your best bet is to factor out some of the handler part into a method (or sometimes it's own class) and call it from the catch blocks. But the try..catch clutter will remain. Don't repeat yourself is violated here.
"IDE functionality. Java just provides a way to wrap. Doing it en-masse on the class is a problem of your IDE."
First of all, you cannot delegate every important stuff to the IDE. It makes sense in many cases, but not every time. Also, if I could declare the rethrow case at the beginning of the class, it would make the code more readable. Again, I am talking about syntax.
"Could be interesting. Any concrete example where this information would be useful? And how would the compiler / execution engine use it? It can't force the client developer to catch in all methods each of the exceptions that a package was going to throw, right?"
It was a draft idea, but basically it is matching the exception model with the modularity models of OSGi and Jigsaw. In those models, you can hide many aspects of the module behind the explicitly exposed interfaces. Of course if these interfaces declare the throwable exceptions, then my idea is completely unnecessary.
"then it's reasonable to expect that I can get and catch AX exceptions when calling methods on B. In Java"
It is reasonable if B also declares to throw that exception. Otherwise it must wrap it in XB. B must explicitly document that it is letting AX exception through. I don't see why is this a problem.
"Can you describe the "common idioms" a bit more? And how do other languages solve those problems?"
Other languages do not have checked exceptions, Java is the only one I think.
I do not want to repeat myself, so I just link to my other comment where I explain some common cases:
http://slashdot.org/comments.pl?sid=1707628&cid=32797252
What I would like to see is more declarative exception handling.
Some examples:
- pattern matching on nested exceptions
- declaring that a class will simply wrap and rethrow all exceptions in a given higher level exception
- implementing common exception handler routines in a separate class and declaratively attaching them to other classes - AOP style would be handy
- chaining attached handlers
- package level declarations about the exception types that could be thrown to classes outside the package