Many programming languages put boxes around the bits that the CPU actually operate on. These boxes often store things like reference count and type (or a dispat

Many programming languages put boxes around the bits that the CPU actually operate on. These boxes often store things like reference count and type (or a dispatch table for object-oriented languages with single-dispatch). That thing inside a box that is the actual value is called an atom. Those boxes have a lot of overhead (in PHP it's around 140 bytes!), and because a major identified problem is the waste of valuable cache space and CPU time book-keeping these boxes, a lot of JIT and compiler research is about how to eliminate the boxes. You can see why they do this when considering a program like: $a = array(); for($i = 0; $i < 100000; ++$i) $a[$i] = rand()*65536; sort($a); which might take 200k (and fits easily in cache) in C/C++ but 15 megabytes (and doesn't) in PHP. However. Eliminating those boxes has proven to be very difficult, and while I have heard great things about Java 10, I am reserved because I also heard great things about Java 5. And Self. I do not expect JIT/compilers will get smart enough to actually solve this problem in my lifetime. On the other hand, array programming languages allow you to get that space-overhead that C/C++ has in an interactive (and usually interpreted) language, so it so happens that you don't have to choose between a nice interpreted programming language with introspection, automatic memory management, and so on, and high performance, but it does mean you have to program the arrays instead of the atoms. I do not understand how that source file is "OO business logic".