Python versus Perl
Terry Reedy
tjreedy at udel.edu
Sun Sep 11 15:08:46 EDT 2005
"Michael Sparks" <ms at cerenity.org> wrote in message
news:43246da1$0$1290$ed2619ec at ptn-nntp-reader02.plus.net...
> That said, if you do describe it that way, it'd be more accurate to
> describe
> the python binary as a compiler/runtime rather than interpreter since
> it'd
> be more accurate.
If Java calls its runtime bytecode interpreter a 'runtime' rather than
'interpreter', so can we. Ditto, if applicable, to .NET clr. Still more
accurate, I think, is 'intergrated compiler and runtime'.
> It strikes me as ironic that python would probably gain more credibility
> with some circles if it had two binaries like this, even though it'd be a
> step backwards from a usability perspective :-)
Yes. The integration is a practical necessity for interactive mode with
alternative compile and execute. For batch mode, integration consists of
the very nice built-in mini-make.
> Personally I agree that any language that is described as interpreted has
> an
> image issue. However I'm not sure who's problem that is - some people
> claim
> it's "Python's problem", however personally I'd view as a problem for the
> people who buy into "interpretted bad, compiled good" argument. After
> all,
> they're the ones limiting themselves, and missing out on a whole class of
> languages (of which python is just one of course) !
That has been my response. And as a Python programmer, that is the end of
it. But as a responder/advocate, I am beginning to accept that the
misperception is wide enough to also be a bit my problem. Hence my small
effort for a more effective vocabulary. Thanks for your contribution.
Terry J. Reedy
More information about the Python-list
mailing list