[Baypiggies] Type checking - argument for it being bad practice?

Zachary Collins recursive.cookie.jar at gmail.com
Sat Oct 9 13:08:02 CEST 2010

Many points have been here, but I'd like to throw in my feelings about
it, because I really do feel strongly about typing.

It's really not the typing that is necessarily the gate keeping in
traditional typed systems.  It's the types.  And there's several
reasons for this.  Now, in the more trivial cases, like int, or
string, or whatever, it's pretty obvious what type you need.

But there are still actually alot of cases where the type of an object
is not clear at the time you get to coding it.  For instance, take
containers.  Which container is best for this problem?  Which is most
efficient based on scaling with data set X?  data set Y?

How about I don't care right now.  How about I just give you an object
that you can slice and I'll think about it later?

What if suddenly I need to keep a bunch of meta data associated with
that list and it is no longer a generic list type, but it needs to be
it's own special caching slice like class that knows how and when to
fetch data?  Do I want to have A.  had to spend the half an hour
before hand pondering the potential interface I might want based on
data I don't have yet or B.  Have to by hand change the type in
several places possibly scattered in several files just so the
compiler believes me that it is ok?

The gatekeeping in typing is the planning of "what type is this?"
Often I don't know.  I don't even know which functions I might call on
my variable y until I've actually written a few lines.  When I'm
prototyping, I like to keep design and actual prototyping as tightly
coupled as possible, because rarely can I or should I spend the time
before hand /knowing/ alot of the details of my interface.

Another reason I like python's hands off approach to private members
and typing is that... I don't trust other programmers to know what I
need to do.  Frankly, my belief is that the coder who is most
immediately writing software has priority over the guy who wrote the
lib 10 years ago.  If I need your private variable to hack around a
feature problem or bug, I don't want to have to ask "pretty please".
If I need to give you a type you didn't think about when you wrote
your library, I don't want to have to assure you that it's ok.  How
about I take responsibility for that?

2010/10/9 Sean Perry <shaleh at speakeasy.net>:
> On Fri, 2010-10-08 at 09:59 -0700, Shannon -jj Behrens wrote:
>> Most of my bugs come from not understanding the problem well
>> enough--not from type errors.  That being said, I'm still excited
>> about Scala which has a very rich static type system (yeah, yeah, go
>> ahead and make fun of me ;)
> I like haskell for this too. However as others have commented here the
> type system ends up being used for duck typing most of the time. It is
> rare to say "this has to be an int" instead we just use it for math and
> the compiler figures out I meant a Num instance.
> Of course the coding ends up being similar to the suggestions elsewhere
> in the thread to just be optimistic and catch the exceptions. The
> difference is most of it is handled by the compilation phase instead of
> at runtime.
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies

More information about the Baypiggies mailing list