Magnus Lycka wrote: > Isaac Gouy wrote: > >>I think it is wrong to call Python "very slow" just because it is slower > >>than some other language or languages, for the same reason it would be > >>wrong to describe the population of the UK as "very low" because 60 > >>million people is a smaller number than China or India's one billion plus. > >>Doing so merely reinforces the premature optimizer's message that any > >>language that isn't C (and sometimes Lisp) is "not fast enough". > > > > There was some context: Is python very slow compared to C? > > But that is a stupid context. It doesn't really tell us > anything. Slow at what?
As I said: We can make /the missing context/ in the OP's question more obvious... > > No one writes a program for the purpose of doing loops, > comparing integers, setting up stack frames or jumping > between instructions. > > The context for programming typically involves solving some > problem or executing a function that matters to the user. > > It's just as database benchmarks. TPC C benchmarks tells us > how fast a certain database is at performing TPC C benchmarks. > Does that tell you anything about how fast it will be compared > to competing products for your real world problem? Probably > not. Which ever product you choose, you might end up with > situations where a particular function is too slow. You can > typically solve this either by changing the code or the > configuration of the server. Sometimes you have to rethink > your system and solve the problem in another way. Changing > from e.g. DB2 to Oracle is unlikely to have more impact than > these smaller changes. It's the same thing with most software > development. > > >> The benchmark you pointed to are of limited use for application > >> developers. (Their value to language designers is another story.) > > > > Limited use for what purpose? > > They are more or less useless for anyone who wants to decide > what programming language to use in a real world situation. Good that's more explicit. One of the program contributors told me they do something quite similar to fasta, k-nucleotide and reverse-complement in their real world situation. Isn't it possible that someone would look through The Computer Language Shootout programs and decide that language X was unusable convoluted gobbledegook? > It's simply stupid to implement sorting algorithms in Python. > It's there already. Solving Ackermann's is also rather far > from what people typically want to achieve. What "sorting algorithm" are you talking about? There isn't one on http://shootout.alioth.debian.org/gp4/ Solving Ackermann's? Well if that was really the point then the programs would be allowed to use memoization rather than simple recursion. > If people actually > had the time and resources to create real software products, > (i.e. things that take man-months to create) from the same > spec, and developed e.g. ten programs each each ten different > programming languages in cleanroom conditions, we'd probably > learn something useful about the usefulness of a certain type > of programs with certain programming languages in certain > conditions, but only in these conditions. I'm rather certain > that aspects such as team size, development methodology etc > will influence the relative ratings of programs. > > I'm not saying that the typical toy benchmarks are completely > useless. They might tell us things about particular language > features that should be improved, or give us clues that a > certain way of solving a particular problem etc, but they > don't really help Joe Newbie Programmer who wants to write > yet another web site toolkit. -- http://mail.python.org/mailman/listinfo/python-list