tag:blogger.com,1999:blog-10345428.post1282356555393392080..comments2023-09-27T00:29:23.437-07:00Comments on Making programming pay: Type safety, An Oxymoron?Paul Beckfordhttp://www.blogger.com/profile/16046651614960778254noreply@blogger.comBlogger74125tag:blogger.com,1999:blog-10345428.post-65122393287545134622007-11-05T17:13:00.000-08:002007-11-05T17:13:00.000-08:00Why would you want to write tests for something (t...Why would you want to write tests for something (type safety) that the compiler can check for you?<BR/><BR/>If the compiler (even partially) makes sure the correct types are used, you don't need to test these cases manually. So it makes life easier for the programmer and of course it's nice to have.<BR/><BR/>Btw: Haskell (http://www.haskell.org/) is a statically typed language and there the compiler can catch a lot of errors you would otherwise need to test for.sthhttps://www.blogger.com/profile/04433365330701132062noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-52632366413360972822007-03-19T14:07:00.000-07:002007-03-19T14:07:00.000-07:00paul wrote in comments "This is why I was so peeve...paul wrote in comments "This is why I was so peeved, by your intital tone, and in case you haven't noticed, my starting place is <I>I don't know</I>."<BR/><BR/>Perhaps you do believe that your "starting place is I don't know" but <B>any honest scrutiny of your comments on this blog would overturn that belief</B>.<BR/><BR/><BR/>paul wrote previously in comments <I>... I have no reason to take back my comments, since despite several attempts you still fail to grasp the basis of the argument ...</I><BR/><BR/>Please show how the example of Java not using structural typing has been "ripped to threads".<BR/><BR/>Please show how the "quotes of other peoples ideas and opinions have been ripped to threads".Isaac Gouyhttps://www.blogger.com/profile/00226627985460018169noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-65506760474523938102007-03-19T13:31:00.000-07:002007-03-19T13:31:00.000-07:00paul wrote in comments I want to rephrase your com...paul wrote in comments <I>I want to rephrase your comment. It wasn't testing that proved insufficient, but the tester.</I><BR/><BR/><B>You are mistaken.</B><BR/><BR/>You seem not to understand the most basic truth of testing - <I>"Program testing can be used to show the presence of bugs, but never to show their absence!"</I> E.W.Dijkstra, 1972.Isaac Gouyhttps://www.blogger.com/profile/00226627985460018169noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-47255553983535633242007-03-19T01:17:00.000-07:002007-03-19T01:17:00.000-07:00Hi Isaac,Read a bit more about the Haskell recursi...Hi Isaac,<BR/>Read a bit more about the Haskell recursive bug. What I found most interesting was Ron's open and honest nature. His willingness to share his code, and accept criticism and input from others. This comes from his values I believe. I have debated with Ron on several Agile forums and this comes across. So despite all his experience, he is willing to start from a postion of not knowing. He is happy to say I haven't got all the answers.<BR/><BR/>This attitude can result in a culture where others feel safe in sharing their uncertainty too. Software development is hard, and pretending that we have all the answers doesn't help. Being able to say, I don't know, and I could do with some help here is a great bonus. Unfortunately, amongst many in the software industry, this type of openess is a sign of weakness leaving you open to attack, but I see it as a sign of strength.<BR/><BR/>This is why I was so peeved, by your intital tone, and in case you haven't noticed, my starting place is <I>I don't know</I> .Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-18312994813567878582007-03-19T00:35:00.000-07:002007-03-19T00:35:00.000-07:00Hi Isaac,Well spotted. Interestingly it was the Ha...Hi Isaac,<BR/><BR/>Well spotted. Interestingly it was the Haskell recursive version that had the flaw. Unlike the imperative language implementations, I guess that this was the only version that could have been proven correct or incorrect mathematically (not sure need to look at it in detail).<BR/><BR/>... I want to rephrase your comment. It wasn't testing that proved insufficient, but the tester. It was a test in the Ruby version by another tester, that revealled the flaw in the Haskell recursive code.<BR/><BR/>...This is a <B>very</B> important point. The most important contributing factor to program safety is the programmer. Tests in themselves are no guarantee. What is important is the person doing the testing, and the skills and experience that can be brought to bare.<BR/><BR/>This is why Agile development values people over tools. Even the best tester can have a bad day, which is why team work is beter than relying on any single individual.<BR/><BR/>So in this instance Tests + Common Code Ownership detected the flaw. It was through sharing the code on the web that Dan and Ron, discovered the bug with the help of others.<BR/><BR/>After all this talk of type safety, and program corectness - we often tend to forget these human factors. Program safety as I have defined it, IMO is best served by a set of values and principles observed by a team of people and supported by the tools. The values, principles, and people are the critical factors, tools are secondary.Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-15602063106959070992007-03-18T19:55:00.000-07:002007-03-18T19:55:00.000-07:00paul wrote previously in comments Ron Jefferies ha...paul wrote previously in comments <I>Ron Jefferies has created a series of 'bowling' example programs ... All versions of TDD bowling are safe, which dispells the myth that type safety correlates with program safety.</I><BR/><BR/><B>You are mistaken</B> <A HREF="http://www.xprogramming.com/xpmag/dbcHaskellHassle.htm" REL="nofollow">testing was insufficient</A> - some programs were not correct.Isaac Gouyhttps://www.blogger.com/profile/00226627985460018169noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-79770848155616740132007-03-17T09:52:00.000-07:002007-03-17T09:52:00.000-07:00paul wrote in comments ... I'll just state this si...paul wrote in comments <I>... I'll just state this simple point once again: A Class (implementation) is not a Type (Interface). No number of quotes will persuade me otherwise.</I><BR/>Please show where I said a class was the same as a type.<BR/><BR/><B>For the entire length of your programming career the reasons why a class is not a type have been well understood.</B><BR/><BR/>As you might have guessed from the title, William Cook's paper (the "quotes"?) explains why a class is not a type.Isaac Gouyhttps://www.blogger.com/profile/00226627985460018169noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-57287026764262159212007-03-16T18:20:00.000-07:002007-03-16T18:20:00.000-07:00...I agree that Type safety does not infer program......I agree that Type safety does not infer program correctness. I have bloggd as such. Stee Zara has provide an example of where type safety 'assists' with program correctness. I have conceeded this to be true, but I see it as more of a side effect of the confusion of Classes with Types in languages like Java. I have offered Strongtalks Manfiest Type System as an example of a conceptually sound alternative.<BR/><BR/>... I'll just state this simple point once again: A Class (implementation) is not a Type (Interface). No number of quotes will persuade me otherwise.<BR/><BR/>... By your own definition type safety does not exist. It is a conceptual idea that breaks down when it comes to creating a practical language implemention. As stated in my blog all common programming languages are partially type safe.<BR/><BR/>... I have no reason to take back my comments, since despite several attempts you still fail to grasp the basis of the argument (which incidently as already been debated and concluded!). Either state in your own words why you disagree with what I have said above, or give up.Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-74717963387804236922007-03-16T13:00:00.000-07:002007-03-16T13:00:00.000-07:00paul wrote in comments Thanks for the constructive...paul wrote in comments <I>Thanks for the constructive tone. My tone will be as equally constructive.</I><BR/><BR/>paul previously wrote in comments <I>I guess I'm picking on you, but you're just too easy a target. Funny that the moment you present original thought of your own (your Java Class A and B example), it's ripped to threads. Even your qoutes of other peoples ideas and opinions have been ripped to threads too.</I><BR/><BR/>Those are malicious remarks.<BR/><BR/>Please show how the example of Java not using structural typing has been "ripped to threads".<BR/><BR/>Please show how the "quotes of other peoples ideas and opinions have been ripped to threads".<BR/><BR/>Or retract those malicious remarks.Isaac Gouyhttps://www.blogger.com/profile/00226627985460018169noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-12671771961665426772007-03-16T12:46:00.000-07:002007-03-16T12:46:00.000-07:00paul wrote in comments ..I think you missed the po...paul wrote in comments <I>..I think you missed the point about a Class not being a Type. Briefly, a Class is a ...</I><BR/><BR/>My specific question was "does Java accept instances of A and B as the same type?" and you replied <I>"Yes, this was the point raised by Steve Zara, made after my original post, which I have conceeded to be true."</I><BR/><BR/><BR/>It's been nearly 2 decades since William Cook wrote <A HREF="http://www.cs.utexas.edu/~wcook/papers/InheritanceSubtyping90/CookPOPL90.pdf" REL="nofollow">Inheritance is not subtyping</A>.<BR/><BR/><A HREF="http://www.jot.fm/jot/issues/issue_2002_05/column5/index_html" REL="nofollow">"The Theory of Classification"</A> is a series of articles on object-oriented type theory, aimed specifically at non-theoreticians.Isaac Gouyhttps://www.blogger.com/profile/00226627985460018169noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-10611170371971587442007-03-16T12:09:00.000-07:002007-03-16T12:09:00.000-07:00paul wrote in comments ..Yes, my central point is ...paul wrote in comments <I>..Yes, my central point is with regards to program correctness. Type safety is a poor cousin to program correctness IMO</I><BR/><BR/>Once again, type safety is <B>not related</B> to program correctness.<BR/><BR/>Let's try a simple analogy - passenger safety in cars - safety from bad stuff happening when something goes wrong. Seatbelts are a way to increase passenger safety, and air-bags are a way to increase passenger safety. <BR/><BR/>Neither wearing a seatbelt nor having an air-bag decrease the risk that something might go wrong. They both decrease the risk of bad stuff happening when something does go wrong.<BR/><BR/>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.<BR/><BR/><BR/>paul wrote in comments <I>Type safety is a poor cousin to program correctness IMO, hence the title of my post (Is Type Safety and Oxymoron?).</I><BR/><BR/>In the blog entry you wrote <I>"No program is Type Safe, and to claim so is a bit of an oxymoron"</I> - that is an example of confusing type safety with program correctness. Any program written in a type safe language is type safe - that does not mean the program does not have errors, it means there's a limit to the damage those errors can do.<BR/><BR/>Being confused about what type safety means does not make type safety an oxymoron.Isaac Gouyhttps://www.blogger.com/profile/00226627985460018169noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-81407376754116334352007-03-15T23:51:00.000-07:002007-03-15T23:51:00.000-07:00Hi Isaac,Thanks for the constructive tone. My tone...Hi Isaac,<BR/><BR/>Thanks for the constructive tone. My tone will be as equally constructive. <BR/><BR/>..Yes, my central point is with regards to program correctness. Type safety is a poor cousin to program correctness IMO, hence the title of my post (Is Type Safety and Oxymoron?).<BR/><BR/>..I think you missed the point about a Class not being a Type. Briefly, a Class is a concrete implementation of an Interface Contract. That same contract could be implemented several ways. I see the interface contract as the Type, not a given concrete Implementation. Duck typing and early bound manifestly typed languages like Java check and enforce interface contracts (Types) differently, with diferent assumptions and different consequences. IMO the Java type system is restrictive and leads to excessive coupling. Steve Zara was arguing that duck typing is too loose. I have described the Strongtalk Type System as an example where I believe you can gain the best of both approaches.Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-27878014275550717632007-03-15T16:11:00.000-07:002007-03-15T16:11:00.000-07:00paul wrote in comments So type safety does not inf...paul wrote in comments <I>So type safety does not infer program safety as I have defind it.</I><BR/>As I've already said: <BR/><B>type safety</B> is about <I>what happens</I> when your program has a particular kind of error, not about whether it has a particular kind of error. <BR/><BR/><I>afaict</I> what you mean by <I>program safety</I> is no different from <B>what everyone else</B> calls <I>program correctness</I>, and it has nothing to do with type safety.<BR/><BR/><BR/>paul wrote in comments <I>So If there is an error in my logic in my code resulting in incorrect behaviour, and hence an error, then my Type Safe language will detect it will it?</I><BR/>If your logic error causes an error forbidden in the language and the language is safe then the forbidden error will be detected. That is not the same as detecting your logic error.<BR/><BR/><BR/>paul wrote in comments <I>So by your definition a dynamically type safe language like Smalltalk is correct in accepting A as equivalent to B. So are A and B equivalent or aren't they? This is why we have distinguished between static type safety and dynamic type safety.</I><BR/>Neither Krishnamurthi's nor Cardelli's definitions of type safety have anything to say about whether a particular type safe language should accept instances of A and B as the same type.<BR/><BR/>Type compatibility and equivalence are orthogonal properties to type safety.<BR/><BR/>And I haven't confused type safety with static type checking and dynamic type checking, even if you have.<BR/><BR/><BR/>paul wrote in comments <I>Firstly a Class is not a Type. In Java Class A and Class B could be ...</I><BR/>You have already conceeded this point - the type system is based on the name of types not the structure of types.Isaac Gouyhttps://www.blogger.com/profile/00226627985460018169noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-77991695252386131382007-03-15T14:56:00.000-07:002007-03-15T14:56:00.000-07:00paul made a sequence of ad hominem remarks "This i...paul made a sequence of ad hominem remarks <BR/><I>"This is where you've got to put down the reference manual and start thinking for yourself"</I><BR/>...<BR/><I>"Isaac, you are not thinking. Too busy trying to score points and boost your Ego. If you can't do better I won't be responding to your comments in feature. Your input lacks Quality and does not add Value to the debate"</I><BR/>...<BR/><BR/>Those are not the comments of someone whose "goal is to communicate and exchange ideas".<BR/><BR/>I suggest you imagine I had addressed those comments to you.Isaac Gouyhttps://www.blogger.com/profile/00226627985460018169noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-79668055726324544552007-03-15T14:37:00.000-07:002007-03-15T14:37:00.000-07:00paul wrote in comments I don't mind educating you,...paul wrote in comments <I>I don't mind educating you, but it would be so much easier if you showed a little humility. It is this lack of humility and arrogant tone that gets to me!</I><BR/><BR/>Those comments presume the other person lacks knowledge and presume you to be the knowledgeable teacher who will educate them.<BR/><BR/>Those are not the comments of someone whose "goal is to communicate and exchange ideas".<BR/><BR/>I suggest you imagine I had addressed those comments to you.Isaac Gouyhttps://www.blogger.com/profile/00226627985460018169noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-84354486579776181472007-03-15T14:19:00.000-07:002007-03-15T14:19:00.000-07:00paul wrote in comments Caml is the only functional...paul wrote in comments <I>Caml is the only functional language I've tried. ... does this make it an example of a pure functional language? I'm not sure, and if I stated this in error thanks for the correction.</I><BR/><BR/>You contrasted "an imperative program" with "pure functional languages like caml (no side effects ..." when simply reading <A HREF="http://caml.inria.fr/" REL="nofollow">"What is Caml?"</A> would tell you that Caml supports imperative programming, this is an egregious mistake.Isaac Gouyhttps://www.blogger.com/profile/00226627985460018169noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-27846464763314615032007-03-15T01:14:00.000-07:002007-03-15T01:14:00.000-07:00Hi Isaac,Why do you continue to claim that caml is...Hi Isaac,<BR/><BR/><I>Why do you continue to claim that caml is a "pure functional language" - do you have a problem admitting and correcting factual errors?</I>.<BR/><BR/> I mentioned Caml once as an example to distinguish imperative programming from functional programming with respect to program correctness. Caml is the <I>only</I> functional language I've tried. (I don't see Common Lisp as a purely functional language).<BR/><BR/>TheCaml tutorial I used said that it supported a pure functional style, does this make it an example of a pure functional language? I'm not sure, and if I stated this in error thanks for the correction. <BR/><BR/>But you haven't corrected me tough have you? You could have stated an example of a pure functional language and why Caml doesn't qualify, but you haven't. You could have even responded to the substance of my comment and overlooked this erroneous example which I used to make a broader point, but again you didn't. So I am saying rather than throw stones, question your own motives, and the Quality of your discourse and what if anything you are contributing!Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-91435226684651186102007-03-15T00:54:00.000-07:002007-03-15T00:54:00.000-07:00Hi Isaac,I guess I'm picking on you, but you're ju...Hi Isaac,<BR/><BR/>I guess I'm picking on you, but you're just too easy a target. Funny that the moment you present original thought of your own (your Java Class A and B example), it's ripped to threads. Even your qoutes of other peoples ideas and opinions have been ripped to threads too.<BR/><BR/>I don't mind educating you, but it would be so much easier if you showed a little humility. It is this lack of humility and arrogant tone that gets to me!<BR/><BR/>I see it in programmers all the time, and I believe it to be a significant factor in the general poor quality of Software. The people writing the Software can't admit to themselves that maybe they don't know, and perhaps they should ask questions and listen, and perhaps they should write a test to be sure and perhaps by running the test they may learn something.<BR/><BR/>Please dwell on my words before responding. Humility is important for all of use, including you!Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-10076148735605752412007-03-14T19:50:00.000-07:002007-03-14T19:50:00.000-07:00Hi Isaac,Java, create classes A and B subclasses o...Hi Isaac,<BR/><BR/><I>Java, create classes A and B subclasses of Object - they have the same structure - does Java accept instances of A and B as the same type? (Nominal type system.</I><BR/><BR/>Well we have already covered this earlier in the debate, if you had taken the time to read you would know. But let's cover it again for your benefit.<BR/><BR/>Firstly a Class is not a Type. In Java Class A and Class B could be the same Type and share a common Interface. If you specifiy an Interfcae say InterfaceC which is implemented by both classes then A and B can be equivalent and interchanged where InterfaceC is specified as the required type. In other situations where a specific implementation, Class A or Class B is specified they can't.<BR/><BR/>I Said:<BR/><BR/><I>So are A and B equivalent or aren't they? </I><BR/><BR/><BR/>Well Sometimes you do want equivalence and sometimes you don't. Duck typing assumes equivalence if the two classes are structurally the same type. Strongtalk goes one better by defining a Type (Protocol) per class automatically. So Type A and Type B become true seperate types in the Type system. In Strongtalk Class A implements Type A automatically, but can also be made to implement Type B too, making Class A an implementation of Type A and of Type B. The same could be done with Class B also.<BR/><BR/>BTW. What is a nominal type system? (This is a chance to redeem yourself :^))Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-43296020232125886682007-03-14T18:54:00.000-07:002007-03-14T18:54:00.000-07:00Hi Isaac,Java, create classes A and B subclasses o...Hi Isaac,<BR/><BR/><I>Java, create classes A and B subclasses of Object - they have the same structure - does Java accept instances of A and B as the same type? (Nominal type system.</I><BR/><BR/>Yes, so lets compare this to your definition of type safety:<BR/><BR/><I>Type safety: The property stating that programs do not cause untrapped errors.</I><BR/><BR/>So by your definition a dynamically type safe language like Smalltalk is correct in accepting A as equivalent to B. So are A and B equivalent or aren't they? This is why we have distinguished between static type safety and dynamic type safety.<BR/><BR/>Isaac, you are not thinking. Too busy trying to score points and boost your Ego. If you can't do better I won't be responding to your comments in feature. Your input lacks Quality and does not add Value to the debate.Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-60595177386199753242007-03-14T18:36:00.000-07:002007-03-14T18:36:00.000-07:00Hi Isaac,Coming back to your definitive factual de...Hi Isaac,<BR/><BR/>Coming back to your <I>definitive factual</I> definitions:<BR/><BR/><I>Type safety: The property stating that programs do not cause untrapped errors.</I><BR/><BR/>So If there is an error in my logic in my code resulting in incorrect behaviour, and hence an error, then my Type Safe language will detect it will it?<BR/><BR/>This is where you've got to put down the reference manual and start thinking for yourself :^).Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-31871566358397198802007-03-14T18:16:00.000-07:002007-03-14T18:16:00.000-07:00Hi Isaac,Type safety: The property stating that pr...Hi Isaac,<BR/><BR/><I>Type safety: The property stating that programs do not cause untrapped errors.</I><BR/><BR/>Yes, but we have broken this down to where the error is trapped, either statically (compile time) or dynamically (runtime). We have also discussed the advantages/disadvantages of trapping errors at compile time versus runtime.<BR/><BR/>Having trapped an error, our user is still without a correctly operating program as originally specified. This is what I mean by program safety.<BR/><BR/>So type safety does not infer program safety as I have defind it. This is where tests, my executable specification step in.<BR/><BR/>Do you disagree?Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-81375141168209924542007-03-14T17:48:00.000-07:002007-03-14T17:48:00.000-07:00Hi Isaac,Java, create classes A and B subclasses o...Hi Isaac,<BR/><BR/><I>Java, create classes A and B subclasses of Object - they have the same structure - does Java accept instances of A and B as the same type? (Nominal type system.</I><BR/><BR/>Yes, this was the point raised by Steve Zara, made after my original post, which I have conceeded to be true.<BR/><BR/>This is the purpose of producive debate where people discuss what they think and exchange ideas. <BR/><BR/>You use the word fact as if there is this great reference book in the sky defining all known facts. The truth is there isn't. What there is are opinions, and ideas, some published some not.<BR/><BR/>You would gain a lot more credibility in my eyes if you could actually state your own opinion and why you believe what you do!Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-70659790809692987082007-03-14T15:36:00.000-07:002007-03-14T15:36:00.000-07:00paul wrote Still throwing stones...Why would I thr...paul wrote <I>Still throwing stones...</I><BR/>Why would I throw stones - you've already broken the glass.<BR/><BR/>Why do you continue to claim that caml is a "pure functional language" - do you have a problem admitting and correcting factual errors?<BR/><BR/><BR/>paul wrote <I>Any way let me address your points..<BR/>... Well since I write my tests before I write code, it is impossible to detect errors in code that doesn't yet exist. My test are an executable specification for the code to be.</I><BR/>And that still has nothing to do with type safety (and that was my original point).<BR/><BR/><BR/>Is the "Handbook of Computer Science and Engineering" definitive enough for you?<BR/><A HREF="http://citeseer.ist.psu.edu/cardelli97type.html" REL="nofollow">In Chapter 103, Cardelli</A> helpfully defines: <BR/><B>Safe language</B>: A language where no untrapped errors can occur.<BR/><B>Type</B>: A collection of values. An estimate of the collection of values that a program fragment can assume during program execution.<BR/><B>Type safety</B>: The property stating that programs do not cause untrapped errors.<BR/><B>Typing error</B>: An error reported by a typechecker to warn against possible execution errors.<BR/><B>Untrapped error</B>: An execution error that does not immediately result in a fault.<BR/><I>etc</I><BR/><BR/>paul wrote <I>... So we are back to word games :^)</I><BR/>As much of your blog entry is about the meaning of type safe, and your "goal is to communicate and exchange ideas" it's surprising to me that you characterize the distinction between nominal typing and structural typing as a word game.<BR/><BR/><BR/>paul wrote <I>Yes, and types have structure and behaviour. In the same way code has structure and behaviour. My point was that structural typing relies soley on the external structure of a type not the behaviour.</I><BR/>In Java, create classes A and B subclasses of Object - they have the same structure - does Java accept instances of A and B as the same type? (Nominal type system.)Isaac Gouyhttps://www.blogger.com/profile/00226627985460018169noreply@blogger.comtag:blogger.com,1999:blog-10345428.post-87298140873815680962007-03-14T02:38:00.000-07:002007-03-14T02:38:00.000-07:00Hi Isaac,Still throwing stones...:^) I'm still wai...Hi Isaac,<BR/><BR/>Still throwing stones...:^) I'm still waiting to hear what you think? Is that so difficult or is your Ego better served picking holes?<BR/><BR/><BR/>Any way let me address your points..<BR/><BR/>"paul wrote in the blog entry So how do I know that my program is Safe? Well simple, I test it!<BR/>No - that's how you find out if your program has errors."<BR/><BR/>... Well since I write my tests <B>before</B> I write code, it is impossible to detect errors in code that doesn't yet exist. My test are an executable specification for the code to be.<BR/><BR/>"In contrast, structural typing is based on the structure of the types." <BR/><BR/>... So we are back to word games :^) Yes, and types have structure and behaviour. In the same way code has structure and behaviour. My point was that structural typing relies soley on the external structure of a type not the behaviour. Last time I looked all my Types passed as code :^).Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.com