In his book "Zen of Assembly Language", Michael Abrash has a chapter named "Billy, don't be a compiler" and tells the story of a man who coded Assembly like a C

In his book "Zen of Assembly Language", Michael Abrash has a chapter named "Billy, don't be a compiler" and tells the story of a man who coded Assembly like a C compiler. I apologize in advance, but I can't help but extend to you the same advice, cperciva. "Make it hard to figure out what your variables are by mixing up code with their declarations." In the right language, binding of variables is usually done by a LET construct, and within its scope where the variable is visible, the code is indented in ward. When you nest LETS you can see the liveness of a variable. "Construct new values" --> Manually do what the first pass of the compiler already does. Except don't use the const keyword He misspoke. He meant construct new variables. I am sure you would agree with him that a 'promiscuous tmp' is a royal pain in the ass when you're stepping through bad C code. "Make functions, not procedures" --> "Don't check for errors. Don't even make it possible to check for errors." Again, you're thinking at an abnormally low level of abstraction. Results are not for error handling, that's what the condition system is for (some erroneously call it an exception handling system) "Make your objects immutable" --> "Let's see how much time we can spend in malloc!" That's what the GC is for. When you make objects immutable you're buying yourself the piece of mind that comes with referential transparency. "Use purely functional data structures" --> "Arrays and hash tables are often the optimally performant data structures... but you shouldn't use them." There are ways to implement functional arrays and hashtables, but none too apparent without getting into academic wankery. I agree on this point.