Thoughts on Guido's ITC audio interview

[Dave Benjamin]

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
here:

http://www.itconversations.com/shows/detail545.html
http://www.itconversations.com/shows/detail559.html

I'd like to comment on a few parts of that interview.

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),
where Python, though it supports an interactive mode, follows more of a
UNIX-style "do one thing well" philosophy, and was designed to integrate
with other tools rather than being a whole world to its own.

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. On the other hand,
even though internally "there's only one way to do it" in Python, Python
itself is one of many ways to develop software, and does not insist on being
the one perfect way to do it. You can use whatever editor you like, and the
language doesn't go out of its way to make it difficult to use other
programs and processes, including the operating system if so desired.

It is a bit ironic that, according to Guido, the command-line interpreter
interface to Python was more of an afterthought, since my whole experience
with Python has very much centered around the interpreter. Like many, I
think, my first use for Python was as a calculator. =) In fact, since
discovering Python, I've been very resistant toward learning any language
that doesn't have an interpreter. Ruby, Scheme, OCaml and SML/NJ have been
fun to learn because I can tinker with them at the command line. "perl -de
42" is rather frustrating to use, as is Haskell's "hugs" due to the
inability to define new functions at the command line.

Command-line interfaces are a great way to get up to speed on new languages
and libraries. One of the advantages of Python is that it allows you to
graft a CLI onto environments that weren't designed with one. For instance,
Jython gives Java a command-line interface, and this makes working with Java
much more tolerable since you can interact with libraries in real-time and
learn how they behave at runtime. Likewise with PythonWin and COM scripting.
I am glad to see that IronPython is designed with a command-line interpreter
as well, should I ever need to learn my way around .NET in a hurry.

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.

Guido briefly summarizes language comparisons with other languages:

- Perl: similar niche, but Perl is for regexes and text processing, and
Python is for objects, data structures, and more general-purpose
programming. Obligatory TMTOWTDI argument.
- PHP: very successful at its niche, being a point-solution for adding
bits of script to web pages. Not very useful outside that context, and
lots of language-design gaffes.
- 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."
- C/C++: same arguments as Java, plus most programmers aren't up to the
task of manual memory-management.
- Lisp: even though there's no code-equals-data in Python, you still have
the compiler available at runtime, and there's a lot you can do to treat
code as data even though they're not syntactically idnentical.
- Smalltalk: very similar to Python, but Python is easier to integrate
into existing shops that use other languages, mainly (IMO) because
Smalltalk is a self-contained, integrated environment so the cost of
introducing it is much higher

There was also some discussion on why Java seems to be such a memory hog.
Guido chalks it up to Java's "fancy schmancy garbage collection technology"
with its heaps and threads and insistance on far-reaching low-level control
over all the poitners in the heap. It is a bit ironic that (C)Python with its
simple reference-counting plus cycle-detection seems much less
resource-hungry than Java's GC, even though most language experts consider
GC to be a vastly better technique. But I think this has more to do with
Java's particular implementaion of GC; OCaml, for instance, is
garbage-collected but has a very lean memory footprint.

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.

From the perspective of writing C extensions, Guido claims that the amount
of pain (regarding memory management) is about the same whether you're
extending a reference-counted language like CPython or a garbage collected
language like Java. Anyone with experience writing C extensions want to
comment on this?

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. Guido says that they've only been able to get it to
work reliably in Python with constants, which isn't very useful.

Regarding Ruby, Guido said that the community is much smaller than Python,
and that it's much more of a "better Perl" than a "better Python". I think
that, despite claims by both Guido and Matz, Ruby sits pretty much on the
fence betwee the two languages. Guido says he dislikes the code block syntax
in Ruby, but doesn't make it clear whether it's the syntax he dislikes or
the code blocks themselves. He does mention that if you like Smalltalk,
you'll probably like Ruby because of the code blocks...

Generators and iterators are, according to Guido, an "80% solution" for the
kinds of things people use code blocks for in Ruby. I think that the
newly-proposed PEP 343 offers adds another 5-10% to the solution, perhaps;
soon, Python will be able to do resource management in addition to iteration
patterns without the use of code blocks. I can still think of additional
uses for code blocks, and I have to wonder how many "point solutions" Python
is going to gain in attempt to avoid adding code blocks to the language.
This is not to say that I don't think generators or the newly proposed
"with" keyword are cool features to have.

