This is an awful lot of invective from one paragraph that, personally, implies an itinerant bad programmer migrating from 'cool language' to 'new cool language' and carting along everything he'd written before.
If he had meant only that and meant nothing more, he wouldn't have singled out Perl, or he would have done so in a more tactful manner. And ask yourself, is this really a big problem? How often have you actually seen someone embed Perl (or any other language) in Python? Why is that admonition sandwiched between remarks on unit testing and maintaining control flow?
On another note, everyone seems to love anonymous, first-class functions with closures, and yet they never give nontrivial examples - what am I missing out on?
Spend some time with a language that not only supports them but actually encourages their use, and you will see for yourself. For example, both Smalltalk and Ruby make heavy use of blocks, and because of that classes can be written to allow users to greatly customize their behavior without the need of subclassing.
(For that matter, I still haven't seen what TCO offers that is new, but that was April's issue.)
TCO allows programs to, in certain circumstances, reuse existing stack frames for possibly many function invocations. For example, if a function is written to be tail recursive, a VM with TCO could reuse the same stack frame for each recursive function invocation until the terminating condition is reached, at which point the last return value is caught and the frame is popped off the stack. (TCO isn't strictly limited to making tail recursion more efficient, but that is its most often cited benefit.)
The main reason Guido and his Pythonistas have no use for TCO is that they also have no use for recursion. If Python supported TCO, more recursive Python code would probably be written--and that would be very unpythonic.
Spend some time with a language that not only supports them but actually encourages their use, and you will see for yourself.
This isn't an example and does nothing to convince me that it's actually useful. Your suggested application just hints at difficult debugging when a Car object can be a stealth Truck. Maybe it isn't actually difficult, but why is this actually better than subclassing?
TCO allows programs to, in certain circumstances, reuse existing stack frames for possibly many function invocations. For example, if a function is written to be tail recursive, a VM with TCO could reuse the same stack frame for each recursive function invocation until the terminating condition is reached, at which point the last return value is caught and the frame is popped off the stack. (TCO isn't strictly limited to making tail recursion more efficient, but that is its most often cited benefit.)
Don't fall into the Turing equivalence tarpit. It's indeed possible to rewrite recursive code in terms of iteration and vice versa, but the most natural expression of many algorithms is recursion. If you can convince the compiler and/or runtime to manage your stack for you, you can concentrate on the interesting parts of the algorithm.
It's like the difference between using objects in Smalltalk and writing your own object system in C.
The problem is that adding TCO to a mature and widely-used language introduces a massive compatibility problem!
If Python supported TCO, more recursive Python code would probably be written
And not be able to run on Python implementations without TCO!
Code that takes advantage of TCO is utterly dependent on it. It is absolutely not an 'implementation detail', or really an 'optimization' -- its presence is a major part of the semantics of any language implementation that does it.
If he had meant only that and meant nothing more, he wouldn't have singled out Perl, or he would have done so in a more tactful manner. And ask yourself, is this really a big problem? How often have you actually seen someone embed Perl (or any other language) in Python? Why is that admonition sandwiched between remarks on unit testing and maintaining control flow?
On another note, everyone seems to love anonymous, first-class functions with closures, and yet they never give nontrivial examples - what am I missing out on?
Spend some time with a language that not only supports them but actually encourages their use, and you will see for yourself. For example, both Smalltalk and Ruby make heavy use of blocks, and because of that classes can be written to allow users to greatly customize their behavior without the need of subclassing.
(For that matter, I still haven't seen what TCO offers that is new, but that was April's issue.)
TCO allows programs to, in certain circumstances, reuse existing stack frames for possibly many function invocations. For example, if a function is written to be tail recursive, a VM with TCO could reuse the same stack frame for each recursive function invocation until the terminating condition is reached, at which point the last return value is caught and the frame is popped off the stack. (TCO isn't strictly limited to making tail recursion more efficient, but that is its most often cited benefit.)
The main reason Guido and his Pythonistas have no use for TCO is that they also have no use for recursion. If Python supported TCO, more recursive Python code would probably be written--and that would be very unpythonic.