On Fri, Aug 22, 2014 at 4:12 PM, dieter <die...@handshake.de> wrote: > Likely, you would not use Python to implement most parts of an > operating system (where, for efficiency reasons, some parts > are even implemented in an assembler language). > > I can imagine that the GNU compiler developers, too, had good > reasons to implement them in C rather than a scripting language. > It makes a huge difference whether you wait one or several hours > before a large system is built. > > "firefox", too, seems to be implemented in C/C++. There, too, I > see good reasons: > * it is nice when your pages are rendered quickly > > * "firefox" depends on lots of external libraries, all of them > with C/C++ interfaces; while is is possible to create > Python bindings for them, this is quite some work > > * as it is, "firefox" is a huge "memory eater"; one might > fear that things would be worse if implemented in a > higher level language (with everything on the heap). > Though, the fear might not be justified. > > > All these examples are really large projects. I like Python a lot > for smaller projects.
Yep. But it's not so much large vs small projects; these are all situations where it's entirely plausible to saturate a CPU core for a while, so the performance penalty of a high level language will actually matter. (That said, though: Firefox has a lot of non-performance-critical code, which AIUI is implemented in a higher level language than C. And a long 'make' run probably involves some shell scripting and such, not pure C code. Even high performance projects have their less-critical parts.) Similarly, I'd be pretty worried if someone rewrote X11 in Python. But if your program's going to spend most of its time waiting (for the user, for the network, for the real-time clock), halving its CPU usage won't materially affect anything, and halving development time will make a huge difference. That's when Python is an excellent choice. At my last job, we had some parts written in Pike, some written in PHP (not just the web site), and one back-end engine in C++. Toward the end, I wanted to redo the C++ engine in Python or Pike, because I didn't think the performance hit would be at all visible, and it would have been much easier to work on. (I'd also been progressively taking over jobs that PHP code had been doing and giving them to Pike processes instead, with a not-so-secret goal of eventually ripping out the PHP engine altogether. But that for other reasons.) As a back-end process, its performance would be hard for the end user to see directly, so the cost of a high level language would simply have been that the server could cope with fewer requests per hour before we need to requisition more hardware. Alas, there wasn't development time available for the translation (we were far too busy doing things about which I said "YAGNI" and the boss said "Do it anyway"), but I firmly believe that we wouldn't have been suffering from the performance hit. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
