Comment by exDM69 | Hacker News Reader

Comment by exDM69 | Hacker News Reader

Parent Full thread

> Compilers generate assembler, which is about as imperative as it gets...

Yes. In the very end of the compilation the compiler emits machine code or some kind of byte code, which is imperative by nature.

Before that, the compiler must do a lot of analysis and optimization. All of which happens in some intermediate representation, which is as little imperative as possible. In order to get there, the compiler does different control flow and data flow analyses such as live variable analysis, the goal of which is to turn mutable variables into immutable values. It has a resemblance to functional programming in some sense (you can read research papers about SSA, single static assignment and it's equivalence to CPS, continuation passing style, if you're interested).

So in the end, we get assembly or some kind of byte code, but a lot of magic happens to get there. Back in the 1970's, C was like portable assembler. These days the compiler does so much magic that it's not true any more.

We could use any language as the source language for compilation but yet we stick to an ill-fitted C-based languages that are really painful for the compiler and the programmer.

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.

> 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