

Guido's final word on Tail Calls - uggedal
http://neopythonic.blogspot.com/2009/04/final-words-on-tail-calls.html

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

Viva la Gudio :)

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

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

~~~
jacobian
_I [...] expect Python to die well before the end of my professional career
[...]_

Why?

 _I do invest my time in longer term languages such as Scheme and Haskell._

What makes Scheme and Haskell "long-term" languages?

~~~
anc2020
> Why?

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"

------
finin
I love 'Basic of the future' as a slur/compliment for a programming language.

~~~
WilliamLP
If Python is the Basic of the future, then what is the PHP of the future?

------
danbmil99
nice hack returning the next function in the chain. As a FSM user I will
probably need this someday.

~~~
adamc
As the comments mention, it's an old technique called a trampoline.

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

~~~
10ren
Another point of view is to be disappointed in language theory, if one can be
so incredibly successful without it.

Reminds me of Edison.

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

~~~
10ren
_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>

