From: Robert Feldt <feldt@...>
Date: 2001-12-11T02:22:38+09:00
Subject: [ruby-talk:28108] Re: The benefits of dynamic typing?

This is a bit long...

On Tue, 11 Dec 2001, Roy Patrick Tan wrote:

> I have just recently read an old paper by Wirth "On the Design of
> Programming Languages", which started me thinking about dynamic typing.
> 
> One of the lessons he enumerated:
> 
> "Design languages such that most checking operations can be performed at
> compile time, and need not be deferred until execution. The concept of
> static data types of variables is essential in this respect, and enhance
> both programming security and system efficiency."
> 
> Hoare also has similar comments about static typing.
> 
> Now, given that ruby is interpreted, much of the efficiency and type 
> safety aspect might not matter (though, if/when it gets bytecode 
> compiled, I can see that static typing can improve both).
> 
> However, it seems that dynamic types can be more error prone and harder
> to read, since we can't be sure what type of object a variable holds. I
> guess what I'm asking is: given the advantages of a statically typed
> language, does dynamic typing offer any benefits? What is the reason
> behind ruby's dynamically typed variables?
> 
IMHO, there is no simple answer to this and its more of an open research
question than an established fact. Although dynamic typing has been around
for quite a while humanity as a whole has lots more experience with
using statically or type inferring languages. So the verdict is not yet
out there on the relative merits of dynamic and static typing. 

(IMO, the final answer will probably be, as it often is in complex
questions, "it depends". And a hybrid solution where you can adapt to the 
problem at hand will have the highest probablity of success.)

I'm very interested in this questions so have collected some different
views. Below are some of them. Sorry that they are redundant and not
summarized. Beware of the line wrap.

* Classic-formal-methods-safety-critical view:
    * We must be sure the program works, so we need to prove it. Types are
      fundamental aspects of programming languages and type errors are
common.
      With static types we can prove there will be no type errors so one
      source of errors is eliminated. Fine, lets do it.

* Pragmatic-static-typing view:
    * Having the types explicitly stated in the code makes it easier to
read.
      Readability is a crucial aspect in determining the cost of code
since
      it determines maintainability. So lets type!

    CP = Counterpoint: Can't this be solved with comments or some other
      type annotation scheme.

* Modern-dynlang view:
    * Not having to specify types makes me go faster. Its more flexible
      and I can more easily change things as I go along. The flexibility
      and increased speed pays back by making me develop the right product
      with a higher productivity.

* "Based on my considerable experience" view:
    * In practice, type errors are not very common and their effect not
very 
      severe. Since specifying types gets in the way lets not do it.

* Xp/Executable-tests view:
    * Type checking is only one aspect of testing your code. Executable
unit
      tests allow you to test more than the typing of your program.

* Multi-method dispatch view:
    * With multi-methods you can dispatch on more than one type. So even
      though the typing is not static (the dispatch is still based on
dynamic
      type info) you can be sure your method will not be called with
objects
      that aren't of class/type X or fulfill the interface I.

* Efficient-dynlang-implementer view:
    * DynTypes are great but cost a lot since we cannot optimize for a
      certain type. To make the task of the compiler/optimizer simpler we
      need hints of the actual types. Lets give the user a way to 
      specify/hint on the actual types. (Dylan has this feature for
example)

* "Statically typed languages aren't typed anyway!" view:
    * Precise type information is lost when objects are fed through more 
      generic structures.
    * Since we want to write generic data structures etc even in
statically
      typed languages we need to work around the type system or invent
      special handling (templates in C++). In Java and C you frequently
need
      to type cast so they're not really statically typed and its not
safe.

* Smalltalk view:

(http://wiki.cs.uiuc.edu/VisualWorks/Mark+Fussell+Dynamic-vs-Static+Typing+Message)
    * "Types have poor granularity. Frequently a Type will be specified
that has too many operations (is too specific) to be useful in multiple
contexts even though subsets of those operations (a more general
concept) is widely useful. Since it costs effort to name and create each
Type, there is an impetus of reduction that again impedes reuse and
generalization. Save now, pay later."
    * "Types restrict future type-safe expansion to programs. Some
programs that could have been written type-correctly if done in one
"lump" are impossible to write given the actual historical growth of a
program (many people, different companies, over time, with limited
foresight). Choose now, pay later."
    * "[Static typing] ... may be helping in certain ways against mistakes
in the small, but it is interfering with good code (code that will execute
properly at runtime, is easy to understand, is easy to maintain, and is
useful to many clients) that helps grow systems in the large and over
time."

* "Type checking in Lisp" http://www.elwoodcorp.com/alu/table/types.htm
view:
    * "The lack of required variable declarations in Lisp does not provide 
       any less safety than in statically typed languages. Because of the 
       tagged types, Lisp can, in the worst case, check the types at run
time 
       for those items that cannot be automatically recast. In addition,
the 
       type system in Lisp can specify much finer grained types than are 
       usually available in statically typed systems. Thus it is possible
to 
       use the type system to ensure, for example, that a particular
integer 
       be odd, that a character be ASCII, or that an array not be a
string."

    CP: Most modern statically typed languages can accomplish such "finer
        typing".

* Lisper/Schemers going back to static typing:
   Dan Weinreb on ll1-discuss@ai.mit.edu 
     Thu, 6 Dec 2001 01:42:54 -0500 (EST) 
   "   I've written 100,000-line Lisp applications that don't have any
       type declarations.

     Me too, but my current opinion is that the next time I write a
     100,000-line application, I'm going to use type declarations
     everywhere I can, if the langauge makes them available (whether
     mandatory or optional).  I've really changed my mind on this over the
     years.  Partly it's because type declarations sometimes catch
     programming mistakes statically, and partly it's because they make
     programs easier to read.

     How's that for a provocative statement?  :-) Yes, easier to read.
     It's easier to understand a program if you can see, right on its
face,
     important invariants.  Assertions are helpful, and type declarations
     are an important special case of assertions."

   Scott McKay answers:

   "It's not provocative to me at all, since I had the same change of mind
    as you.  My Dylan and more modern Lisp code all use type declarations,
    at least for all the "contracts".

    I still think that's it's important for type declarations not to be 
    mandatory, and for type information to be carried by objects, not by 
    variables.  I haven't change my mind on that."

YMMV :-),

Robert