# Why imperative code is worse than functional code

**URL:** <https://discourse.haskell.org/t/why-imperative-code-is-worse-than-functional-code/7473>\
**Category:** Uncategorized\
**Created:** [August 29, 2023, 10:07pm UTC](https://discourse.haskell.org/t/why-imperative-code-is-worse-than-functional-code/7473 "2023-08-29T22:07:06Z")\
**Posts on this page:** 1\
**Showing post:** 30

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [September 1, 2023, 10:50am UTC](https://discourse.haskell.org/t/why-imperative-code-is-worse-than-functional-code/7473/30 "2023-09-01T10:50:44Z")

</div>

…and all of that is _“a bit”_ of a:

> [@](#):
>
> [simonpj:](http://discourse.haskell.org/t/beautiful-functional-programming/7411/23)
> 
> […] storm in [a] teacup!

Why? Because the questionable use of simple(ton) examples has probably occurred before:

- no doubt there were various snippets of assembly code which purported to show the superiority of assembly over that _“new-fangled”_ Fortran and LISP stuff.

- there probably were analogous snippets of code showing the superiority of `goto` over structured programming.

- and one can only imagine all the snippets of code purporting to show the superiority of manual memory ~~_manglement_~~ management over GC!

They are **all** examples of _“storms in teacups”_…the teacups found in child’s-toy dollhouses!

* * *

Getting back to the _actual_ topic of this thread:

> [@jaror](#):
>
> Why [is] imperative code worse than functional code?

**Mutation.**

While _The Anatomy of Programming Languages_ also nominates sequencing as being a problem:

- arbitrary sequencing but no mutation: [confluence.](https://www.cs.cornell.edu/courses/cs4110/2012fa/lectures/lecture14.pdf)

- arbitrary mutation but no sequencing: nondeterminism!

Standard ML and OCaml both illustrate this point - at first glance, definitions in both languages have little to no resemblance to the rambling sequences of statements found in the likes of Pascal or C. But that lack of visible sequencing is irrelevant: due to the relative ease of access to mutation both provide, Standard ML and OCaml are also imperative languages.

* * *

Alright, so what about Haskell and its use of [seemingly-inexplicable](https://wiki.haskell.org/Monad_tutorials_timeline) interfaces?

- 

> [@](#):
>
> (page 57 of 60)
> 
> […] the resulting language is undeniably complicated, and the monadic parts have a very imperative feel. I would be delighted to find a way to make it simpler and more declarative.
> 
> [Tackling the Awkward Squad: monadic input/output, concurrency, exceptions, and foreign-language calls in Haskell](https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.13.9123&rep=rep1&type=pdf) (2002).

- 

> [@](#):
>
> I don’t mind that we haven’t yet been [liberated from the von Neumann model](http://conal.net/blog/posts/can-functional-programming-be-liberated-from-the-von-neumann-paradigm). As long as [we] _remember_ [that] we haven’t.
> 
> As long as we keep on searching.
> 
> [Conal Elliott:](http://conal.net) [Is Haskell a purely functional language?](http://conal.net/blog/posts/is-haskell-a-purely-functional-language) (2010).

…for something better (or a proof that none exists, analogous to [that for the _Entscheidungsproblem_](https://www.ics.uci.edu/~lopes/teaching/inf212W12/readings/church.pdf)).

---

_[View the full topic](https://discourse.haskell.org/t/why-imperative-code-is-worse-than-functional-code/7473)._