
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:<p>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&#x27;t imagine programming my Arduino board in a functional way for example.<p>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.

~~~
Superpelican
>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?

That was exactly what I was referring to with the Arduino board example ;)

~~~
chas
Haskell has been used to build embedded software to great effect. As you move
out of the domain of simple sequencing in embedded systems and into hard
realtime systems, coordinating tasks correctly becomes very difficult. Being
able to track and infer information about timing and dependencies with the
type system becomes extremely useful in order to make it easier. This is a
very simple intro example of an DSL built in Haskell for realtime systems[0].
This is a talk on using Haskell for robotics in particular[1].

[0] [https://leepike.wordpress.com/2009/05/05/an-atomic-
fibonacci...](https://leepike.wordpress.com/2009/05/05/an-atomic-fibonacci-
server-exploring-the-atom-haskell-dsl/) [1]
[https://vimeo.com/77164337](https://vimeo.com/77164337)

------
rmah
yes

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

