Thoughts on Guido's ITC audio interview

[D H]

Dave Benjamin wrote:
 > One thing Guido mentions in his comparison of ABC (Python's 
predecessor) and
 > Python is how ABC was inextricably tied to its environment (a la 
Smalltalk),

What surprised me was that this was the only thing he really mentioned. 
  He didn't mention anything about the theoretical underpinnings of ABC, 
he was only involved in the implementation of ABC, and others did all 
the language design.  And his main criticism is a pragmatic issue with 
using the ABC in real tasks like reading external files.  It explains 
why sometimes Python's features seem to be more implementation-driven 
rather than design-driven.  Such as perhaps the use of self, but a 
counter-example is slicing syntax, borrowed from the language Icon 
apparently.
I think when you borrow some features from a language but not all, you 
have to re-evaluate every part of the language design.  Colons at the 
end of lines for example help readability in the ABC language because 
keywords are all uppercase (unlike python).  So the colons in effect 
counteract some of the negative impact uppercase words place on 
readability.  In Python however, I don't see how colons really are 
needed to help readability at all.  And there are other issues too such 
as changing python to be case-insensitive or making 7/4 == 1.75 instead 
of 1 which even Guido wanted at one point (
http://www.linuxjournal.com/article/5028 ), but only the latter was 
implemented (yet not enabled by default yet).


 > I find that a similar comparison can be made between Python and Java. 
Java's
 > startup time is so long that it is not practical for writing small 
tools for
 > use in command-line scripts, and the propensity toward application 
servers
 > and integrated development environments suggests a strong preference 
for a
 > monolithic, self-contained, single-language environments.

That's a very good point.  Yeah you never hear of people using java for 
making quick little scripts, which python and php are really great for 
(among other things).


> Guido makes a funny jab at Paul Graham about Graham's nine things that make
> Lisp Lisp (available here: http://www.paulgraham.com/icad.html) - I had read
> this essay many times but never saw the subtle irony behind claims of
> "Greenspunning": in order to claim that a language is approaching Lisp, you
> have to define what it is about Lisp that other languages are purportedly
> emulating, and this begs the question of why you have the authority to
> declare which 9 (or n) attributes of Lisp are most important. I like Paul
> Graham and his essays a lot, but I must admit I had to laugh too when I
> heard the way Guido framed this argument. I'm not so sure that Python has 8
> out of 9, though: the statement/expression dichotomy rules out #6, and the
> lack of macros rules out #9. These are arguable, depending on how you define
> things, but I think the most obvious thing that Python lacks compared with
> Lisp and Scheme (and also Ruby) is a symbol type (#7). I'm in the process of
> trying to understand what symbols are good for, outside the context of Lisp
> and its nested lists of symbols as executable code. Ruby seems to have come
> up with some creative uses for symbols within Python-like syntax, though I
> haven't seen anything terribly compelling so far.

Other python extensions and descendants I mentioned in this note are 
exploring the two main things lisp has but python doesn't - #6 
eliminating the expression/statement distinction (at least in some cases 
like assignments), and #9 macros:
http://groups-beta.google.com/group/comp.lang.python/msg/360c99b7ab7b839c?dmode=print&hl=en


>   - 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."

As pointed out elsewhere, type declarations also help with documenting 
your code, as well as dramatically speeding up your program.


> I think Python's decision to use reference counting was an instance of 
> worse-is-better: at the time, reference counting was already known not to be
> "the right thing", but it worked, and the implementation was simple.
> Likewise with dynamic typing versus type inference. It seems that Guido
> shares Alan Kay's viewpoint that type inference is really "the right thing",
> but modern language technology is really not ready to make it mainstream,
> whereas dynamic typing works today, and is arguably a better "worse"
> solution than explicit/manifest static typing due to its verbosity.

That's very interesting.  Type inference isn't always perfect though. 
There are some cases where it can't infer the type, or it infers the 
wrong type that you really want.  Type inference + dynamic typing is a 
good combination that can speed up your code without slowing down your 
coding.

> Type inferencing is especially difficult to add to a dynamically typed
> language, and in general I think results are much better if you have type
> inference from the very beginning (like ML and Haskell) rather than trying
> to retrofit it later. 

It's easier to add dynamic typing to a type inferenced, statically typed 
language.

> Someone in the audience mentioned that the CPython VM is so solid they're
> surprised nobody's implemented a Java program on top of the Python VM (as
> opposed to the other way around, as in Jython). 

The CPython VM is really geared specifically for the Python alone, and 
Python's dynamic typing.  It's no wonder other languages haven't been 
built upon it unlike the java VM or the .NET/Mono CLR.

Someone in the audience
> surprised everyone by mentioning an actual project attempting this, called
> javaclass:

Sounds like it really is converting java classes to python classes, 
which are very different things.  Lot of limitations mentioned such as: 
"It runs on the Python runtime which does not have the security, 
threading and just-in-time compiler features that people enjoy about 
Java runtimes"