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

[Superpelican]

After this question getting down voted and put on hold on programmers.stackexchange.com, I decided to take it here, as HN seems to be better suited for discussion about such a topic. Copy of the question:

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?

[wmf]

It often seems that today imperative programming is considered outdated and inferior to functional programming.

Only among the kind of people who bother to consider that question at all, which 99% of programmers don't.

[nikdaheratik]

1. I believe the premise this question is based on is flawed. As other commenters have said, Functional vs. Imperative is not a binary state, but rather a sliding scale. Imperative is much closer to how the hardware works than Functional, so your style will need to be more "Imperative" if it needs to deal with lower level stuff.

2. Computer Science is very new and different styles move in and out of vogue as new tools and techniques are discovered. In this case "hype" is merely another term for "yesterday's cool approach". Just as "make everything an object" came and went, leaving its mark on every language, "make everything a function" will probably be less emphasized, but still an important approach that leaves its mark in most CS.

[bjourne]

Imperative programming wont die, but more an more of the languages we use are functional. SQL, CSS, HTML.. The last two are declarative, I know, but they fit very well into a functional paradigm.

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.

[AnimalMuppet]

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

[theseoafs]

> SQL, CSS, HTML

None of these languages are "functional" by any reasonable definition of the term "functional". CSS and HTML aren't even programming languages.

[rmah]

yes

[Superpelican]

Would you mind elaborating your answer? It currently isn't clear to which question you are answering yes. ;)