(Upon review, I realize that Guido made the "80% solution" comment
regarding generators vs. continuations, not code blocks. Still, generators
are far more specific of a tool than either continuations or blocks.)

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). Someone in the audience
surprised everyone by mentioning an actual project attempting this, called
javaclass:

http://www.boddie.org.uk/python/javaclass.html

In response to any question on how to create a language, a community, a
successful project, Guido's response tended to be the same: he doesn't
really know what he did that made it work, or made the community follow
Python so well and for so long. He says it's probably not a good idea to
start a new project by following in the footsteps of an old one. If only we
could tap a bit deeper into the mystique of successful software projects.

Cheers,
Dave

 

[John Roth]

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.

 

[D H]

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

 

[Steven D'Aprano]

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.

I haven't used IntelliJ or Eclipse, so I guess I'll have to take your word
for how wonderful they are.

[snip]

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.

It must be an very bad case of non-obviousness indeed, because it isn't
obvious to me at all what particular bit of non-obviousness it is that
you are referring to.

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.

Am I the only one who has reservations about having to build a list of all
the matches before doing anything with them?

s = "a" * 10000000 # 10 MB of data to search
L = s.findall("a") # lots of matches means L is very large

or imagine a more complex case where I have to programmatically change my
search string as I go. I might not know how many matches I need until I
have found them and can analyse the text around the match.

Seems to me that rather than having to find all matches regardless of what
you actually want, it would be better to turn find into a generator. Then
findall becomes list(find) and you still have the flexibility of finding
matches one at a time.

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.

Er, how does that last one work? How can findall be used cleanly? Why
can't find?

 

[John Roth]

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.

I haven't used IntelliJ or Eclipse, so I guess I'll have to take your word
for how wonderful they are.

You might want to look at something outside of Python. The world
changes, and if you keep your eyes closed, you might not notice
it changing until it rolls over you.

[snip]

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.

It must be an very bad case of non-obviousness indeed, because it isn't
obvious to me at all what particular bit of non-obviousness it is that
you are referring to.

The result of find() cannot be used cleanly in an if statement; you
need to compare it to -1. This is not obvious to a novice, and is
a fertile source of mistakes. It's an irregularity that has to be checked
for.

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.

Am I the only one who has reservations about having to build a list of all
the matches before doing anything with them?

You don't have to build a list of all the matches. First, that's what the
maxfind parameter is all about, second, as I said below, it could be
implemented as an iterator. I'd expect that to happen if it was going
to be used in a for statement.

s = "a" * 10000000 # 10 MB of data to search
L = s.findall("a") # lots of matches means L is very large

or imagine a more complex case where I have to programmatically change my
search string as I go. I might not know how many matches I need until I
have found them and can analyse the text around the match.

Seems to me that rather than having to find all matches regardless of what
you actually want, it would be better to turn find into a generator. Then
findall becomes list(find) and you still have the flexibility of finding
matches one at a time.

See below. I covered it.

Er, how does that last one work? How can findall be used cleanly? Why
can't find?

findall() has a definite type: a list of integers, specifically a list of
integers
that are legitimate indexes into a specific string. The result of find()
does
not have this property: it can be an integer that is an index into the
string,
or it can be a -1. Index can either return an index into the string, or it
can throw an exception. Both of these are complex result types that
hinder further type inference.

John Roth

 

[Steven D'Aprano]

You might want to look at something outside of Python. The world
changes, and if you keep your eyes closed, you might not notice it
changing until it rolls over you.

If and when I have personal experience with either of these IDEs, I'll
be sure to let you know if I disagree with you. But until then, since I
have no reason to doubt what you say, and life is too short to check
everything in the world, I will accept your opinion on IntelliJ and
Eclipse.

[snip]

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.

It must be an very bad case of non-obviousness indeed, because it isn't
obvious to me at all what particular bit of non-obviousness it is that
you are referring to.

The result of find() cannot be used cleanly in an if statement; you need
to compare it to -1. This is not obvious to a novice, and is a fertile
source of mistakes. It's an irregularity that has to be checked for.

Oh, that? It was obvious to me from the moment I understood that strings
were indexed from 0, not 1. How else could it work?

find() doesn't return a truth-value, it returns an index. You can't
sensibly use that index where Python expects a truth-value, but then you
also can't use it where Python expects a dict or a tuple or a function. I
realised that in about 5 seconds, was disappointed that Python used
0-based indexing rather than 1-based, and got over it. I never once even
tried passing the index returned by find() to if.

Yes, a lot of novices make that mistake. Shame on them. I've made plenty
of stupid mistakes in my time, and no doubt I will continue to do so. When
I make a stupid mistake, I am ashamed at MY stupid mistake, and don't
blame the language for my failures.

(I have writen p = S.find(substr); if p >= -1: in error.)

[snip]

You don't have to build a list of all the matches. First, that's what
the maxfind parameter is all about, second, as I said below, it could be
implemented as an iterator. I'd expect that to happen if it was going to
be used in a for statement.

Firstly, I've already noted that sometimes you can't predict before hand
how many matches you need, so maxfind doesn't always help.

And as for it being an iterator, I quote your specification for what
findall should do:

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

Whether it is implemented as an iterator or not is irrelevant: it still
has to package up all those yields and stick them in a list before
returning that list.

I believe there is a case for turning find() into an iterator. There might
even be a good case to make for a function findall. But I think it is a
terrible idea to replace find() with a function which "returns a list of
the beginning index of each substring which matches".

You are welcome to change the specifications of findall() and turn it into
an iterator which returns each match one at a time instead of all at once,
but then the name is misleading, wouldn't you agree?

findall() has a definite type: a list of integers, specifically a list
of integers
that are legitimate indexes into a specific string.

Not according to your specification. It can also return an empty list.
There are no legitimate indexes in an empty list. If your IDE or compiler
or other tool can deal with that special case, why can't it deal with the
special case of find returning -1?

In any case, there is no such type as "legitimate indexes", and there
can't be for arbitrary strings. In general, you don't know the length of
either the substring or the main string until runtime. Since you don't
know both lengths, you can't tell which ints are legitimate indexes and
which are not.

For arbitrary strings, length unknown until runtime, the best you can do
is allow any index > -1. And if you are going to do that, then it is not
really such a big deal to allow any index >= -1 instead.

Yes, an index of -1 has a different meaning than 0 or 1 or 2, but in the
findall case, a return result of [] has a different meaning than a return
result of [0, 1, 2]. You are just exchanging one special case for another
special case.

The result of find() does
not have this property: it can be an integer that is an index into the
string,
or it can be a -1.

Both of which are ints. What you are talking about isn't really TYPE
checking, but more like VALUE checking.

Index can either return an index into the string, or
it can throw an exception. Both of these are complex result types that
hinder further type inference.

Why? index doesn't return an exception, it raises it. The return value
is always a non-negative int. Any function can in principle raise an
exception. If "can raise an exception" is enough to confuse the
type-checking tools, then you have some serious trouble.

 

[George Sakkis]

You are welcome to change the specifications of findall() and turn it into
an iterator which returns each match one at a time instead of all at once,
but then the name is misleading, wouldn't you agree?

The regex module has since 2.2 a function (and method for regex
objects) called finditer that does exactly that. Perhaps str (and
unicode) should have it too for consistency ?

George

 

[Scott David Daniels]

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

From the perspective of writing C extensions, Guido claims that the amount
of pain (regarding memory management) is about the same whether you're
extending a reference-counted language like CPython or a garbage collected
language like Java. Anyone with experience writing C extensions want to
comment on this?

This is probably true for extensions written from scratch. From the
point of view of connecting an existing block of code, Python made a
great choice. If allocated memory doesn't need to move, and the garbage
collector needn't get to _all_ the references in the system, the
extension can make blocks of memory and include references to it in
their own code, in their own format. They simply need to hold the
objects in a Python-visible way. If the memory system needs to move
allocated blocks, many data structures lose their efficiency in a
haze of either adjusting and identifying references or indirection
through piles of tables. One of the hard problems of talking "cross-
language" has to do with "who is in charge of memory."

Lots of languages are happy to allow interaction with another language
as long as the other language is restricted to writing subroutines
fitting the model of "the language really in charge." The fights are
usually about memory allocation, non-standard flow of control, and
intermediate data structures. C is easy to talk to because it was
conceived as a "portable assembly language". Only straight assembler
is easier to write language extensions in, because only assembly has
less of a preconception of how memory is used and what code is and is
not allowed to do. If you want to know pure hell, try to write a
program that has significant code in both Smalltalk and Lisp (or even
better, ML) in the same address space. They both want to be in charge,
and you will quickly decide the best thing to do is put each language
into its own process.

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. Guido says that they've only been able to get it to
work reliably in Python with constants, which isn't very useful.

Look at the Self language. That language has less of a surface concept
of type than Python (classes are not defined). Still, Self was/is used
as a platform to investigate type inferencing, code specialization, and
native code generation.


--Scott David Daniels
(e-mail address removed)

 

[Sakesun Roykiattisak]

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.

1. Automatic refactoring never solve the readability issue.
2. I've never been lucky enough to have enough resource for those IDE.
3. Python solve my problem.

 

[Aahz]

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.

Perhaps. But adding the time to learn those IDEs in addition to the time
to learn Java is ridiculous. I've been forced to use Java a bit to
support credit cards for our web application; I've got a friend whose
Java-vs-Python argument hinges on the use of Eclipse; I was unable to
make use of Eclipse in the time I had available for the project.

Meanwhile, I'm busy with a code base that I doubt any IDE could handle...

 

[Ivan Van Laningham]

Hi All--

Perhaps. But adding the time to learn those IDEs in addition to the time
to learn Java is ridiculous. I've been forced to use Java a bit to
support credit cards for our web application; I've got a friend whose
Java-vs-Python argument hinges on the use of Eclipse; I was unable to
make use of Eclipse in the time I had available for the project.

Were there _good_ reasons not to do the credit card part of the web app
in Java instead of Python? As in, there is no secure module, or you
didn't have time, or Python doesn't support crucial APIs? I'm very
curious.

f u cn rd ths, u cn gt a gd jb n nx prgrmmng.

l tk t.

Metta,
Ivan
----------------------------------------------
Ivan Van Laningham
God N Locomotive Works
http://www.andi-holmes.com/
http://www.foretec.com/python/workshops/1998-11/proceedings.html
Army Signal Corps: Cu Chi, Class of '70
Author: Teach Yourself Python in 24 Hours

 

[Aahz]

Were there _good_ reasons not to do the credit card part of the web app
in Java instead of Python? As in, there is no secure module, or you
didn't have time, or Python doesn't support crucial APIs? I'm very
curious.

The problem was that we needed to use a vendor-supplied library.

 

[Ron Adam]

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
here:

http://www.itconversations.com/shows/detail545.html
http://www.itconversations.com/shows/detail559.html

Thanks for the links Dave.

He talked a fair amount on adding type checking to python. From
reading his blog on that subject, it seems Guido is leaning towards
having the types as part of function and method definitions via the 'as'
and/or '->' operator in function and class argument definitions.

My first thoughts on this was to do it by associating the types to the
names. Limiting reassignment of a names to specific types would be a
form of persistent name constraint that would serve as a dynamic type
system.

Has any form of "name constraints" been discussed or considered
previously?

Regards,
Ron

 

[Simon Brunning]

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.

I'm a Java programmer as my day job, most of the time, and I use
Eclipse. I'm fairly proficient with it, but nevertheless I'm more
productive with Python and SciTE than I am with Java and Eclipse.
Eclipse helps a lot, true - I certainly wouldn't want to code Java
without it or something like it - but it's not enought to pull ahead
of Python's inherent superiority.

 

[Simon Brunning]

1. Automatic refactoring never solve the readability issue.

Eclipse's refactorings are a great boon, I find. Refectoring is never
*fully* automatic, of course, but the ability to, for example, select
a chunk of code and have it extracted into a separate method with all
needed arguments and the return value worked out for you is very
helpful. All you have to do is give the new method a name. And this
sort of thing can certainly improve readability.

2. I've never been lucky enough to have enough resource for those IDE.

Eclipse is indeed a memory hog of the first order.

3. Python solve my problem.

Mine too - but I'm not free to choose.

 

[Stephen Kellett]

Eclipse's refactorings are a great boon, I find. Refectoring is never
*fully* automatic, of course, but the ability to, for example, select
a chunk of code and have it extracted into a separate method with all
needed arguments and the return value worked out for you is very
helpful. All you have to do is give the new method a name. And this
sort of thing can certainly improve readability.

This is not an attach on you Simon, but if people are relying on that
type of thing for increases in software productivity they are hiring the
wrong people.

Stephen

 

[Dave Benjamin]

This is not an attach on you Simon, but if people are relying on that
type of thing for increases in software productivity they are hiring the
wrong people.

I think that the right people to hire are the ones that can make the
best use of whatever tools are available so they can get their job done
well and in a reasonable amount of time.

I'm not a big fan of Java programming, but sometimes I have to do it,
and when I do, I must say that the refactoring capabilities of IDEs like
IntelliJ IDEA are very helpful. Being able to rename classes, variables
and functions across multiple files, extract methods with automatic
naming and typing of parameters and throws-clauses, and move methods
from one class to another makes it so much easier to reorganize and
improve large amounts of code. And due to Java's verbosity, there
usually is a lot of code to manage even for simple changes.

In Python, there's still a need to do these sorts of things. Typically,
we use "search and replace" and "cut and paste" instead. You could make
a similar statement about those tools - if you rely on "cut and paste"
to increase your productivity... gah, it makes me cringe just writing
that! Nonetheless, I would hate to program without "cut and paste" as a
tool. In any language.

The need for automatic refactoring tools in Python is smaller; Python
gives you the opportunity to program at a higher level of abstraction,
so there is less code to deal with. In addition, since Python doesn't
have checked exceptions or require type annotation, design changes tend
to "splatter" less across your code base. Still, Python's dynamic nature
limits the sort of automatic changes you can make reliably, and we ought
to recognize that. By using Python, we are making a tradeoff: in
communicating less information, we are forcing IDEs to do more
guesswork. Java requires less guesswork for the IDE, but requires
significantly more communication on behalf of the programmer. I don't
think it's a cut-and-dry win for either language.

Dave

 

[Dave Benjamin]

1. Automatic refactoring never solve the readability issue.

True, but with the aid of automatic refactoring, you can make code more
readable, by splitting up classes and functions, giving things better
names, etc.

Another readability issue in a similar vein is "intellisense" /
context-sensitive menus. They allow you to give every class and method
really long or confusing names without slowing you down, since you can
just pick it from a menu. But I think this has some negative consequences.

First, as you've stated, you still have to read the code. Second, you
become reliant on these menus, rather than just "flowing". For instance,
I almost never have to look up documentation for any of Python's list,
dictionary, and string methods. They're short and simple, and they're
easy to memorize. I think this is at least partially a consequence of
the fact that people type them in, by hand, all the time, so they're
designed to be friendly and memorable.

2. I've never been lucky enough to have enough resource for those IDE.

It's worth noting that IntelliJ IDEA has gotten rather slow and bulky
with the more recent releases. It used to be pretty quick. Emacs, which
was at one point considered a total resource hog, is lean and mean in
comparison, and doesn't seem to be expanding much these days... =)

Dave

 

[Markus Wankus]

This is not an attach on you Simon, but if people are relying on that
type of thing for increases in software productivity they are hiring the
wrong people.

Stephen

Have you ever tried anything that provides real, usable refactoring like
Eclipse does with Java? I guarantee if you used it more than a few
times your view would most likely change.

The fact is, code evolves. You simply cannot write high-quality
software in one pass. Good refactoring tools save time, and therefore
money. I sure wouldn't hire anyone who thought otherwise...

Markus.

 

[Stephen Kellett]

Have you ever tried anything that provides real, usable refactoring
like Eclipse does with Java? I guarantee if you used it more than a
few times your view would most likely change.

I was forced to use Eclipse recently. Dreadful. I really disliked it. I
never got as far as wanting to refactor things. I couldn't wait to stop
using it.

The fact is, code evolves. You simply cannot write high-quality
software in one pass.

Total agreement. My point is that productivity gains from refactoring
tools are the least of your worries. Hiring good staff that know how to
write, test and debug software is very much more important than the
amount of time a refactoring tool will save.

Stephen