install make

apt-get install make

Welcome to 2012, where linux ships in 800Meg distributions that don't even contain make and gcc.

CO2 is not a problem

CO2 IS FINE

It doesn't matter how much CO2 you produce, the only thing that matters is that all the CO2 produced is MANAGED in order to return to the initial state.

That means that we can continue burning fossil fuels as long as we plant X trees and build Y CO2 processing plants.

THERE ARE SOLUTIONS

The world is FULL of solutions to all those problems, from planting trees, to directly piping industry CO2 output to other systems, to recycling nuclear waste, to fusion energy and so much more.

So where's the problem ?

As usual, where the power lies, with the people.

You.

That's where the solution is, too.

facebook's HipHop for PHP is a lie

Ever since I heard about hiphop (from a beginner dutch programer's website -- ), I had my doubts about the approach, and my belief was that real Cpp would have been so much better than automatic PHP to Cpp translation+compile.


I of course knew that PHP was half a billion times slower than Cpp (actually just about 31 times), and even much slower than C (35 times says the benchmark), which is also the level of "highly optimized C++" code.

On facebook's HipHop php page, the presentation of HipHop is that it takes 50% cpu of the apache/php combo.


We of course already know that simply pre-compiling the PHP will yield such results (actually far better in the case of something as simple as facebook's web pages) - and the immediate conclusion is that their hiphop compiler is totally unable to bring PHP code to C-like speeds.

We also know that there are other simpler webservers (that can fit the facebook bill) than apache's httpd out there, most of which beat it in CPU and memory usage - the very fact that facebook did not write their own pure C web server tailored to their own needs is a mistery to me, considering the scale and infra costs.


According to the benchmarks currently available on the web, when PHP code is hiphop compatible (some major stuff is not, and the half-compatible stuff will compile but end up much slower), it can see anywhere from the same performance to between 2 and 10 times better performance, i.e. between 4 and 17 times slower than real Cpp.

The other major observation everyone made is that the better memory handling in the compiled version led to memory savings between 25 and 50%.

Not that bad for a facebook hack ;) Too bad it's mostly due to precompile and not to code quality.




If that's what they call "highly optimized C++", I'll make sure to stay away from anything they write in C++, including hiphop.

Otherwise, if you can't be bothered to find programmers that know C-fu, you'll find hiphop or APC can save you a lot on server bills.

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=php&lang2=gpp
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=php&lang2=gcc
https://github.com/facebook/hiphop-php/wiki
http://translate.google.com/translate?hl=en&prev=/search%3Fq%3Dalioth%2Bshootout%26hl%3Den%26lr%3D%26client%3Dfirefox-a%26rls%3Dcom.ubuntu:en-US:official%26tbs%3Dqdr:d%26prmd%3Divns&rurl=translate.google.com&sl=pl&twu=1&u=http://php.webtutor.pl/pl/2011/03/26/co-najbardziej-spowalnia-skrypty-php/
http://php.webtutor.pl/en/2011/04/02/hiphop-for-php-bechmark-english-version/
http://php.webtutor.pl/en/2011/05/17/drupal-hiphop-for-php-vs-apc-benchmark/
http://cassandra-php.blogspot.be/2011/05/lightspeed-php-performance-and-scaling.html


Note: I have since then improved the PHP submissions to the computer benchmarks game, and the difference between native PHP and C++ has shrunk considerably. There are however major performance issues related to PHP arrays, and one would expect Cpp to solve that problem entirely (the problems are on the order of 100x slower).

js Templating Engines

Before we even discuss templating engines, I believe it's worth pointing out the advantages of client-side markup generation:

Because your markup generator is cacheable and your templates too,

• you save A LOT of bandwidth
• the ONLY thing a returning user will transfer is the new data, i.e. the strict minimum you can transfer to create the page - considering you transport the data in an efficient format like gzipped json
• you save A LOT of processing power on the server-side (string manipulation is always expensive), spending a bit more on the client-side (not an issue, even 800mhz ARM is much too fast for such tasks)

To take advantage of that kind of stuff, just create js that will echo your html markup, with the parameters it got from json (you can put your json in a non-cacheable include js file, or get it via ajax), and make sure everything but the data is cached.

The only way to improve on that is to make the templating engine faster, and the unique data smaller (think about how much you can cache really -- like normalized data ;) ).

Lastly, I don't use any kind of templating engine, but all my client side except html,head,body,script is js-generated, and it's extremely fast, even on my phone.

On the other hand, I write web applications, not websites, so that might be why I don't care about that kind of crap  - web apps are best built with modules like in flex, which by definition handle the view and thus templating internally.

The Best Programming Language

There IS a best programming language

And we can find it by logic alone - what's the most useful code base in the world ?

Unix kernel

What's the best FPS game ever ?

Quake

The holy kernel is written in C.

The holy quake is written in C.

And the winner is C

Why is it so ?

The machine speaks ASM.

To have something humanly readable, we need the thinnest translation layer possible, a layer that would mimic ASM while abstracting the processor-specific instructions.

We have been using two such translations for three decades, and this is not going to change tomorrow.

The first is FORTRAN, which remains the fastest compute language available, barring ASM, and beating C by a tiny margin.

The second is C, slightly slower, but expressive enough to write EVERYTHING in it, including all the other languages - and it lets you include ASM, beating fortran hands down when it matters :).

When does a language become inferior to C ?

The second you remove the possibility to manually direct the ASM output.

There are many languages where it is IMPOSSIBLE to output the required optimized ASM for the task you're trying to accomplish.

