2011/3/28 Cédric Beust ♔ <[email protected]> > > > 2011/3/27 Kevin Wright <[email protected]> > >> >> >> >> >> >> >> Haskell doesn't have this issue, nor does Coq or Agda, all of them >> being far more Nannyish than Java is ways that actually have some proven >> benefit as to improving the quality of your programming >> >> > >> >> > >> >> > I think you just beat a new record in the area of unproven, >> unfalsifiable and frankly ludicrous claims. >> >> > >> >> >> >> Which part is ludicrous? The claim that these languages are more >> restrictive than Java, or the claim that stronger typing improves quality. >> > >> > You didn't make any of these claims in the paragraph I quoted. >> > >> > You did say that all these languages have "proven benefit as to >> improving the quality of your programming". >> > >> > Calling this "ludicrous" is being nice. >> > >> >> So: >> - Checked exceptions are stronger typing (I disagree) >> >> - Stronger typing does not probably improve the quality of your >> programming (I believe it does) >> >> - Yet you are in favour of checked exceptions, believing they do so >> improve quality (I believe they subvert static typing, and so reduce it) >> >> I'm sure I've missed some nuance here, because it's fairly obvious that >> you must have a coherent opinion, and there's a good chance that we actually >> agree on the vast majority of points raised. When you appear to be >> self-contradictory, it's almost certain that any response I give will be to >> my own misunderstanding of your viewpoint, instead of to your actual >> beliefs. >> > > And again, you are writing a wall of text that has absolutely *nothing* to > do with what we were discussing. I'm requoting above the entire thing just > so you can see for yourself, and here, again, are your own words, which I > called ludicrous: > > Haskell doesn't have this issue, nor does Coq or Agda, all of them being > far more Nannyish than Java is ways that actually have some proven benefit > as to improving the quality of your programming > > > Now tell me, how what you wrote above related in any way to this? It > doesn't. It sounds like some knee jerk reaction to something completely > unrelated. > > I know you have a hard time keeping your mind focused on a single thing, so > I made a point of quoting only three lines of your original email, so that > it would be obvious to you what I was responding to. You still missed it by > a mile once, and then missed it by another mile a second time with this > email. > > I think it's just impossible to have a rational discussion with you, at > least not until you learn how to read what you're responding to and then > learn how to stay focused on a topic. > > -- > Cédric > > With director's commentary then:
Haskell doesn't have this issue *[this issue = checked exceptions arising as a result of strong typing]* , nor does Coq or Agda, all of them being far more Nannyish than Java is *[Haskell, for example, forces all side-effects to be handled via specialised monads]* in ways that actually have some proven benefit *[via case studies, academic research, and statistical analysis]* as to improving the quality of your programming *[i.e. making it less prone to some classes of error, by making such errors invalid within the type system]* I'm arguing that checked exceptions are *not* correctly viewed as a form of strong typing when compared to unchecked exceptions. Rather, they're a particularly weak (and easily subverted) form of typing when compared to equivalent behaviour expressed directly in the return type of a method. By way of contrast, I'm further arguing that extra static typing is a good, safe, thing in a great many scenarios and should not be held to blame for the inadequacy of checked exceptions. These only give a facade of offering stronger static typing, which in turn leads all too easily to a false sense of security - it's the weakness of typing and ease of subversion that then makes them such a rich source of anti-patterns. Something like Scala's Either type instead forces you to deal with an alternate return type (including exceptions) directly, without the potential for vanishing from the method signature once you pass through remoting (or another similar layer where some form of marshalling may be involved), and without being wrapped. This encoding of an error condition as a first class citizen in the return type of a method is far less prone to abuse and is impossible to lose in translation, thus making it a safer design pattern. -- 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.
