tag:blogger.com,1999:blog-10345428.post8481038677764717016..comments2023-09-27T00:29:23.437-07:00Comments on Making programming pay: Deep into the Blue with CroquetPaul Beckfordhttp://www.blogger.com/profile/16046651614960778254noreply@blogger.comBlogger51125tag:blogger.com,1999:blog-10345428.post-80574146708333465762007-03-21T00:11:00.000-07:002007-03-21T00:11:00.000-07:00Hi Isaac,There you go. Go review books. At your be...Hi Isaac,<BR/><BR/>There you go. Go review books. At your better moments I have found some of your comments thoughtful too. (Like the word tautology). At other times I believe that you choose not to address the issues, but to persue meaningless arguments using a dialetic style which serves no purpose <B>(like your insistence to misrepresent what I have clearly stated about NullPointerExceptions in Java, and runtime exceptions in general).</B><BR/><BR/>On balance, I think this debate has long past it's usefulness. Thanxs for the debate, but I see no value in persuing it further. Goodbye and good luck!Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-68746930494879393572007-03-20T20:11:00.000-07:002007-03-20T20:11:00.000-07:00paul wrote in comments I would rather trust anythi...paul wrote in comments <I><B>I would rather trust anything Craig Larman had to say</B> then to acredit any credbility to a loony nut like you.</I><BR/><BR/><A HREF="http://www.xprogramming.com/xpmag/gouy.htm" REL="nofollow">Here's what Craig Larman had to say:</A><BR/>"My view is that sotfware engineering shouldn't be religion and should indeed be based on evidence and statistics, and I appreciate Isaac's or anybody's improvements to whatever I wrote. (I hope Isaac may be a reviewer on my next book, because he seems thoughtful)."Isaac Gouyhttps://www.blogger.com/profile/00226627985460018169noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-67624739622707349342007-03-20T18:11:00.000-07:002007-03-20T18:11:00.000-07:00Isaac said:You repeatedly put words into my mouth ...Isaac said:<BR/><BR/><I>You repeatedly put words into my mouth and misrepresent what I and others have written.<BR/><BR/>You repeatedly claim to have demonstrated something without being able to show where.<BR/><BR/>You seem to have no interest in whether what you write has some basis in reality or is blatantly wrong.</I><BR/><BR/>The irony is that everyone of these actions you attribute to me <I>exactly</I> describe your behaviour.<BR/><BR/>I have read about your attack on Craig Larman, and even though I had read his book and found it a great piece of work, I kept an open mind. <B>Now I know!</B> I would rather trust <I>anything</I> Craig Larman had to say then to acredit any credbility to a loony nut like you.<BR/><BR/><B>Make your protest elsewhere. I can't help you.</B>Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-39538191089470263872007-03-20T17:58:00.000-07:002007-03-20T17:58:00.000-07:00Hi Isaac,You are pathetic. I spoke about Java. I a...Hi Isaac,<BR/><BR/>You are pathetic. I spoke about Java. I agreed about <I>other languages</I><BR/><BR/>It is in the record. Here for everyone to see. <B>Please just go away!</B>Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-71454158783739358712007-03-20T15:50:00.000-07:002007-03-20T15:50:00.000-07:00paul wrote in comments My point is that it occurs ...paul wrote in comments <I>My point is that it occurs at runtime and can not be detected by a static type check.</I><BR/><BR/><BR/>class nulltest {<BR/>public static void main(String[] args)<BR/>{<BR/>String s = null;<BR/>System.out.println(s.length());<BR/>}}<BR/><BR/>Exception in thread "main" java.lang.NullPointerException at nulltest.main(nulltest.java:4)<BR/><BR/><BR/><B>#1</B> <BR/>void main(String[] args){<BR/> String s = null;<BR/> println(s.length());<BR/>}<BR/><BR/>line 2, column 11:<BR/>The value null cannot be assigned to s because it might be null.<BR/><BR/><BR/><B>#2</B> <BR/>void main(String[] args){<BR/> ?String s = null;<BR/> println(s.length());<BR/>}<BR/><BR/>line 3, column 14:<BR/>No possible call for length.<BR/>Arguments: (?java.lang.String)<BR/><BR/><BR/><B>#3</B> <BR/>void main(String[] args){<BR/> ?String s = null;<BR/> if (s != null) println(s.length());<BR/>}<BR/><BR/>nulltest: parsing<BR/>nulltest: typechecking<BR/>nulltest: generating code<BR/>nulltest: linking<BR/>nulltest: writing in archive<BR/><BR/>>java -jar nulltest.jar<BR/>><BR/><BR/><BR/><B>#4</B><BR/>void main(String[] args){<BR/> ?String s = "a String";<BR/> if (s != null) println(s.length());<BR/>}<BR/><BR/>nulltest: parsing<BR/>nulltest: typechecking<BR/>nulltest: generating code<BR/>nulltest: linking<BR/>nulltest: writing in archive<BR/><BR/>>java -jar nulltest.jar<BR/>8<BR/>><BR/><BR/>As I said "... it's a programming error that in many cases <B>can be detected by static type checking</B> <I>in other languages</I>."Isaac Gouyhttps://www.blogger.com/profile/00226627985460018169noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-21006685217677946802007-03-20T14:43:00.000-07:002007-03-20T14:43:00.000-07:00paul previously wrote in comments My goal is to co...paul previously wrote in comments <I>My goal is to communicate and exchange ideas.</I><BR/><BR/>paul wrote in comments <I>It is clear to me that all you want to do is argue.</I><BR/><BR/><B>argue: exchange view or opinions</B><BR/>Oxford English DictionaryIsaac Gouyhttps://www.blogger.com/profile/00226627985460018169noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-89161346017357921842007-03-20T11:40:00.000-07:002007-03-20T11:40:00.000-07:00Paul said...I have made no claims. I have merely s...Paul said...<BR/>I have made no claims. I have merely stated opnions. Incidently it is still unclear to me what exactly about what I've said you disagree with.<BR/><BR/>.. You have said that the word oxymorom is inappropriate and I agreed.<BR/><BR/>..You have said that type safety and program correctness are orthogonal concerns, and I have agreed with this too.<BR/><BR/>... You have given several definitions of type safety, which once we cleared up the ambguity I agree with also.<BR/><BR/>...You now want to argue with me over whether NullPointerException is a rumtime exception or a type miss-match.<BR/><BR/><B>Frankly I don't care. My point is that it occurs at runtime and can not be detected by a static type check.</B><BR/><BR/>It is clear to me that all you want to do is argue. Well I'm tired so please go argue with someone else!Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-17302247022863782512007-03-20T10:51:00.000-07:002007-03-20T10:51:00.000-07:00paul wrote in comments To be honest I'm tired of t...paul wrote in comments <I>To be honest I'm tired of this ... I would rather talk about Croquet.</I><BR/><BR/>You repeatedly put words into my mouth and misrepresent what I and others have written.<BR/><BR/>You repeatedly claim to have demonstrated something without being able to show where.<BR/><BR/>You seem to have no interest in whether what you write has some basis in reality or is blatantly wrong.<BR/><BR/>I have no reason to think that you would behave any differently if the subject was Croquet.Isaac Gouyhttps://www.blogger.com/profile/00226627985460018169noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-25688649854141113292007-03-20T10:34:00.000-07:002007-03-20T10:34:00.000-07:00paul wrote in comments dislike of the term Type Sa...paul wrote in comments <I>dislike of the term Type Safety ... Your definition: A programs that does not cause untrapped errors.</I><BR/>Please show where I used that definition of type safety - I have consistently referred to Krishnamurthi's definition and Cardelli's definition.<BR/><BR/>paul wrote in comments <I>I will assume that you mean untrapped type errors, otherwise like I've pointed out already your definition doesn't make sense.</I><BR/>You've already seen <A HREF="http://pab-data.blogspot.com/2007/03/type-safety-oxymoron.html#comment-7065979080969298708" REL="nofollow">a definition for untrapped error</A>, please show where you pointed out that definition doesn't make sense.Isaac Gouyhttps://www.blogger.com/profile/00226627985460018169noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-38385667034910751162007-03-20T10:08:00.000-07:002007-03-20T10:08:00.000-07:00paul wrote in comments Null has no type in Java .....paul wrote in comments <I>Null has no type in Java ...</I><BR/><B>You are mistaken.</B><BR/>"There is also a special null type, the type of the expression null, ... The null reference is the only possible value of an expression of null type." Java Language Specification<BR/><BR/>paul wrote in comments <I>Null has no type in Java and is not a variable in Java.</I><BR/>Please show where I said null was a variable.Isaac Gouyhttps://www.blogger.com/profile/00226627985460018169noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-83158917374958238552007-03-20T09:55:00.000-07:002007-03-20T09:55:00.000-07:00Hi Isaac,So you stand by your original views on ty...Hi Isaac,<BR/><BR/>So you stand by your original views on type safety and program correctness. That is good to hear, because I actually think you are right here.<BR/><BR/>To be honest I'm tired of this, and I have satisifed myself about Type Safety and it's usefulness. How about writing a blog post of your own on type safety if you so desire? I would rather talk about Croquet.Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-59406191937868475742007-03-20T09:43:00.000-07:002007-03-20T09:43:00.000-07:00So you agree that your comment that NullPointerExc...<I>So you agree that your comment that NullPointerException has nothing to do with types is completely wrong?</I><BR/><BR/>I can see this debate has served it's usefulness :^) For Java NullPointerException is a runtime exception, which by definition can only be detected at runtime, and cannot be detected by a static type check. Null has no type in Java and is not a variable in Java. It stands in for an undefined variable.<BR/><BR/>I'm sure you know this. Or maybe you don't?Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-75835486181398175562007-03-20T09:23:00.000-07:002007-03-20T09:23:00.000-07:00paul wrote in comments Now your views on the diffe...paul wrote in comments <I>Now your views on the difference beween type safety and program correctness ... Have you changed your mind? Or is this just blatant opportunism?</I><BR/><BR/>I guess you think there's some kind of contradiction between those quotes and something else. What is this contradiction you imagine - you haven't actually told us?Isaac Gouyhttps://www.blogger.com/profile/00226627985460018169noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-4358666537756520142007-03-20T09:14:00.000-07:002007-03-20T09:14:00.000-07:00paul wrote in comments There are several common er...paul wrote in comments <I>There are several common errors that have nothing to do with types that will can lead to incorrect behaviour. A common example for Java is null pointer exceptions.</I><BR/><BR/>paul wrote in comments <I>If Java's null was a true object like Nil in Smalltalk then true null pointer could be avoided by using the type system.</I><BR/><BR/>So you agree that your comment that NullPointerException has nothing to do with types is <B>completely wrong</B>?Isaac Gouyhttps://www.blogger.com/profile/00226627985460018169noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-10754842813975917852007-03-20T00:35:00.000-07:002007-03-20T00:35:00.000-07:00Hi Isaac,... As for my dislike of the term Type Sa...Hi Isaac,<BR/><BR/>... As for my dislike of the term Type Safety, you only have to look at this blog to see why it is a poor term. There are as many opinions of what it means as people. Your definition:<BR/><BR/><I> A programs that does not cause untrapped errors.</I><BR/><BR/>Is ambiguous. I will assume that you mean <I>untrapped type errors</I>, otherwise like I've pointed out already your definition doesn't make sense.<BR/><BR/>Steve seems to think that you can express user requirements using mathematics, and some how type safety addresses <I>requirement analysis errors</I>. I won't comment on this view.<BR/><BR/>The best definition I've come across is the one on the C2 wiki:<BR/><BR/><I>Any declared variable will always reference an object of either that type or a subtype of that type. </I><BR/><BR/>But they quickly go on to break this definition down into lesser partial forms, because they accept that in practice full type safe languages do not exist.<BR/><BR/>I think this discussion about Type Safety speaks volumes, and makes my point.Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-30194846357850197832007-03-20T00:13:00.000-07:002007-03-20T00:13:00.000-07:00Hi Isaac,Not only is a NullPointerException an exa...Hi Isaac,<BR/><BR/><I>Not only is a NullPointerException an example of a type error, it's a programming error that in many cases can be detected by static type checking in other languages.</I><BR/><BR/>If Java's null was a true object like Nil in Smalltalk then true null pointer could be avoided by using the type system. Strongtalk does this.<BR/><BR/>What I am talking about is runtime exceptions like the one that took out Ariane 5. Now your views on the difference beween type safety and program correctness have been recorded on this blog.:<BR/><BR/><I>Type safety does not decrease the risk that something might go wrong - type safety decreases the risk of bad stuff happening when something does go wrong.</I><BR/><BR/>and<BR/><BR/><I>type safety is about what happens when your program has a particular kind of error, not about whether it has a particular kind of error. <BR/><BR/>afaict what you mean by program safety is no different from what everyone else calls program correctness, and it has nothing to do with type safety.</I><BR/><BR/>Have you changed your mind? Or is this just blatant opportunism?<BR/><BR/>What do you think about Croquet BTW?Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-23206950185632206562007-03-19T23:27:00.000-07:002007-03-19T23:27:00.000-07:00paul wrote in comments There are several common er...paul wrote in comments <I>There are several common errors that have nothing to do with types that will can lead to incorrect behaviour. A common example for Java is null pointer exceptions.</I><BR/><B>You are mistaken.</B><BR/>Not only is a NullPointerException an example of a type error, it's a programming error that in many cases can be detected by static type checking in other languages.Isaac Gouyhttps://www.blogger.com/profile/00226627985460018169noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-86118338858288081062007-03-19T22:36:00.000-07:002007-03-19T22:36:00.000-07:00paul wrote in comments My difficulty with the term...paul wrote in comments <I>My difficulty with the term type safety...</I><BR/>It seems like your difficulty with the term type safety is the same as your difficulty with the word oxymoron - you don't actually understand (or prefer not to understand) what it means.<BR/><BR/><BR/>paul wrote in comments <I>My difficulty with the term type safety is the use of the word safety. The word has a conitation that ...</I><BR/>Seems like you have taken the word "safety" out of context, ignored it's primary and secondary meanings, and fixated on a single connotation - how incredibly bizarre.Isaac Gouyhttps://www.blogger.com/profile/00226627985460018169noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-23416084866566101582007-03-19T17:08:00.000-07:002007-03-19T17:08:00.000-07:00Hi Isaac,I've looked up tautology, and I see where...Hi Isaac,<BR/><BR/>I've looked up <I>tautology</I>, and I see where you are coming from and it is close, but it doesn't quite express what I mean either.<BR/><BR/>My difficulty with the term <I>type safety</I> is the use of the word <I>safety</I>. The word has a conitation that infers <I>freedom from fear</I>.<BR/><BR/>Fear is a strong motivator. And talk of type safety is often associated with programmers fears. A lack of program correctness is a primary fear for most programmers, and colloquially type safety is seen as a technique that at least in part addresses this fear. I just think <I>Type Safety</I> is an unfortunate term. 'Type checked', is better because it indicates that a certain type of error is being checked for, but does not imply that the program is safe in anyway.<BR/><BR/>It is interesting the emotion the word <I>safety</I> can trigger. In an academic sense type safety doesn't mean much (using your defintion, or the one on the c2 wiki). But colloquially <I>type safety</I> evidently means a lot more then either of our definitions state. At least Steve, and Mess seem to think so.Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-77583088532075904592007-03-19T16:32:00.000-07:002007-03-19T16:32:00.000-07:00Hi Steve,... You claim that what I have said about...Hi Steve,<BR/><BR/>... You claim that what I have said about requirements analysis, design specification and types is <I>nonsense</I>. Like I said I'm not trying to convince you. As for academics, no slur was intended.<BR/><BR/>... What about the rest of my post? Did you read the article on Croquet? What do you think?Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-66236946674648946232007-03-19T14:59:00.000-07:002007-03-19T14:59:00.000-07:00"They didn't test because they didn't choose to te..."They didn't test because they didn't choose to test."<BR/><BR/>There little difference between didn't choose and didn't know - both illustrate the problem about reliance on developers.<BR/><BR/>"No way would a static type check be able to detect subtle differences in hardware - yet they were lulled into a false sense of security that cost millions."<BR/><BR/>Actually, a static type check certainly could detect 'subtle' differences in hardware (like the difference between 64-bit and 16-bit).<BR/><BR/>"The reason why a programmer would not test against the design requirement for Currency, is because it wasn't specified and he didn't know."<BR/><BR/>No, this is rubbish. The programmer did not test against the design requirement for Currency not because it wasn't specified, but because the programmer was not qualified to work in this area. In the area of finance, the requirement for Currency is patently obvious. Would someone have to specify the use of an 'int' for a loop?<BR/><BR/>"This is why your proof argument is flawed. Some one needs to talk to the customer and interpret requirements, and create a design. The logic in this interpretation may have gaps, or be flawed. You cannot perform a static check against verbal requirements."<BR/><BR/>This is total nonsense, and I can't believe I am reading such a defence of incompetence! For anyone who has anything to do with financial software, the use of Currency types is essential. I have provided you with links to show this. You no more need to discuss this in terms of design than you need to talk about not using cardboard to build cars! It is ludicrous to talk of anyone having to 'talk about customer requirements' to deal with currency correctly. There certainly is a static request available for verbal requirements. The customer says "This is a program that deals with currency", and the test is to use BigDecimal. <BR/><BR/>"I am not making an academic argument, I am talking from real world experience."<BR/><BR/>You think that is some kind of <I>positive</I> argument?<BR/><BR/>This is yet another slur against academics. Sooner or later you will realise that academic work in this area is founded on vastly more real world experience than you have, and perhaps then you will learn a little humility and realise that thousands of people have studied this area and know far more about this than you (or I!).<BR/><BR/>I have lost patience with this, as you seem to be learning nothing from these discussions. <BR/><BR/>Isaac has given me things to look up, which is useful, but other than that, I see no merit in continuing this debate. All the answers to your questions are easily accessible.<BR/><BR/>And as Isaac says, I really don't think you understand what 'oxymoron' means....Steve Zarahttps://www.blogger.com/profile/16867968082532563442noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-1701235006195465712007-03-19T13:41:00.000-07:002007-03-19T13:41:00.000-07:00me22 wrote I figured I'd post the prof's definitio...me22 wrote <I>I figured I'd post the prof's definition ...</I><BR/>Seems to be the same as the definition of <I>type soundness</I> p261 <A HREF="http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/" REL="nofollow">Programming Languages: Application and Interpretation</A>Isaac Gouyhttps://www.blogger.com/profile/00226627985460018169noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-83363507858283339822007-03-19T13:25:00.000-07:002007-03-19T13:25:00.000-07:00Hi Isaac,Steve's argument is that static type chec...Hi Isaac,<BR/><BR/><I>Steve's argument is that static type checking demonstrates the absence of a particular category of program error - and thereby contributes to demonstrations of program correctness.</I><BR/><BR/>I agree that static type checks can eliminate a certain category of error, but that still leaves the majority of potential errors undetected (all runtime exceptions for example).I have spoken about static type checking and it's limits. I have given examples such as the Ariane 5 example. I have stated my preference for tests irrespective of the use of static type checking or not.<BR/><BR/>To me it is quite clear. What is your take?Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-60176125885163085072007-03-19T12:56:00.000-07:002007-03-19T12:56:00.000-07:00paul wrote in comments True, what would a better t...paul wrote in comments <I>True, what would a better term be?</I><BR/><BR/>Tautology.<BR/><BR/>Stating that wearing a seatbelt doesn't imply that we won't be in an accident is true but redundant.<BR/><BR/>Stating that type safety doesn't imply program correctness is true but redundant.<BR/><BR/>(Where type safety means <I>The property stating that programs do not cause untrapped errors.</I>)<BR/><BR/>It would be much better to talk about one of the techniques used to implement type safety - <B>static type checking</B>.<BR/><BR/><BR/>Steve's argument is that <B>static type checking</B> demonstrates the absence of a particular category of program error - and thereby contributes to demonstrations of program correctness.Isaac Gouyhttps://www.blogger.com/profile/00226627985460018169noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-65141551866642860642007-03-19T12:52:00.000-07:002007-03-19T12:52:00.000-07:00Hi Steve,This is the conclusion of the report on t...Hi Steve,<BR/><BR/>This is the conclusion of the report on the Ariane 5 disaster:<BR/><BR/> <I>This loss of information was due to <B>specification and design errors</B> in the software of the inertial reference system.<BR/> The extensive reviews and tests carried out during the Ariane 5 Development Programme <B>did not include adequate analysis and testing</B> of the inertial reference system or of the complete flight control system, which could have detected the potential failure.</I><BR/><BR/>The use the same words I have been using. Type safety cannot eliminate human error.Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.com