Graduate thesis on Python-related subject

[Alex Martelli]

"Benjamin.Altman" <benjamin.altman at noaa.gov> wrote in message
news:3AE9AC80.36D8E0A at noaa.gov...
> Potentially, there are less bugs to fix with less lines of code to be
maintained and
> understood etc.
>
> hat at se-46.wpa.wtb.tue.nl wrote:
>
> > I consider #lines of code (in whatever definition of line) not very
useful. In
> > fact, in the past years, I have moved away from considering #lines
anything
> > near relevant.
> > The real criterium of choosing a language is thus different. I haven't
figured
> > out what exactly, but concepts like 'readability' play an important role
imho.

To be precise, the *lines*, per se, are a rather random measurement.
There aren't going to be any more bugs, on average, lurking in a two-line
version of a statement:
    a = b.c(
        d)
than in the one-line equivalent:
    a = b.c(d)


OK, we could work around this one by thinking of logical lines as opposed
to physical ones.  But still, consider:
    if acondition(foo): blah(bar)
versus
    if acondition(foo):
        blah(bar)
these times the number of logical lines has really doubled, yet again we
are in exactly equivalent situations.  Why should the second form, which
is the preferred Python style of most programmers I think, be penalized
or considered twice as bug-prone?


There ARE, however, measures of code size which are impervious to these
non-complication-adding ways that lines can multiply.  But you need to
get quite a bit more sophisticated than just line-counting...


Alex