But is that not the point of the post - that all the 'easy and cheep' comes at a huge cost to be planet and eventually to the company. Are C# and Java really that much harder to learn and use?
It's trivial to write monstrously inefficient C/C++ - arguably it's even easier than writing slow Python code, because high level concepts like events and callbacks are harder to express programatically and code that should be event-driven becomes:
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.
Most real scientific computing (quantum mechanics - in which I did my doctorate, meteorology, astrophysics etc.) is done in C or more normally FORTRAN. The code will use highly optimised routines like BLAS. It is normal to perform careful inner loop optimizations for each target platform.
Fair enough, but you do realize that not everyone will optimize inner loops after switching to C/Java? Certainly not to the extent of scientific computing or even the language shootout snippets.
Also to address the power usage of one server. The 6.6 tonnes number seems to come from having the server drawing 1kw of power continuously for an entire year. The biggest server I could find on Dell's site (E910) comes with a 1.1KW power supply. This DOES NOT mean that it draws 1.1KW continuously. Indeed, outside of peak usage hours it probably draws much less. This is amortized over many users as well. Even slow, interpreted languages can serve hundreds of users on such a server.
Compare this to driving 10 miles/day in a medium-sized car. This produces 2 tonnes of CO2 annually, and unless you're diligent at carpooling, probably serves one person. Even a small car will still use half of that. If some new software helps even a small number of people telecommute instead of driving, the result is overall positive. For this to work, such software has to be cheap (certainly cheaper than driving) and for that to happen programmer time must be conserved.
Good arguments. I based 1kw on the 800 watt rating of the machine mentioned plus a/c etc. It is all ball park and I am a bit shocked you are the only person to call me out. But it does not matter because if you 1 tonne per year - it is still plenty. The car thing is a good point to make but I think you are stretching it with the telecommuting. This is especially so as the key to telecommuting if fast software (ever tried implementing video streaming in an interpreted language?) The amortized over many people point correct but not valid to the argument as it is a multiplicative not additive effect it has as no impact on the over all calculation.
You have not been looking at scientific computing. Matlab is more something people used for comp-sci of math. If it was not FORTRAN then it was not scientific computing.
I believe within 20 years, we will have unlimited energy from the sun, and this will not be an issue. I don't know whether an interpreted languages is that much easier, but I do believe that any language that gets people writing code and solving interesting problems quickly can't be too bad a choice.
Unfortunately - right now - we do not have unlimited energy. If we did - then the argument simply shifts to the limited mineral resources we have to make the computers...