Python for large projects

[Jacek Generowicz]

gabor <gabor at z10n.net> writes:

> i wanted to use python for a project in our company... we wanted to
> build a fairly big system/program.
> 
> but when i recommended python, i got a question like:
> (previously all the programs were written in java)
> "if one of our programmers changes a method in a class/interface, we
> immediately will know about it, because the next program-rebuild will
> simply fail. but if we would use python, we wouldn't find it out".

"if one of our programmers changes a method in a class, without
changing the interface, but introduces a logic error, we won't know
about it, because the program will happily compile, but, as we have no
test suite, the runtime error will go unnoticed."

The errors which static typing system catch at compile time, are just
a tiny fraction of all the errors that programmers make, and they are
usually the most boring, and most obvious errors.

> yes, i know that people usually recommend unit testing for this, but
> imho it is not a good enough argument

It is not a good enough argument for convincing those who already
firmly believe that static typing somehow helps in the overall
software development process. Yes, it is an unfortunate fact of human
nature that people often acquire ushakeable beliefs, which make them
very unreceptive to evidence which points to flaws in said beliefs.

> other thing is, that in the projects i work on, there seems to be
> very hard to do unit tests

... and one thing that makes unit testing very difficult, is static
typing ... (which is why statically-typed projects are less likely to
have (any, let alone good) unit test suites, which is why statically
typed projects are far more likely to be bug infested).

> ... most of the parts of the system can't be that easily be tested
> (how do you unittest a threadpool? a servlet?).

Yes, some things are harder to unit test than others. That in no way
affects the _necessity_ of testing it ... and static typing only makes
testing harder (and less testing means more bugs ... hence static
typing means more bugs.)

> yes, i've heard that "if you can't make unittests, that means your
> classes/modules/packages depend too much on each othere, and that
> means you wrote bad code.

Yes, there is some truth to that, but I consider it irrelevant to what
we are discussing. _All_ software must be tested, whether written with
or without static typing. Static typing makes testing more difficult,
therefore static typing lets more bugs slip through the net. (I hope
I've repeated that often enough in this article to for it to be
noticed my more than one reader :-)

(In next week's episode of "Static Typing Sucks" we discuss static
typing systems' penchent for rejecting perfectly _correct_ programs
because they contain what the rigid type system considers to be a type
error, even though said "error" would have no adverse influence on the
correct running of the program.)