Class Browsers vs Static Types (Re: Inefficiency of __getattr__)

[Kragen Sitaker]

In article <8rfslr$335$1 at news.cis.ohio-state.edu>,
Mark Carroll <carroll at cis.ohio-state.edu> wrote:
>In article <B600ED43.1041A%graham73 at telocity.com>,
>graham  <graham73 at telocity.com> wrote:
>(snip)
>>Err, that's the point of a type system. If you have a piece of code
>>that does
>>
>>    true + 1
>>
>>it will cause a run-time problem of some sort, unless the code isn't
>>run. But the latter case is not very common, since no-one writes code
>>that they don't intend to run.
>(snip)
>
>Unless you have a very well designed test suite, for any significant
>project it's likely that not every line of code will actually be
>executed during development and testing.

I agree.

>Indeed, some of the code I'm
>writing now has modules with features that aren't used by the
>functions that use the modules, but I'm expecting that some later
>version will use those features and it's easier to include them now
>rather than trying to add them on later.

Those features are buggy and poorly designed, unless --- and probably
even if --- you've implemented something very similar before.  And when
you do get around to using them, you will end up fixing bugs that you
wrote months before instead of minutes before.  This makes the problem
much harder.

My experience is that it's not much easier to include features early
than to add them later, especially with high-level languages like
Python and object databases like ZODB.  (It's harder when you're
writing code in assembly and storing your data in an RDBMS.)

Code that has never been run (or, at least, thoroughly inspected by
several people) is, in my eyes, rotten --- like worm-eaten wood.  It
makes it harder to find the important parts of the code, simply by
adding bulk; it greatly increases the average time between writing bugs
and fixing them; it vitiates process feedback.  (Do you write most of
your bugs when working past 17:00?  When you've eaten a low-protein
lunch?  How effective are your code reviews?  How will you have any
idea if your bugs remain hidden for a month?)  When you're working in a
system full of untested code and something breaks, you can't tell if
it's something you just added --- or a bug that's been there for weeks,
months, or years.  That makes debugging slower.

Your argument seems to be that static typing makes bad development
processes more tempting.  I'm not going to argue that mine are perfect
--- I write code I forget to test, too, and sometimes it stays in there
for a long time, and it usually bites me later --- but I try to improve
them.

>In particular, with languages
>like Lisp, without lots of (declare ...)'s I'd sometimes find type
>errors cropping up some time after the code had been put into use.

I believe you!  :)
-- 
<kragen at pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
Perilous to all of us are the devices of an art deeper than we ourselves
possess.
                -- Gandalf the Grey [J.R.R. Tolkien, "Lord of the Rings"]