There is NO valid excuse for removing that ability, since abstractions are built on top of each other and you can provide the most powerful abstraction along with no abstraction if you so desire.

Like there is NO valid excuse for removing the possibility to manage memory manually. Garbage Collection is a nifty tool, but unless you can turn it off and do the whole thing without, it's not a worthy addition.

As a summary, for a language to be better than C it must :

• provide the means to be as fast as C/ASM
• provide access to every feature C/ASM offer, including manual memory management
• provide higher-level abstractions as well

What about the others ?

I'll take Java and Python, because C# is a bad copy of java anyway and perl is mostly interesting for the regex goodness.

All those languages bring interesting "approaches" (or religions), syntaxes and operators.

But they're NOT in the same layer.

They're above C, they're not ASM translators, they're concept translators.

They essentially could just be C extensions (like Cpp) or C pre-compilers.

So yes, while some languages may bring some concepts or approaches to the front and enable more programmers to use them with ease, they're usually the equivalent of badly implemented C extensions, like the ultra slow ruby for example.

Mobile Development : HTML5 vs Native

http://blog.suthakamal.com/2012/08/go-native-html5-is-going-to-lag-for.html

That guy seems to think native is better because the web is slow, and while he clearly has a point for games (even chrome is not there yet), he's dead wrong on applications, and here's why.

1. most applications do not use 3D
2. the only "slow" thing in the [html5/css3/js] combo is js-loop-type visual effects (like fadeIn and that type of crap)
3. v8 is more than decently fast for js processing, firefox is meh-but-ok
4. most android phones today are powerful quad cores
5. those 100% CPU web apps have very low quality code, and that has nothing to do with the technology

Every application that is not a game can be implemented just fine in html5, and will be plenty fast in most browsers.

Now for the points that "native" does not address:

More than being limited to one OS, native is limited to a few versions of  an OS.

An HTML5/CSS3/JS solution (coded to standards) works -

on a phone

on a computer

on a smart TV

on a tablet

on google glasses

So sure, while some actually design games, and some others can totally afford developing a dozen versions of each application, with a dozen platform specialists to leverage all the platform-specific goodies, the simplest approach remains our good (but evil) friend, chrome.

Less comments, More readability

Comments are technical debt

Like code, they're to be maintained, unlike code they can be totally unrelated to what the processor will do.

Every line that is self-explanatory guarantees a single source of truth, avoids any possible confusion, and minimizes your technical debt.

Unlike code, comments only bring value when the code is revisited, which for so many projects rarely ever happens (I have yet to see code that looks like the 17th revision of refactoring cleanup of doom), and when it happens it covers about 1% of the codebase.

Too many comments

These days, you can find billions of comment lines in programs so simple that comments actually make the read far more complicated than just the bare code.

I can think of many but I recently read a bit of CodeIgniter (a PHP framework), which is so full of comments and empty lines that you need to reduce the line count to less than a fifth to make it readable.

Less comments is more readable

Unless you're using a very particular C or ASM trick (à la XOR var swap or better), which makes sense to explain, comments are useless to any decent programmer.

Let's consider the following code ...

 function sql_match($item,$rkeys,$rcomp){  
      $match=array();  
      for($i=0;$i<count($rkeys);$i++){  
           $match[]= "(".$rkeys[$i]." = " . "'".$item[$rkeys[$i]]."')";  
      }  
      return array_merge($match,$rcomp);  
 }  

I believe we can all agree this is perfectly clear, such a function is so short and so explicit that anyone looking at it will understand it instantly, even many who are not coders.

Would you add comments to this ? why ? what's the point ? It can only get less readable from here on.


Most code does NOT need comments



Let's see with a function that does much much more...

 function pre_edit_actions($p){  
      $p["post"]['changes']=array_change_key_case($p["post"]['changes'],CASE_LOWER);  
      return specific_pre_edit_actions($p);  
 }  
 function edit_item($p){  
      $p=pre_edit_actions($p);  
      if(!isset($p["iid"])){  
           $r=insert_rows(array($p["post"]['changes']),$p["iclass"]);  
           $p['iid']=$r[0]['id'];  
      }else{       
           $p["post"]['changes']['id']=$p["iid"];  
           update_rows_encrypt_password(array($p["post"]['changes']),$p["iclass"],array('id'),array());  
      }  
      return post_edit_actions($p);  
 }  
 function post_edit_actions($p){  
      if(isset($p["post"]['relation'])){  
           add_relations($p);  
      }  
      if(isset($p["post"]['relremove'])){  
           delete_relations($p);  
      }  
      return specific_post_edit_actions($p);  
 }  

Right here, we have a function that will create or update any item, as well as handle pre edit and post edit actions (like associated uploads or more) including creating and removing relationships with other items.

All so short you can't possibly misread them, with every function call or verification clearly named and everything.


I don't think code should be readable for non-programmers and I don't believe any programmer of any language would have any issue reading and understanding those functions under 5 minutes.

I also believe that the vast majority of code being written can be segmented and abstracted to a level where commenting is useless.

Another approach

Since such code, that is self-explanatory and well segmented/abstracted, implies almost zero commenting costs (don't underestimate the cost of writing clear comments), clearly improves code quality, also diminishing the debug and update costs, shouldn't we be focusing on those characteristics rather than frail comments that easily become stale, take at least as much time to express clearly, and add zero value in most cases ?



Do you have some code that still requires comments although it seems to be well written ?

Do you have a reason to make code readable by the non-programmers ?