Hacker News Reader

Comment by mikemike | Hacker News Reader

Converting to SSA form is comparatively easy. The interesting question is how pure a particular SSA variant actually is (hint: almost none are in practice).

Just the fact that a language is closer to SSA form doesn't make it interesting. If a compiler is able to turn pretty much every source language into SSA, then why should I bother to do part of its work by hand? Much more relevant is how easy it is to express my intentions as a programmer and how much of that ends up helping the compiler and the CPU to execute the code faster.

I really don't want this to turn into a flame-war about the merits of functional programming. The Wikipedia article has a nice list of the typical concepts: http://en.wikipedia.org/wiki/Functional_programming#Concepts ... and the particular mix simply doesn't appeal to me personally.

View on HN

It's interesting that you say that you are doing the compiler's work when you program functionally.

Imperative compilers have three steps: they compile from an imperative language to SSA (which is almost functional), they then optimizes the SSA and then convert back to an imperative language.

The reason that they convert the program into SSA is because it is much easier to reason about the program in that form. My take is that imperative compilers are an admission that functional programs are easier to reason about.

>My take is that imperative compilers are an admission that functional programs are easier to reason about.

If you're implying that "easier to reason about" for a compiler is equivalent to "easier to reason about" for humans, I think that's a fallacy.

Where functional programming fails is in performing tasks that are predominantly imperative; say, anything involving real-time behavior, like games or animation. And by "fails" I mean that an imperative language is easier for humans to follow when it maps more directly to the problem at hand.

> If you're implying that "easier to reason about" for a compiler is equivalent to "easier to reason about" for humans, I think that's a fallacy.

I would like to know why you think that. The same predominant factor, complicated interactions, prevents easy reasoning in both cases.

I don't agree that functional programming fails in those cases.

What kind of code do you write? I write games (and, recently, UI-heavy interactive apps that talk to servers).

Even the most strident FP advocates I know who are real game developers say that they wouldn't even consider using a strictly functional language for game development. IO-heavy apps in general seem like they're not a good use of functional languages.

Different programming paradigms suit different problem domains. It's not complicated interactions that would make it harder to understand for a human; it's that when you try to use a language for something that it isn't well suited for, it can be hard to figure out what the program does or how it works.

The objective isn't to write the most clever code, or even the code that's easiest to reason about, but the code that works and is easy to understand.

> If you're implying that "easier to reason about" for a compiler is equivalent to "easier to reason about" for humans, I think that's a fallacy.

It's easier to reason about for the developers who are writing the compiler transforms, ie. humans.

Agreed--I think functional programming comes a lot closer (or at least it can, in theory) to expressing programmer intentions. The compiler doesn't have to deal with side effects and all of their hairy consequences (escape analysis, aliasing, inferring dependencies, ...).

Reply on news.ycombinator.com