"Anton van Straaten" <anton@appsolutions.com> writes:
> Yoann Padioleau wrote:
> > i dont see TCO as part of the design of scheme, but more to the design
> > of the compiler.
> > I prefer than a langage designer focus on programmer productivity rather
> > than program efficiency (that is why i hate all those C/C++/... langages).
>
> The mistake that C/C++ makes is that they strike the wrong balance between
> programmer productivity and program efficiency. That's a big issue that
> Scheme addresses very successfully.
>
> Programmer productivity and program efficiency can't always be completely
> separated, and certainly not in the case of tail-call optimization. Without
> TCO, a recursive programming style would often not be practical. Without a
> recursive programming style, much functional programming would not be
> possible. So tail-call optimization is an important feature for programmer
> productivity.
True. The only things i said is that i prefer a designer to focus
on programmer productivity. but i agree with you that you cant
always forget about efficiency.
>
> As I said in another reply just posted, the point is to enable programmer
> productivity, by ensuring that a programmer can rely on high-level
> abstractions without paying an undue performance penalty.
>
> This is one reason why it is possible to write systems like, say, the
> symbolic mathematics program JACAL
> (http://www.swiss.ai.mit.edu/~jaffer/JACAL.html) in Scheme. Even if someone
> was perverse enough to write such a system in Perl, the performance would be
> likely to be unacceptable. (Although, with a water-cooled hyperthreaded
> 3GHz Intel Xeon, who knows?)
>
> Anton
>
>
>
--
Yoann Padioleau, INSA de Rennes, France,
Opinions expressed here are only mine. Je n'écris qu'à titre personnel.
**____ Get Free. Be Smart. Simply use Linux and Free Software. ____**
|