Popular conceit about learning programming languages

[Donn Cave]

Quoth Alexander Schmolck <a.schmolck at gmx.net>:
| "Donn Cave" <donn at u.washington.edu> writes:
|
| > If there's one thing that makes Python a bad choice for me, that's it.
| > During development, static type systems save me a lot of trouble.
|
| Have you tried pychecker? I'm not sure what sort of troubles static type
| systems save you from, but at least for the relatively trivial but common
| cases like typos, pychecker seems to do quite a good job.

In the context where I've been making my typos lately, pychecker has
been out of its depth.  Lots of stuff it can't follow for one reason
or another, functions too long to analyse, etc.  This is not all my own
code, I hasten to point out.

Most of the problems are just limitations in pychecker that could be
overcome with more development effort.  But this same software is full
of every kind of introspective hack you can think of, importing modules
determined at run time and that kind of thing.

| On the whole, I think compulsory static typing is a bad idea. It invariably
| seems to lead to spurious warnings and unnecessary code (partly because
| typecheckers are usually quite daft and complain about correct code and partly
| because it causes less flexible code) and longer development times. 
|
| It would seem to me that most or all of the benfits of static typing can be
| obtained from tools.

It can't.  In places where the program itself is determined by run time
inputs - like in the case of the module that's imported that way - your
tool is of no use.  That's an extreme case, but in general, Python isn't
typable, be it compulsory or optional.

As per another followup's observation, it does not come as a surprise to
find that static type checking is not popular on comp.lang.python, and
it probably isn't worth while to take it up here.  I will only say that
there are many languages that have some degree of static typing, and the
quality and usefulness differs a lot from one to another.  OK, and I guess
I will say, if you don't count bugs that turn up in a program months after
you thought it was finished, I think you are underestimating your Python
development time.

But forget the way other languages do it, we're all Python users here
and we're talking about how experts program in Python, and guess what -
we're responsible for doing the work that the static type checking language
would have supposedly done during compilation.  We have to reason about
the correctness of programs - so - we have to write programs that people
can reason about with decent odds of success.  Python's most frequently
touted advantage is probably its readability, and of course that's the
same thing, and of course it isn't achieved just by selecting Python as
your implementation language.

I would like to propose, for example, that a simple 'if/elif/else' block
might be better than mounds of OO code with objects that register themselves
in tables at run time, if it means that you can tell at a glance how the
code works.  I would like to propose that an expert Python programmer is
one who knows all the introspective tricks in the book, and knows better
than to use them.

	Donn Cave, donn at drizzle.com