From: ptkwt@...1.aracnet.com (Phil Tomson) Date: 2001-12-11T05:20:17+09:00 Subject: [ruby-talk:28134] Re: The benefits of dynamic typing? In article , Robert Feldt 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 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." 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