* Rami Chowdhury:
On Thu, 12 Nov 2009 11:24:18 -0800, Alf P. Steinbach <al...@start.no>
wrote:
* Rami Chowdhury:
On Thu, 12 Nov 2009 09:32:28 -0800, Alf P. Steinbach <al...@start.no>
wrote:
This also seems religious. It's like in Norway it became illegal to
market lemon soda, since umpteen years ago it's soda with lemon
flavoring. This has to do with the *origin* of the citric acid,
whether natural or chemist's concoction, no matter that it's the
same chemical. So, some people think that it's wrong to talk about
interpreted languages, hey, it should be a "language designed for
interpretation", or better yet, "dynamic language", or bestest,
"language with dynamic flavor". And slow language, oh no, should be
"language whose current implementations are perceived as somewhat
slow by some (well, all) people", but of course, that's just silly.
Perhaps I'm missing the point of what you're saying but I don't see
why you're conflating interpreted and dynamic here? Javascript is
unarguably a dynamic language, yet Chrome / Safari 4 / Firefox 3.5
all typically JIT it. Does that make Javascript non-dynamic, because
it's compiled? What about Common Lisp, which is a compiled language
when it's run with CMUCL or SBCL?
Yeah, you missed it.
Blurring and coloring and downright hiding reality by insisting on
misleading but apparently more precise terminology for some vague
concept is a popular sport, and chiding others for using more
practical and real-world oriented terms, can be effective in politics
and some other arenas.
But in a technical context it's silly. Or dumb. Whatever.
E.g. you'll find it impossible to define interpretation rigorously in
the sense that you're apparently thinking of.
Well, sure. Can you explain, then, what sense you meant it in?
I think that was in the part you *snipped* here. Just fill in the mentioned
qualifications and weasel words. And considering that a routine might be an
intepreter of data produced elsewhere in program, needs some fixing...
You'll also find it impossible to rigorously define "dynamic language"
in a general way so that that definition excludes C++. <g>
Or, for that matter, suitably clever assembler. I'm not arguing with you
there.
So, to anyone who understands what one is talking about,
"interpreted", or e.g. "slow language" (as was the case here), conveys
the essence.
Not when the context isn't clear, it doesn't.
And to anyone who doesn't understand it trying to be more precise is
an exercise in futility and pure silliness -- except for the purpose
of misleading.
Or for the purpose of greater understanding, surely - and isn't that the
point?
I don't think that was the point.
Specifically, I reacted to the statement that <<it is sheer nonsense to talk
about "the" speed of an implementation>>, made in response to someone upthread,
in the context of Google finding CPython overall too slow.
It is quite slow. ;-)
Cheers,
- Alf
--
http://mail.python.org/mailman/listinfo/python-list
