PHP/Python/Ruby - Immoral? | Hacker News Reader

Ruby - Immoral?

nerds-central.blogspot.com

5 pointsNerdsCentral29 comments

I hate environmentalists. Don't get me wrong, I love the environment, I even call myself a geolibertarian at Mises conferences, but the problem I have with environmentalists is that they think "the world doesn't boil down to dollars and cents" (This was actually said to me).

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.

You shoot down our own argument. The video suggest C# and Java as alternatives to interpreted languages. By picking C you are deliberately trying to make your argument sound stronger than it is. The video also mentions the economic cost.

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.

The video wouldn't run in my OS (which isn't standard, granted, but still).

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.

"PHP/Python/Ruby - Immoral?"

Ooh, ooh, Betteridge's Law of Headlines - http://enwp.org/Betteridge%27s_Law_of_Headlines - has the answer: no.

For scientific computing and data crunching, trying to get the MOST OUT OF THE HARDWARE, I would agree you are wasting resources using a interpreted language, and it is inefficient.

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.

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?

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...

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.

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.

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.

Don't talk about things you don't understand.

> Don't talk about things you don't understand.

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.

I have to disagree here. Although I know that the speaker is just trying to have fun with the idea the metaphor is flawed. whereas a Mercedes engine gets more and more powerful and not any more efficient computer processors are getting more efficient by the day. also the "10 to 100 times slower" comment seems like an exaggeration to me. In the end the language you use should be decided by what will give your customers the best software possible and nothing else. Because its not immoral to waste the computers time but it is immoral to waste the users time.

There are plenty of bench marks showing 10 to 100 times is in the ball part. Computers use masses of power because there are so many of them. As they get more efficient, their numbers increase. The benefit of using faster languages is constant irrespective of the efficiency of the machine on which it is running. How can wasting energy be OK? Even if you don't think it has climate change effects, it has economic and energy security effects - non of them good.

I wouldn't say its OK to waste energy but you have to put things in perspective. Your first concern should be to save the users time. The less time they have to use the program to achieve their goal means less instructions. Videos like these aren't looking at the bigger picture.

If code runs faster then the user time is wasted less as well. That seems in alignment with the ideas behind the video.

I don't want to hear the "faster programs save the user time too" argument its total BS. the vast majority of CPU time is spent waiting for the user. So while you're on a holy quest maximizing 100,000 instructions down to 1,000, every second that the user wastes dealing with your neglected UI 1,000,000,000 cycles are wasted (and that's on a machine with a single 1ghz processor).

The post is talking about servers. Most scripting is for code running on servers. Servers do not wait for the user. Your comment has zero merit.

no.. your comment and your whole shortsighted video have no merit. Servers spend time waiting for users as well. Whether its waiting for the next HTTP request or the next batch processing job servers wait for people too.

OK, I'll explain this as you clearly have no idea what you are talking about. When one commissions a server or server farm it is done against a service non functional requirement. For example 1 second page serve time at peak load. This means that a lot of the time the servers might be waiting but not a peak load. Never the less, modern servers will clock down if waiting. Now, what sets the peak load is the efficiency of the software and the number of people using the server and/or the run length of the batch jobs. The more efficient the software the less servers are required to meet the peak load and so the less power is used all the time. Further, the more efficient the software the less often servers will have to clock up during off peak times. Do you finally get it? If not - I suspect you have zero idea about large scale computing and are here only to defend your lack of ability to program anything other than scripts.

The page below shows the media peformance of Python (the fastest in these of PHP/Ruby/Python) as 49.73 times slower than the fastest compiled language. The seems pretty much between 10 and 100 to me.

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.35

...and then they embed Flash in the page. I wonder how much energy gets wasted by my CPU fan being driven to 100% on Flash sites :)

Yes - HTML5 would be much much better - it will come soon I expect.

Although I will concede that flash is an abomination that needs to be removed from all my computers. haha

Yes - I said that some time ago.. http://nerds-central.blogspot.co.uk/2007/06/why-flash-is-per... and http://nerds-central.blogspot.co.uk/2010/05/steve-jobs-agree...

Opposing nuclear power is immoral. Writing code is ruby is good sense.

CO2 is only a problem if we let it be.

Not sure of the connection here. BTW - check out the nerds-central post on why Thorium matters if you are pro-nuclear - it might have some good amo for you to use.

"All things techi and nerdy!" - I cannot wait to have the power to downvote.

Reply on news.ycombinator.com