Let's be very, very generous here and assume that it would take twice as long to code something in C that it would in Python. Let's assume that the code isn't a static library, but something like a web app or equivalent. Doubling the number of developers to get the 10x speed up / 90% reduction in server use is not worth it from an environmental perspective. Those developers use resources to live. They burn fuel to heat their dinner. They drive their car to work.
These types of arguments are trying to make an emotional plea to a perceived market failure. The solution is to fix the market, not waste time implementing stuff in C. Tax pollution at the rate at which it would take to clean it up and the market will automatically allocate resources efficiently.
From an economics point of view you are just wrong. Because of the vast numbers of computers used in 'scale out' architectures the impact of code efficiency is enormously bigger than the cost of developers. If a developer's code runs on 10 or 100 machines then you are correct. But modern software runs on hundreds or even hundreds of thousand machines.
Most software that ships to hundreds of thousands of computers is software that must run on other people's machines. If it must, then it is automatically in the markets best interest to optimize to require less overhead since it will give them access to a larger portion of the market. If it is for their own internal servers, then again it is in the market's best interest to roll it in C or similar since they are able to make the distinction as to where it is worth it to convert it to a lower level language.
Ooh, ooh, Betteridge's Law of Headlines - http://enwp.org/Betteridge%27s_Law_of_Headlines - has the answer: no.
But when your goal is first to market, and trying to get the MOST OUT OF THE PROGRAMMERS - it is a waste of human resources, and programmer enjoyment using a compiled language with an unfriendly syntax.
Of course, you could find experienced programmers who are super fast productive, and super happy to work in the compiled languages - but don't underestimate that most people enjoy interpreted's ease of getting started, and syntax simplicity - and usually they cost less to hire as there is a larger pool of people.
while (1)
{
// check for input
}
And no offense to the TFA, but all the academic code I've seen is buggy, slow, and inefficient - hardly using "every ounce of efficiency". For example, the most popular data processing tools I've seen in engineering are matlab and excel (!). Not exactly coding to bare metal.http://shootout.alioth.debian.org/u64q/which-programming-lan...
compare 2 |- |--- 25% median 75% ---| -|
Fortran Intel 1.00 1.00 1.00 1.01 1.35 1.87 7.84
C GNU gcc 1.00 1.00 1.01 1.21 1.55 2.36 4.97
C++ GNU g++ 1.00 1.00 1.10 1.26 1.68 2.28 2.28
ATS 1.00 1.00 1.24 1.45 2.30 3.90 7.24
Ada 2005 GNAT 1.04 1.04 1.22 1.51 1.84 2.76 4.81
Java 7 -server 1.40 1.40 1.59 1.90 2.14 2.97 4.76
Scala 1.38 1.38 1.90 2.76 3.43 5.72 10.21
Haskell GHC 1.53 1.53 2.60 2.80 4.36 7.00 15.15
Go 1.29 1.29 2.12 2.85 6.90 14.08 24.05
C# Mono 1.60 1.60 2.62 3.08 7.12 13.88 14.21
Lisp SBCL 1.12 1.12 1.81 3.40 4.24 7.89 11.20
OCaml 1.18 1.18 1.76 3.75 4.87 9.24 9.24
Pascal Free Pascal 1.53 1.53 2.47 4.37 7.49 15.03 24.20
Clojure 2.02 2.02 3.50 4.99 8.44 14.81 14.81
F# Mono 2.97 2.97 3.16 5.33 8.92 17.57 37.80
Racket 1.22 1.22 5.06 6.86 11.04 19.99 59.08
Erlang HiPE 5.17 5.17 7.99 10.79 15.44 26.61 41.54
Erlang 5.40 5.40 14.20 22.73 30.09 53.91 218.10
Python 3 1.22 1.22 9.25 49.73 68.86 131.37 131.37
PHP 1.90 1.90 10.29 50.17 83.42 193.10 260.90
Ruby 1.9 4.67 4.67 11.74 53.29 101.33 235.71 356.61
Ruby JRuby 5.75 5.75 26.67 58.81 115.06 247.65 266.51
Perl 4.00 4.00 22.61 103.29 126.82 225.35 225.35CO2 is only a problem if we let it be.