Ask HN: Does imperative programming have a (mainstream) future?

I have written a few small programs in Python and C++ and am currently learning F# (I am already quite familiar with FP concepts, as a result of reading the Learn you some Haskell tutorial until the monad part ;) ). And while I appreciate the elegance of functional programming in some situations, in other situations I just feel that it would be more natural to write a particular algorithm imperatively with mutation and I certainly can't imagine programming my Arduino board in a functional way for example.

It often seems that today imperative programming is considered outdated and inferior to functional programming. So my question basically is: does imperative programming have a future outside of some niches? What do people with practical experience with both functional and imperative programming think? Will the programming world slowly shift to functional programming languages or will functional programming languages merely continue to influence imperative programming languages, leading to tacked on FP features (like in the latest versions of Java and C# and Ruby, Python etc.) or is functional programming in mainstream languages just a hype all together?

I don't think Haskell or F# will ever make it big (for many reasons, to many to go into detail on here). But regular imperative languages are getting more functional oriented. Like LINQ expressions, list comprehensions, immutable data structures (Clojure is big on that) and TCO (very beneficial for fp).

It's a sliding scale and it doesn't matter so much if the language is categorized as functional or imperative. It's how you approach problems you solve with your language. I think more and more programmers are realizing that the functional approach is almost always superior.

Only for a very limited definition of "almost always". It's almost always superior if you don't hit performance constraints, and if your problem isn't dominated by sequencing, and if your team can handle the functional approach, and if...

Why is it superior? It controls the state space explosion, and therefore makes it easier to understand and reason about your program.

Why could performance be a problem? Think about a functional quicksort algorithm. It doesn't do mutation, so at each stage, it has to return a new sorted list rather than sorting the list in place. As the list gets longer, the performance gets worse compared to an imperative quicksort.

Now, quicksort would actually be implemented as a library, and would be tuned for speed. But the same issue comes up in other ways. If you have to transform data structures, imperative can be more efficient than functional, and the difference grows as the size of the structure increases. (I could have called this area "scaling" instead of "performance".)

When could your problem be dominated by sequencing? It often is in embedded systems, where you're sequencing external hardware to get it to do real-world things. I mean, yes, you could write all that in a monad, but if that's the dominant thing you need to control, what does it gain you?

All that said, making any individual function pure (in the FP sense) is always at least a local win, because that function becomes simpler to understand, debug, and test.