Is there a "Large Scale Python Software Design" ?
dave at pythonapocrypha.com
Wed Oct 20 00:30:33 CEST 2004
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).
More information about the Python-list