From: mailbox@dmitry-kazakov.de   
      
   On Sat, 20 Sep 2003 08:34:13 GMT, Don Geddis  wrote:   
      
   >I wrote:   
   >> >Your _insistence_ on static type checks is basically a claim that any   
   >> >("modern") compiler should _refuse_ to compile the code until the   
   programmer   
   >> >makes more changes.  All I'm asking for is flexibility, to merely provide   
   >> >a static type warning, but compile the code anyway if that is more useful   
   >> >to the programmer's current needs.  Let the programmer make the decision   
   >> >about whether he wants to execute the code or not.   
   >   
   >"Dmitry A. Kazakov"  writes:   
   >> There is absolutely no need to execute an infeasible code.   
   >   
   >Obviously _you_ don't see a need to execute it, but I don't understand why   
   >you refuse to accept that other programmers may find value there.   
      
   Oh, since Windows became the most popular OS, nothing can wonder me!   
      
   >> Statically typed laguages do not perform *all* type checks statically.   
   >> They only check what is statically known. The rest is checked dynamically   
   >> at run time.   
   >   
   >If this is true, then the whole dichotomy is meaningless.   
      
   Right, it is to death beaten issue.   
      
   > Why even claim   
   >that Ada/Haskell is a "statically typed language",   
      
   Mostly for historical reasons.   
      
   > whereas Lisp is a   
   >"dynamically typed language"?  Apparently both languages do extensive type   
   >inference at compile time, and both do run-time type error detection.   
   >   
   >How do they even differ?  Why do they claim to be in different camps?   
      
   The thing which really counts, is the default behaviour. "Statically   
   typed" languages tend to have the most safe behaviour as the default.   
   (A notorious exception was PL/1). "Dynamically typed" ones usually   
   ignore safety.   
      
   >> This is why they comprise a more generic class of languages than the   
   >> dynamically typed ones. If in a given program, no type is statically   
   >> known, then a statically typed language acts *exactly* as a   
   >> dynamically typed one.   
   >   
   >And many compilers for Common Lisp, a prototypically "dynamically typed"   
   >language, do extensive static type checking.  So "if a type is known at   
   >compile time, then it acts *exactly* as a statically typed language".   
   >The situation seems exactly symmetric, and you've eliminated any distinctions.   
      
   Right. In fact, except for extremists, both camps have finally   
   understood that types have to be checked as early as possible. While   
   *both* "early" and "possible" are important words here.   
      
   >> Again, not to check what can be checked is hardly an advantage. So   
   >> usually "dynamic" people rapidly switch to other issues. They claim   
   >> that they are able to compile the program more quickly.   
   >   
   >You keep bringing up irrelevant issues.  I've never claimed any of these   
   >things.  My only concern is when a program is not provably type-safe, but can   
   >run successfully with some inputs (although not others).  Static-type fans   
   >tend to say "modify the program until it _is_ type-safe".  Dynamic-type fans   
   >tend to say "run it now to get some quick results, and I may improve it later   
   >if the program seems to be on the right track."   
      
   This is a design technique issue. Not surprisingly, people using   
   statically-typed languages prefer a more careful design.   
      
   >> >You've gone too far.  There's a huge difference between "provably illegal",   
   >> >vs. "not provably type-safe".  Random generator programs may do anything.   
   >> >Whereas, a type-imperfect program may compute useful functions for some   
   >> >inputs (but not for others).  This partially-working program is _much_ more   
   >> >useful than a random program.   
   >>   
   >> Where is a measure for that? A random sequence of bytes could appear   
   >> partially-working. Who knows, let's start and see! (:-))   
   >   
   >I've given you plenty of examples already.  Partial programs that work   
   >correctly for a subset of their stated (or provable) types are very common   
   >in the initial stages of working on a problem.   
      
   Well, a clock standing still also shows correct time two times per   
   day...   
      
   The problem is that to know whether a program works correctly for a   
   part of the problem, one have to define that part. Because nobody   
   actually does it, it remains absolutely unclear whether the results   
   are feasible or just a garbage. How can you know, whether you hit the   
   part or are already outside?   
      
   >> Consider thread-safe and thread-unsafe objects. In a language like   
   >> Lisp you can send them messages indiscriminately. What will happen, if   
   >> your program would concurrently send messages to an unsafe object? It   
   >> will randomly corrupt data depending on call timings.   
   >   
   >Of course this is possible.  But Lisp was designed with the attitude of:   
   >"Give the skilled programmer power; he may abuse it, but that's his problem.   
   >Whereas, if you deliberately constrain his power on the off chance he may   
   >abuse it, he'll be constantly annoyed by what he is not permitted to do."   
   >   
   >The basic answer is: let the programmer decide whether he wants to   
   >"concurrently send messages to an unsafe object".  This is not guaranteed to   
   >fail, and may be just what the programmer needs to figure out the real bugs.   
      
   See, the programmer has to decide ..., the programmer has to care of   
   ..., etc. Now, you tell me that to decide which type to take is an   
   unbearable burden, while a need to inspect each and other call is just   
   an additional flexibility? (:-))   
      
   >> Typical is a situation when it works under debugger, but sporadically   
   >> crashes whithout it. Now consider that the program makes a lengthy   
   >> learning process 2 week long and finally, when you are eager to see the   
   >> result, crashes and corrupts the data base.   
   >   
   >This scenario is exactly at the root of static vs. dynamic type debates.   
   >The static side says "prohibit this, because it might fail".   
      
   No, it says, "prohibit this, because it will fail, otherwise, let him   
   (the programmer) *explicitly* specify, that he wants this".   
      
   For example:   
      
   X : Integer;   
   Y : Float;   
      
   X := Y; -- This does not compile, because it will fail in many cases!   
   X := Float (Y); -- OK, you wanted this, catch it!   
      
   >The dynamic side   
   >says "allow any power which might be of use in some situation."   
      
   Again, it is allowed to shut oneself in a foot. But to do so, you have   
   to disarm the safety lock.   
      
   >If you use a powerful language, you might mess yourself up.  But I, for one,   
   >would not voluntarily choose to give up that power.   
   >   
   >> type Has_No_Increment is ... -- Has integer, real and string   
   >> type Has_Increment is  ... -- Has only integer, real   
   >> function Read_From_Input return Has_No_Increment'Class;   
   >> procedure Read_Increment is   
   >> begin   
   >>    Increment (Read_From_Input);   
   >>       -- Compile error   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)