Thoughts on Guido's ITC audio interview

[John Roth]

"Dave Benjamin" <ramen at lackingtalent.com> wrote in message 
news:slrndbrse5.71d.ramen at lackingtalent.com...
> Guido gave a good, long interview, available at IT Conversations, as was
> recently announced by Dr. Dobb's Python-URL! The audio clips are available

[snip]

>  - Java: the usual static vs. dynamic, static analysis vs. unit testing
>    arguments. Guido says that there's such a small amount of problems that
>    can be caught at compile time, and even the smallest amount of unit
>    testing would also catch these problems. "The blindness of that 
> [static]
>    position... escapes me."

Three years ago, this was a viable arguement. Two years ago, it was
beginning to show difficulties. Today anyone who makes it can be
accused of having their head in the sand [1].

What's being ignored is that type information is useful for other things
than compile type checking. The major case in point is the way IDEs
such as IntelliJ and Eclipse use type information to do refactoring, code
completion and eventually numerous other things. A Java programmer
using IntelliJ or Eclipse can eliminate the advantage that Python
used to have, and possibly even pull ahead.

The only thing that is even vaguely similar in the Python community
is Bycycle Repair Man, and, to be brutal about it, it sucks in
comparison with what either Eclipse or IntelliJ can do.

I agree with Guido's point later in the interview that type inference
is the way to go, and that it's very difficult to retrofit it to an existing
language. Difficult does not mean impossible though. The place to
start is to go through the standard objects and make sure all return
values make sense.

I'll throw out one very simple example in the string library. The
index() and find() methods, and their variants, suffer from a bad
case of non-obviousness inherited from the C library. A very
simple replacement would fix this.

--------------------------------

findall([maxfind,] sub, [start, [end]])

findall returns a list (possibly a tuple) of the beginning index
of each substring which matches sub. If there are no matches,
an empty list is returned. At most maxfind indexes are returned.
start and end have the same meaning as in the existing find and
index methods.

--------------------------------

This version works intuitively with if statements (an empty
list is false), goes directly into for statements, can be implemented
as an iterator, and is only less efficient by a constant (creation of
the list) if the maxfind parameter is used. It never throws an
exception (unless the parameter list has the wrong types).
Its an example of a method that can be used cleanly with a
type inferencer, while the index and find methods cannot.

[snip]

John Roth

 [1] I'm well aware that ostritches do not stick their heads in
the sand to avoid looking at distressing things, such as advancing
predators. It is, however, a useful metaphor.

>
> Cheers,
> Dave