On 30 March 2011 14:00, Reinier Zwitserloot <[email protected]> wrote:
> On Wednesday, March 30, 2011 12:50:37 AM UTC+2, KWright wrote: >> >> >> Why are you criticizing the self-proclaimed "rough first draft" and >> totally ignoring the whole point of my message? >> > > Because Cedric already explained why the point of your message wasn't > particularly convincing. I'm calling you out as an extremely biased source > that'll make java look bad at any opportunity, and evidently you do this > without consciously even realizing it. I get the feeling that, whatever java > does, if scala has an alternative way of doing it, you're against it, > regardless of what "it" is. > Hey, Java is a bloody marvellous platform, aside from the occasional gripe about lack of tail-calls and such you won't hear me knock it. Lets face it though, the language is deeply encumbered by backward compatibility requirements, which is fine if you're still weaning yourself off of COBOL, but it's starting to get seriously annoying in the way it restricts a lot of good design. > Specifically, that using checked exceptions to provide an alternate return >> is a flawed design, because it sidesteps the type system >> > > No it doesn't. > All together now... "Oh yes it does!" (see how easy that was? It must be pantomime season already, I know that Christmas gets marketed earlier year on year, but this is just plain silly) > > >> and doesn't compose effectively >> > > Yes it does. > Rats, you already got there ahead of me... > In the extremely rare scenario you want to do a series of parallel > operations and the failure of one such operation by way of an exception is > not meant to stop processing on any other, then... just build that. If for a > particular case you truly feel the best design is to create a > List<Either<Widget, IOException>> or some such then... just make that. > collections are API constructs. If you want to have, say, a map call that > works like this you can build it with (checked) exceptions just the same as > with eithers, and if you build it for exceptions then you get the additional > benefit of being able to apply this feature to unchecked exceptions as well. > The difference between an unchecked exception and a checked exception (or > Either return) is a grey line; there are cases where its a judgement call > where there will never be any consensus about what is right: An unchecked > exception, or, a checked exception / either / whatever other mechanism you > prefer for conveying an expectable alternate result. This implies there are > cases where you get one but wished it was the other and vice versa. Eithers > are a real pain in this regard when trying to composition, because you need > to do more work and the API needs to handle this complication as well: In > practice you want to be able to treat both an Either return *and* an > exceptional return the same way, but as these are two completely different > constructs this is kinda complicated. The easiest way to do it is in fact to > wrap the call in a closer and just throw the alternate result from the > either, at which point we're right back where we started. Exceptions can all > be handled uniformly. > > (HINT: What if you're in scala and composing a parallel sequence and one of > them throws a runtime exception? What happens then? - scala has this > 'problem' too) > I agree, Scala by default also has the issue of handling parallel exceptions, which is why the alternative is available for when you find yourself in that situation. Typically, this kind of problem where you use a checked exception to act as an alternative response and demand immediate handling is located in exactly the kind of code that makes sense to be used with collections. By contrast, something really exceptional (e.g. running out of memory) means that you're hosed regardless of concurrency, best you can do is bail out cleanly and tell the end user. and since when was working with collections particularly unusual anyway? The only rare part here is that I referred to handling elements in parallel, which isn't common practice, yet... > > >> My intent was not to make that aspect of Java syntax look artificially >> bad, but to start with a familiar syntax before migrating to a language that >> already has the functionality I'm advocating. I could have completed the >> whole thing in Java, but it would have required an unwieldy amount of >> supporting code, including either SAM types or the as-yet unfinalized Java 8 >> closure syntax. >> >> > You didn't even read a word that I said. You have the exact same issue in > both scala and java (you want the result of a method call with a parameter > that is itself the result of a method call), but in java you decide to > labouriously create a bunch of final variables to store intermediate > results, but in scala you inline it all, making the scala code look far > smaller than the java code. A casual glance creates the wrong impression. > I made the Java code look quite a bit smaller than it would have been in production, given that I left out the obligatory exception handling. Having ripped that junk out I'm sorry that I then didn't go on to optimize the Java for minimum line count, it wasn't even slightly relevant to the point I was making and I was foolish for not recognising that people might pick up on such a totally insignificant detail to use as a diversion from the message that I considered significant. > > >> Perhaps you could cherry-pick a spelling mistake as well, which would then >> *surely* demonstrate how everything I stated was completely invalid >> >> > You just engaged in the logical fallacy that you're (falsely) accusing me > of. Brilliant. > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- Kevin Wright gtalk / msn : [email protected] <[email protected]>mail: [email protected] vibe / skype: kev.lee.wright quora: http://www.quora.com/Kevin-Wright twitter: @thecoda "My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
