Python versus Perl

Terry Reedy tjreedy at udel.edu
Sun Sep 11 21:08:46 CEST 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