[DanWaterworth]

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.

[SomeCallMeTim]

>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.

[DanWaterworth]

> 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.

[SomeCallMeTim]

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.

[naasking]

> 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.

[zwegner]

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, ...).