I really love Guido's pragmatism. It's inspiring how he says "no" to a "would be nice feature" - - a feature that seems simple to implement at first, but probably would complicate a lot of things.
The subtle overtone here is the rather sensible conclusion that Python is not going to be an "everything language". I think the defining characteristic of a successful language designer is the ability to recognize and acknowledge the inherent limitations in your own language.
FTA:
> One other thing I learned is that some in the academic world scornfully refer to Python as "the Basic of the future".
I'm not from the academic community and have never heard anyone else say it before, but have thought of Python this way for quite a while now and am pleasantly surprised to see I'm not alone.
Thats not me being snarky, its a very serious observation - you'd get laughed at for learning Basic today. I'm young and expect Python to die well before the end of my professional career, so I do invest my time in longer term languages such as Scheme and Haskell.
I don't really expect Scheme to make a huge comeback (especially when there's Clojure to play around), nor do I think Python will die very quickly, so I don't fully agree with the poster.
However, a lot of new ideas are tried in Haskell, and I wouldn't be surprised if it gained importance as people make it more accessible. It's a very powerful and concise language.
Obviously I can't know it for sure, but my argument hinges on parallelism. Imperative programming isn't so well suited to parallelism as you probably know, and Python is sticking firmly to the imperative pseudo-code area of programming (which it does very well). Even for the scripting tasks I think in 10 years time it'll just be unacceptable to have so many cores under-utilised and functional languages make parallelism so much easier that it'll be a fairly easy choice to start coding a new project in those languages instead of Python. And then on top of this main argument, I'll just say you never know - I don't think people would have predicted the decline Perl has had to such a big degree (sure its not dead but its going that way). Python won't be here in 100 years (or 200, or 300..), I'm 100% sure. So I'm just arguing that the actual number of years left of Python is likely to be within 30 years. No-one knows the exact length, but my prediction is that its within that range.
> What makes Scheme and Haskell "long-term" languages?
They're just very simple and pure, and that's important for longevity because they aren't likely to be replaced in a kind of "major revision change" by a similar but better language, because they don't really need a big revision change, they're very good (or should I say "good enough") already. Python just doesn't so obviously provide the best language of its kind (dynamic, OOP, imperative) and is prone to be replaced by a different kind of language or a slightly different language of the same kind.
Both my answers are long enough that no doubt there'll be holes to pick in them. Eg. Should I have said "Scheme"? Well I don't think Scheme will ever make it big, but I do still think it'll be around in the long term to much the same degree it is now.
* By long term I meant at least 100 years for both Scheme and Haskell.
*Edit: That was a bit big, I'd like to correct it to "at least 30 years, and quite likely 100 years"
If nothing else, implementing a reasonably efficient but basic Scheme interpreter is a short exercise that can be done in a pinch. "Reasonably efficient" is a consequence of the proper tail recursion.
Well I've thought of Python that way for a while too, before I saw anybody else say it, but I meant it in a good way. It's like BASIC but actually useful.
I can see that connection, but not for the reason you list.
To me, Python is most like Basic in that new programmers can get started with it easily, unlike, say, Scheme or Haskell.
(And I love Scheme, but I have no illusions that it's a 'long term' language. I think something lispy will still be around long term, just not sure I'd put my money on Scheme.)
I am surprised (and to some extent disappointed) that he did not know about trampolines, as it's common knowledge among language implementors (e.g. it's used everywhere to implement proper tail recursion for FFI calls).
Somehow I though that being a language creator (or working on a compiler for a decade) implies unimaginable amount of knowledge...
Doing a lot trumps knowing a lot, even when you make mistakes. It's amazing what GVR has accomplishled despite (apparently) being ignorant of things other language designers know about.
I think GvR's special expertise is more in the 'user-interface' of programming languages than in their implementation. The whole point of Python, really, is to put the former before the latter; which is exemplified in GvR's 'readable-stack-traces before fancy-features-in-the-implementation' reasoning on the present point.
Even if you’re designing for professional programmers, in the end your programming language is basically a user-interface design. You will get much better results regardless of what you’re trying to do if you think of it as a user-interface design. Alan Kay http://queue.acm.org/detail.cfm?id=1039523
I was just starting some state-machine code in Clojure last night, thought about how to best do it functionally (recur doesn't let you cross function boundaries), and said out loud "I'll use a trampoline!"
If that happens again, I can tell the person I confused not to feel badly, because even Guido van Rossum didn't know about trampolines until recently.
Viva la Gudio :)