4 ms·

I can see good uses for that if you're programming a Mars rover. On the other hand, you lose the concept of "known versions" with that, and I wouldn't want it

I can see good uses for that if you're programming a Mars rover. On the other hand, you lose the concept of "known versions" with that, and I wouldn't want it anywhere near audited code. And in most circumstances it suffices to stop and restart.

voldacar 7y ago
Yeah, it is definitely niche. However it is super cool to be able to do optimizations like constant propagation and loop unrolling using information that would never be available at compile time. For instance if you have a function that evaluates an argument and branches based on the value, and if for some other reason your program knows that after a certain condition the argument will always have the same value, it can just optimize away that branch while the program runs. Now that is kind of contrived, but one real world example I ran into happened when I was writing a program to render 2d plots of complex functions. If you hardcode the equation of the function into the source code, the compiler can optimize it (important, since this function gets called for every pixel in the image being rendered) but the program is limited to rendering that one function. If you let the user enter that function at runtime in the form of a text string, your program has to essentially act as an interpreter by creating an AST from the string then walking the AST repeatedly for every single pixel, so obviously much more costly. The ideal solution is to have an environment where code can be seamlessly compiled at runtime and executed without extra ceremony or semantics that would be out of place in compile-time known code. In C you would have to attach a JIT to your program and manually write to an executable page etc, whereas in lisp the system handles all of that for you. Another example happens with config files: Config file data is used for conditional branching, but since it only becomes known at runtime, your progarm ends up with a lot of branches that would get optimized away if the config info had been known at compile time. You could just make all the config data compile-time known by having a something like a massive config.h full of #defines, but this is obviously not user friendly at all and makes it necessary to recompile every time you want to change a setting. If your code is able to introspect and optimize itself based on data that only becomes available at runtime, this tradeoff is eliminated.
flavio81 7y ago
>And in most circumstances it suffices to stop and restart. Only if your program is small and/or does trivial stuff. In ordinary languages, there's a significant loss of time to achieve the following, once a bug is found: - stop the running program - correct the offending function - recompile the program - restart the program again - interact with the program until you achieve the same conditions that caused the bug - confirm that the bug doesn't happen again. On a lisp system the steps are: - correct the offending function - re-compile the function (this takes milliseconds); this can even be done while other threads are running. - restart the stack frame where the error condition was found, and immediately confirm that the error doesn't happen again. The difference in productivity is remarkable.

voldacar 7y ago

Yeah, it is definitely niche. However it is super cool to be able to do optimizations like constant propagation and loop unrolling using information that would never be available at compile time. For instance if you have a function that evaluates an argument and branches based on the value, and if for some other reason your program knows that after a certain condition the argument will always have the same value, it can just optimize away that branch while the program runs. Now that is kind of contrived, but one real world example I ran into happened when I was writing a program to render 2d plots of complex functions. If you hardcode the equation of the function into the source code, the compiler can optimize it (important, since this function gets called for every pixel in the image being rendered) but the program is limited to rendering that one function. If you let the user enter that function at runtime in the form of a text string, your program has to essentially act as an interpreter by creating an AST from the string then walking the AST repeatedly for every single pixel, so obviously much more costly. The ideal solution is to have an environment where code can be seamlessly compiled at runtime and executed without extra ceremony or semantics that would be out of place in compile-time known code. In C you would have to attach a JIT to your program and manually write to an executable page etc, whereas in lisp the system handles all of that for you. Another example happens with config files: Config file data is used for conditional branching, but since it only becomes known at runtime, your progarm ends up with a lot of branches that would get optimized away if the config info had been known at compile time. You could just make all the config data compile-time known by having a something like a massive config.h full of #defines, but this is obviously not user friendly at all and makes it necessary to recompile every time you want to change a setting. If your code is able to introspect and optimize itself based on data that only becomes available at runtime, this tradeoff is eliminated.

flavio81 7y ago

>And in most circumstances it suffices to stop and restart. Only if your program is small and/or does trivial stuff. In ordinary languages, there's a significant loss of time to achieve the following, once a bug is found: - stop the running program - correct the offending function - recompile the program - restart the program again - interact with the program until you achieve the same conditions that caused the bug - confirm that the bug doesn't happen again. On a lisp system the steps are: - correct the offending function - re-compile the function (this takes milliseconds); this can even be done while other threads are running. - restart the stack frame where the error condition was found, and immediately confirm that the error doesn't happen again. The difference in productivity is remarkable.