Re: Open Source Quality

From: Karl Auerbach <karl_at_cavebear_dot_com>
Date: Sun May 09 2004 - 18:59:32 CDT

On Sun, 9 May 2004, David Mertz wrote:

> I.e. Python is the *right* language to write OVC's reference in.

I agree with this, at least for the stations that handle small numbers of
records (less than 10s of thousands). (For stations handling bigger
numbers, I get concerned about the performance of python - at those larger
sizes, which tend to be only in county and state wide aggregations - I
believe that more traditional languages and databases will be useful.)

But my reason has little to do with memory leakage - For years I've
written C++ engines that run for months with no memory leaks - or buffer
overruns (again, good coding practices can address that) - but rather that
Python is a good, concise language.

But I am concerned about Python in that it has what can be a dangerously
flexible name-to-type binding mechanism. Python is all about binding names
to objects. And over time a single name can be bound to many types of
objects.

This makes it hard to inspect static python code. Rather than merely
looking at type definitions to see what a name means you actually have to
inspect (often by execution) the code path actually taken and make a
type(variable) call.

In addition, I am concerned that in python there can be latent bugs
lurking in not-yet taken code paths from things as common as a mistyped
name.

And any Python code that manipulates Python's underlying __xxxx__
variables should be immediately suspect.

There are tools to help with these kinds of things, but A) the tools don't
catch everything and B) we actually have to run the tools.

Python is good, but it is not a panacea.

                --karl--

==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Mon May 31 23:17:28 2004

This archive was generated by hypermail 2.1.8 : Mon May 31 2004 - 23:18:16 CDT