Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!comp.vuw.ac.nz!brian From: brian@comp.vuw.ac.nz (Brian Boutel) Newsgroups: comp.lang.misc Subject: Re: Dynamic typing (part 3) Message-ID: <1991Apr15.015640.4663@comp.vuw.ac.nz> Date: 15 Apr 91 01:56:40 GMT References: <1707@optima.cs.arizona.edu><1991Apr11.053440.13401@comp.vuw.ac.nz> Sender: news@comp.vuw.ac.nz (News Admin) Organization: Computer Science, Victoria University, Wellington, NewZealand Lines: 107 Nntp-Posting-Host: antrim-hse.comp.vuw.ac.nz Originator: brian@antrim-hse.comp.vuw.ac.nz In article , olson@lear.juliet.ll.mit.edu ( Steve Olson) writes: |> [about something I wrote] |> Thats ridiculous. Your argument assumes a bad design. No language |> outlaws |> stupidity. Do you believe that Lisp programmers go around making up |> lists |> of completely random elements just to make things challanging? |> The ability to do just this has been touted by others as one of the advantages of dynamic typing. My point was that if they do not do this, they could use static typing, as you yourself say. |> Of course you can use a statically typed language. The question is how much |> programmer resources (usually more) vs. how much machine resources (usually |> less) will the static solution consume? The choice depends on the |> application. |> Again we agree -(see below) |>[me] Any problem solution can be programmed in a statically typed language, |> if the programmer is prepared to *design* the program before |> writing it. |> |> Any problem solution can be programmed in a statically typed |> language, period. |> So? Are you trying to imply that using a dynamically typed language |> somehow |> prevents one from designing? |> It's a strange kind of logic that has my claim imply what you suggest. There is, though a conection between the design effort I associated with using static types and the "programmer resources (usually more)" that you associate with static types. |> Many (most?) |> large complex programs written in statically typed languages have little |> bits of roll-your-own dynamic typing in them. This is a prime source of |> "hackery". Screw up one of those explicit type tags and there is no |> end to the troubles you face. This may well be true, but what does it show? A lack of design effort. Let me make a statement - up to now I have just responded to other postings. First, let me try to define what I mean (sorry if this is boring). - A type is a set of operations. - a value has type T if it understands all the operations of type T - a type violation occurs when there is an attempt to apply to a value an operation which is not in its type. - Languages can be classified as untyped, dynamic typed, static typed. - Untyped means that it is solely the programmer's responsibility to ensure that no type violation occurs. Failure to ensure this will not be detected at compile time or by the system at run-time. Usually the code implementing the operation is applied to the bit pattern representing the value as though that pattern represented a value of the appropriate type for the operation, with serious results. E.g. doing a floating point add to an integer value. - Dynamic typed means that values/objects contain type information at run-time, so can detect attempted type violations and respond. This is fine unless the response is unanticipated. - Static typed means that a type is associated at compile time with each variable. (In a functional language, which is what interests me, this normally means with each defined function and by implication its formal parameters.) It is possible at compile time to ensure that a value is never bound to a variable of the wrong type, and that only type-valid operations are performed on variables, thus preventing type violations. You made a trade-off between development costs and run-time costs. Fine, there is nothing wrong with that. I prefer to note the trade-off between development cost and run-time unreliability. I.e. it's better, in an important application, to take the extra time in development to protect against run-time type violations. This is not a complete guarantee of program correctness, but it is a step in the right direction. If I had to accept liability for damages resulting from the failure of a software system, which had to be developed from scratch, I would, other things being equal, (programmer skills and experience, etc), insist on the use of a static typed language. Since I moved from industry to Academia, my own programming efforts carry no such burden of responsibility, so I could freely use lisp or apl or smalltalk in my own little world, but I believe my responsibility to students, most of whom will become practitioners in industry, is to encourage them to use safe practices, or "solid engineering principle". --brian -- Internet: brian@comp.vuw.ac.nz Postal: Brian Boutel, Computer Science Dept, Victoria University of Wellington, PO Box 600, Wellington, New Zealand Phone: +64 4 721000 Fax: +64 4 712070