Hacker News Reader

Comment by demallien | Hacker News Reader

Whoa, I think you're mixing things up there. Your original claim was that compilers get rid of the imperative nature of some programming languages. I pointed out that a compiler outputs something that is about as imperative as it gets, ie the compiler has made code mode imperative, not less.

The fact that compilers use s-expressions as an intermediate form says more about the recursive nature of most syntaxes than it does about the imperativeness or not of the program being compiled, and the program being output.

Also, as an aside, if you take some machine code that was compiled from C, even these days it is still ridiculously easy to take that code and turn it back into C. I have quite a bit of experience at doing precisely this. The only thing that has changed is that the compiler has got better at identifying code that is recalculating the same value over and over, and gets rid of that code.

View on HN

> Whoa, I think you're mixing things up there. Your original claim was that compilers get rid of the imperative nature of some programming languages.

Compilers most definitely try to work with as "functional" (ie. immutable values, not mutable variables) program representations as possible. Such as GCC's GIMPLE intermediate language and it's SSA subset or LLVM's IR "assembly". These languages operate mostly on values and try to avoid mutable variables as far as possible (like LLVM's mem2reg pass which does just this).

Getting to this intermediate representation from a C-like language is really painful (lots of iterative graph algorithms). Dealing with source level optimization in C-like languages is next to impossible and most compilers don't do this. Instead they transform the program to the intermediate representation with simpler semantics, which is most definitely less "imperative" than the source language.

A good compiler can use several source languages, which are translated to a common intermediate representation, where machine independent optimization takes place.

The final compilation phase from the intermediate representation to assembler re-introduces the "imperative" style to the program because the CPU operates that way.

> Also, as an aside, if you take some machine code that was compiled from C, even these days it is still ridiculously easy to take that code and turn it back into C.

If you crank up the optimizer to -O3 and give the compiler opportunities to optimize (inline functions or link time optimization), you cannot recognize the original program structure from the emitted assembly code except in the simplest of cases.

    The only thing that has changed is that the compiler has got better at identifying code that is recalculating the same value over and over, and gets rid of that code.

i.e. the compiler identifies pure functions and tries to move them out of any loops. On the other hand, you can't really restructure impure code that much. So basically, you are confirming what your parent said - the compiler has to first analyze the AST and hack its way around any IO and side effects before turning the optimized intermediate program representation into machine code.

Btw, the actual hardware could as well be a lambda calculus reducer instead of a von Neumann machine - in that case a compiler wouldn't emit anything imperative at all.

He's talking about intermediate representation and how some optimizations, such as SSA [1], are closer to functional style. In the end it's all imperative assembly, but during the optimization phase it can be something else.

[1] http://en.wikipedia.org/wiki/Static_single_assignment_form

I was thinking "Has he programmed in assembly?" Because it defiantly does not feel functional...

It's loading data into registers, and then performing operations on the registers. It feels like a turning machine changing state over time.

Reply on news.ycombinator.com