6: Just In Time.

Many languages are adopting a model of just-in-time compiling. Do you know how this affects you? This episode will discuss the advantages and disadvantages of just-in-time compiling. Instead of using the source code directly and interpreting each line and instead of compiling everything up-front, just-in-time gives you benefits from both approaches and then some. There are some gotchas to be careful of though. For example you might think that because you compile your source code first and distribute an intermediate language, that your source code is safe within your company. But in many cases the first compilation can organize your code and then with all the extra information that is included to make sure that your code is behaving well, you can actually end up with intermediate code that is better than your original. Listen to the full episode for more about just-in-time compiling, or read the full transcript below. Transcript Let’s say some new microprocessor with some new instructions just came out last year. Not all of your customers will have upgraded yet so what do you do? You could have special versions of your application for the old and new processors but managing that and expecting the customer to understand is tough. Even if your customer understands what you’re doing, will the customer be able to figure out which version of your software to install? And what if the customer does upgrade their processor after installing the old version of your software? Will your software know that it can now take advantage of the new instructions? Flexibility and the ability to run your application on a variety of platforms is really good but there has traditionally been a cost with this. In order to get the most flexibility, you need to interpret your source code. But interpreting the source code on the target platform means that the source code must be available. And many companies don’t want their source code to be publicly available. For a long time, the only answer to this was to compile the source code to a common and well supported set of microprocessor instructions. This is not so bad really. I mean, sure, the customer still has to make sure to install a Windows version of your software on a PC, or an OS X version on a Mac, or a Linux version on Ubuntu. But most of the time, this can be handled automatically for the user when the user navigates to your download page. Your download page can detect the user’s operating system and provide the correct link. The customer gets a compiled version of your application that runs fast. But what if there was a way to compile your source code not directly to the microprocessor itself but to something that another program could understand? This intermediate step would be independent of any specific microprocessor and platform. It would need to go through a second compilation before it could actually run. This second compilation could wait until it was about to run and would have the specific information about all the instructions available. You might even get benefit not just from additional microprocessor instructions but from more advanced libraries or newer techniques in software that were unknown previously. This solves many problems actually. I mentioned that some companies don’t like the idea of releasing their source code. With this system, the source code can remain safely within the company and only the result of compiling the source code to the intermediate language needs to be sent to the customer. However, you do need to consider that the intermediate language is quite well formed and might actually be easier to understand than your original source code. There are ways to make the intermediate language more confusing by using a program called an obfuscator. An obfuscator mixes up your code that gets sent to your customers making it difficult for anybody to understand what’s going on. Just be aware that like any engineering decision, there&