Is there a "Large Scale Python Software Design" ?

[Dave Brueck]

Alex Martelli wrote:
> Dave Brueck <dave at pythonapocrypha.com> wrote:
>>Andreas Kostyrka wrote:
>>
>>>On Tue, Oct 19, 2004 at 07:16:01AM -0700, Jonathan  Ellis wrote:
>>>
>>>
>>>>Testing is good; preventing entire classes of errors from ever
>>>>happening at all is better, particularly when you get large.  Avoiding
>>>>connectedness helps, but that's not always possible.
>>>
>>>What classes of errors are completely avoided by "static typing" as
>>>implemented by C++ (Java)? 
[somebody before me wrote the above, but it was attributed to me - could have 
been my own fault while replying, but who knows...]

>>(2) much more common in code written by 
>>lazy/underexperienced developers who are already considered a liability,
> 
> No, I think you're wrong here.  Typos are just as frequent for just
> about all classes of coders, lazy or eager, experienced or not -- the
> eager experienced ones often use faster typing (nothing to do with
> static typing;-).

Hmm.. when I wrote that I was merely guessing at what "classes of errors" he was 
referring to, and I honestly didn't even consider typos. Instead I was thinking 
of cases where the programmer is reading too much into information returned from 
the compiler. Two specific instances I've encountered in the past came to mind:

a) Slopping casting - the attitude that casts are needed only when the compiler 
complains, and warnings/errors due to type mismatches are given a cast without 
much thought - the goal is to silence the compiler.

b) Sloppy refactoring - "I added a parameter to the method signature and 
recompiled. In each case where the compiler complained, I added the new 
parameter to the call until all instances were fixed".

Basically, they're cases where static typing appears to give an advantage in 
locating problems, but they are sometimes misleading (and therefore can 
_sometimes_ be a disadvantage if relied on inappropriately) and sometimes the 
remedy more involves helping the developer progress & improve (as such efforts 
yield greater fruits anyway).

>>More modern/advanced static type systems that let you actually get into
>>the semantics of the program (as opposed to just deciding which predefined
>>type bucket your data fits in) may help, but IMO the jury's still out on
>>them (partly due to complexity, and partly due to _when_ in the
>>development process they must be defined - perhaps that's the root problem
>>of some static type systems - they make you declare intent and semantics
>>when you know the _least_ about them! Consider the parallels to available
>>knowledge in compile-time versus run-time optimizations).
> 
> If you mean typesystems such as Haskell's or ML's, allowing extended
> inference (and, in Haskell's case, the wonder of typeclasses), I think
> you're being a bit unfair here.  You can refactor your types and
> typeclasses just as much as any other part of your code, so the "when
> they must be defined" seems a bit of a red herring to me

True enough - the "when" bit apples to the static type systems of e.g. C/C++ - 
where up front you have to specify more detail than you may have (what set of 
values might it have, how will it be used, does it ever need to behave like 
objects of a similar type, how do we represent "nothing", do we need to be able 
to differentiate between uninitialied and "not present", etc.), and refactoring 
later on can have interesting side-effects (not necessarily due to the typing 
system directly; rather, such a type system encourages programmers to 
prematurely think about things like saving memory by using a short vs an int or 
making sure a structure wastes the minimum possible number of bytes on 
alignment padding - later on when you better understand how the data is used and 
would like to refactor it, it can get messy trying to separate decisions that 
were made due to requirements versus those made for other reasons).

-Dave