Julia compiler explained

@oxinabox this is for my saturday session: gonna try to explain a compiler to non-technical people in 5 minutes...

"To understand why Julia is so special and different, we need to understand how it works from the bottom up.

Computer code goes through many stages of processing from when you write `x = 3` to when it actually assigns that value inside of it to a memory register.

The last part of this process is what we will conveniently call compiler - it is in essence a glorified warehouse manager - it takes orders about boxes of stuff (bits!) and moves them around in the computer (memory!). Let's assume the picture is this simple our purposes.

Now that we have a mental picture of what a compiler is, we can separate Julia from other languages and see why it is special.

We will now imagine what they have to do.
These managers have to take your invoice of boxes/bits to move around, and they have several available places where they could do so.  The key to how much space they have is how close it is: They might only have a spare shelf in their own office, a spare room in the same building, a storage across the street, or a warehouse on the other side of town to store and move all your bits. They can immediately fetch something that is available on their shelf(or a cache 1 register) but it will take them about an order of magnitude or more to get it from the next bigger storage place available.

Moral: speed comes from knowing how and where things are stored.

Now, it so happens that there are two main approaches or camps of managers that have arisen in this computer world.

Older warehouse managers/languages - C, Fortran, C++, etc. - are old school. They're extremely experienced and fast, but they're real sticklers for how you order payments, and if it so happens you made a typo on the invoice order for the precise size of the 5.7x3.2x4.3cm3 paperclip boxes, they will spit in your face and not compile at all. These managers need to know the size of every single box on your invoice and where it has to be moved where and when. If you supply them with that painstaking information, they will use their decades of experience in warehouse management to aggressively move your shipment through their system of storage.

Newer warehouse managers/languages - R, Python, Matlab - have a more millennial on-the-fly feel. They are not concerned at all with sizes  on the invoices, and interpret the sizes of the boxes once they come through by 'boxing' and 'unboxing' every single container that has to come through. It's great because you never have to spend fortnights in the back and forth of preparing the invoice, but you can't really expect them aggressively optimize their warehouse process, because they can never remember the precise size of things, even when they are handing out to themselves within the warehouses.

If you stuck through the explanation, here's the super cool kicker on why Julia is so different: 

X-RAY VISION!

Essentially, enough people got sufficiently exasperated at this whole culture divide of ruthless or inefficient warehouse people that they decided to breed their own super manager. Here's how Julia works:

Like the lazy camp, this Julian manager will not ask your for any specific invoices. However, the first time you try to put a shipment through their warehouse, he will use an X-Ray state of the art vision (or if we wanna be fancy, subtyping inference algorithm) to try and determine the exact size of the contents of the box *without you telling it*.
This means that the second time you try to put a shipment through this same manager, he will be able to aggressively optimize the warehouse procedure on your shipment, *just as well* if not better than the old school manager.

In practice: Julia code will infer the sizes of things you want to move through memory the first time, and be as slow as Python, and the second time you want to move the same order through, it will be as fast as C, *if* it was able to infer sizes