On May 22, 2:43 am, sturlamolden <stu...@molden.no> wrote: > On 21 Mai, 20:20, Patrick Maupin <pmau...@gmail.com> wrote:
> > Also, any company in a competitive > > market where execution speed is extremely important might choose some > > other language because, frankly, the fact that a development tool is > > highly productive is not something that the end user directly cares > > about. > > That only applies to CPU bound program code (most program code is I/O > bound), and only to computational bottlenecks (usually less than 5% of > the code) in the CPU bound programs. Today, most programs are I/O > bound: You don't get a faster network connection or harddrive by using > C. In this case, performance depends on other factors than choice of > language. That is why Mercurial (written in Python) can be much faster > than SVN (written in C). > > For computational bottlenecks we might want to try high-performance > numerical libraries first. If that does not help, we can try to > replace some Python with C. Python as "glue" does not mean Python is > inferior to C. It just means it is a PITA to write C or Fortran all > the time. I value my own time a lot more than a few extra CPU cycles. > Who cares about speed where it is not needed? I think we're in violent agreement here -- you neglected to quote the part where I said "(But the up-front choice of another language simply for speed, rather than prototyping with Python and then recoding the slow bits, would probably be a decision borne of ignorance.)" Regards, Pat -- http://mail.python.org/mailman/listinfo/python-list
