Re: Lightness vs. Largeness

[Scott McKay <address@hidden>]

At 01:42 AM 12/6/01, Dan Weinreb wrote:
>    Date: Wed, 05 Dec 2001 13:08:12 -0500
>    From: Scott McKay <swm@hotdispatch.com>
>
>(Not to dispute the greater point from which I wrested the following
>excerpt:)
>
>    I've written 100,0000-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.

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.  (So there :-)

>In the code I work on, another useful assertion at a many points is
>"There must (or must not) be a transaction in progress for the current
>thread at this point"; this doesn't provide static checking, only
>dynamic checking, but it makes the program easier to read in a similar
>way.
>
>Right now, when I am reading through a large Java program that I have
>never read before, one of the first things I do is scan through the
>code in order to figure out, for each "Map" and "List" and "Set" field
>( instance variable), what the actual types are (the types of the
>elements of the sets, or the keys and values of the map, etc), so that
>I can draw a UML-like picture of the data structures.  I'm looking
>forward to the new Java in which these classes will be parameterized
>so that I won't have to go through this step.  (Maybe someday I'll get
>for Xmas a tool that creates the UML diagrams...)
>
>Sure, it's good for the type declarations to be optional, particularly
>when you're writing a very small program.  If I were in a team writing
>a large program in a declarations-optional language, though, I'd think
>carefully about team coding standards regarding where it's OK to omit
>type declarations.

I'm pretty insistent that type declarations be included in input and outputs,
since they do render the code much easier to read.

>(In another discussion, I learned an interesting thing about the Curl
>language.  In Java, there is one type for every class, but in Curl
>there are two: a type that allows any object of that class or null,
>and a type that allows any object of that class but not null.  That
>sounds useful.  Of course there are important tradeoffs about how
>expressive you make your type system.)
>
>Do you think it's true that, for any language, if you want type
>declarations to be optional, there must be some type that is the union
>of all types?  (There is no such type in Java because of the
>"primitive" types; otherwise you could imagine omitted type
>declarations "defaulting" to "Object", although perhaps the grammar
>would need some adjusting...)

Yeah, you need a type "Object".

I think that Java does not have both "type" and "null-or-type" is a
real omission.  Being able to assert that this Set *really is* a Set
(and not a null) is quite important.  It's a royal pain to look at Java
code littered with 'if (x != null) ...'