Re: dynamic vs. static typing

[Chris Page <address@hidden>]

On Nov 22, 2003, at 13:56, Roger Price wrote:

> Overbearing commitment? None.  Heavy responsibility to keep a promise? 
> None.  On the contrary, I wilfully break the type system to see what 
> would be needed if I changed an interface.  The type checker is a 
> friendly and tireless assistant who will remind me of details that I 
> forget (or choose to forget).  I am not stressed by my assistant. I do 
> not hit walls, there is no angst.

If you had an editor that operated not on plain text files but on 
programs (e.g. some form of AST) you might not care much about the 
amount of "book keeping" the common cases of editing type declarations 
require of you. If you changed the type of a function argument, for 
example, it might be straightforward to have the editor update the type 
declarations elsewhere to conform.

When considering issues like type declarations, I think it's important 
to draw a clear line between issues of practical use using today's 
tools vs. "real" language design issues. (In this regard, I'm a little 
concerned that languages like Goo and Arc may be trying too hard to 
reduce the amount programmers have to type as opposed to maximizing 
readability.)

Many language design decisions are based upon a simple model of 
development tools, in which we edit plain text files, and usually only 
one file at a time. In a more advanced system, most syntax details 
could "go away" in the sense that you could decide how you wanted 
programs to be presented for viewing and even change it dynamically. So 
"the" syntax of a language might just be the default presentation.

Don't like where the scope delimiters are placed? Have them displayed 
wherever you like. Prefer "begin" and "end" or "{" and "}"? Pick 
whichever you want to see. Or hide them entirely and rely on indenting 
to guide your eye. Don't like ":=" for assignment? Change it to "=". 
Whatever you want. Want to see expressions presented using Lisp syntax? 
Want to see an Arc-like "(x 1)" instead of "(aref x 1)"? Done.

Language design might be a simpler affair if semantics and presentation 
were much more separated than they are today, especially if 
presentation could be altered without changing the language design 
proper.

But on the larger scale, consider issues like implementation 
inheritance. Some say it's a bad thing because program behavior is 
harder to understand. Part of the problem is that the full meaning of a 
given method may depend on code that is textually remote. What if you 
could view the implementation of a method with the inherited code 
"inlined"? What if you could see all the possible variations of that 
code for all known types?

Escaping the bonds of plain text files may reduce or eliminate problems 
that are currently attributed to language design or programming 
methodologies, but which are really due to the limitation of having 
only one presentation of the code readily available for viewing.

Could languages be more "lightweight" if presentation and editing were 
more robust?

-- 
Chris Page - Software Wrangler - palmOne, Inc.

   Dylan + You = Code
   <http://www.gwydiondylan.org/>
   <http://www.cafepress.com/chrispage>