[ruby-talk:28134] Re: The benefits of dynamic typing?

In article <[e-mail]>,
Robert Feldt  <[e-mail]> wrote:
>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 [e-mail] 
>     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."
Robert

This post offers good coverage of all sides of the issue - could you post 
it to the RubyDiscussions section of the wiki on Rubygarden.com?

Phil