On Fri, 23 May 2008 14:00:33 -0700 (PDT), "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>On 23 mai, 10:42, "inhahe" <[EMAIL PROTECTED]> wrote: >> "Bruno Desthuilliers" <[EMAIL PROTECTED]> wrote in >> messagenews:[EMAIL PROTECTED] >> >> > Brad a écrit : >> >> cm_gui wrote: >> >>> Python is slow. >> >> >> It ain't C++, but it ain't a punch card either... somewhere in between. I >> >> find it suitable for lots of stuff. I use C++ when performance really >> >> matters tho... right tool for the job. Learn a good interpreted language >> >> (Pyhton) and a good compiled language (C or C++) >> >> > LordHaveMercy(tm). Could you guys please learn what you're talking about? >> >> > 1/ being interpreted or compiled (for whatever definition of these >> > terms) is not a property of a language, but a property of an >> > implementation of a language. >> >> That's like saying being spherical is not a property of planets, it's a >> property of an instanciation of a planet. > >I do definitively not have the required knowledge to say anything >about "being spherical" being part of the definition of what a >"planet" is or not. I wasn't going to mention this since it's really not relevant, but since you raise the question: Actually it was a bad analogy because being roughly spherical _is_ part of the definition of "planet". (Of course "spherical" must mean "roughly spherical" here, since no planet is exactly spherical.) A little while ago when Pluto got demoted so it's no longer officially a planet they came up with a definition - part of the definition is that the body is large enough that gravity causes it to assume a spherical shape. >>, and b) It's a far cry to >> imagine a planet coming into being that's not spherical > >Idem > >> (a language as >> dynamic as Python, or most other scripting languages, would be either >> extremely difficult or impossible to make a native compiler for). > >Now this I can tell is false. The problem is not that it's difficult >to "make a native compiler for" dynamic languages, the problem is that >it's difficult to write native compiler for dynamic languages that >generates code that beats the VM/byte-code interpreter/whatever you >name it to be wotrh the effort. > >> I guess I >> should also mention that Python isn't very practical (as in "suitable", >> "right tool for the job", and "perfomance", as mentioned in the above post) >> without an implementation. > >That is debatable. There are algorithm courses taught in "pseudo-code" >- that is, a language that doesn't have any known implementation. > >> So I don't think this distinction has any use >> other than to beat other people over the head with a bat. > >Ok, *you* know this - I mean, the distinction between a language and a >language's implementation(s). Are you sure everyone saying - or >reading - assertions such as "language XXX is slow" or "compiled >languages are faster" etc really know what they're talking about ? > >> > 2/ actually, all known Python implementations compile to byte-code. >> >> Which is then interpreted, but you're still technically right, because >> "compiled" can mean either compiled to bytecode or compiled to native code, >> despite what it actually did mean. Semantics FTW!! > >Yes, semantics. But a bit more than semantics - byte-code interpreters >are usually way faster than "pure" interpreter, and start to be fast >enough for quite a lot of practical use. > >Ok, I'll stop on this - once again, sorry for the noise, and please >bear with me, I tend to be a bit too much on the pedantic side >sometimes. But still, thanks to the pedantics peoples on usenet that >taught me so much so far and still teach me more and more... David C. Ullrich -- http://mail.python.org/mailman/listinfo/python-list
