
Functional Programs Are Imperative Pumpkins - yrashk
https://blog.eventsourcing.com/your-functional-programs-are-imperative-pumpkins-d722ec1358b7
======
Chinjut
What does the word "pumpkins" mean in this context?

~~~
mrow84
I think it is an allusion to the story of Cinderella [0], some versions of
which have her carriage transforming (back) into a pumpkin at midnight.

I see the implication being that when all is said and done, functional
programs are really just imperative programs in disguise (I don't have an
opinion on the matter).

[0]
[https://en.wikipedia.org/wiki/Cinderella#Cendrillon.2C_by_Pe...](https://en.wikipedia.org/wiki/Cinderella#Cendrillon.2C_by_Perrault)

~~~
nickbauman
This pumpkin analogy goes away when you consider a a functional database is
one where only writes and reads happen (no updates). Indeed this is what
functional means: And object is distinct from its state because, in the real
world, we do not consider what something is to be the same as what happens to
it. Imperative programming locks the two together inseparably. Imperative is
where we are merely the accretion of what happens to us. We have no history
and no future.

------
smallnamespace
Isn't this article just stating the obvious fact that programs at some point
do I/O, so no program can be purely functional?

Every Haskell tutorial seems to introduce the IO Monad to illustrate this
distinction.

~~~
wz1000
I feel that one of the biggest misconceptions about monads and IO in Haskell
is that they are an "escape hatch" in the language that allows you to perform
imperative actions. This is plainly false. Monads are just another functional
programming idiom, defined by two regular functions, `return` and `(>>=)`.

What monads allow you to do is have a _purely functional_ model to represent
IO, among a great many other things. Haskell is, in a sense, the best
imperative programming language ever created, because it lets you manipulate
imperative statements in a purely functional manner. You can stick statements
in data structures, compose them, replicate them, generate them and only
evaluate them when you want to.

~~~
js8
I agree. But this is a misconception about functional programming in general,
that its purpose is to somehow replace imperative actions that are done by the
computer system with something else which is not imperative.

But that's not the goal. Functional programming is there to provide a better
formalism for writing programs, it doesn't want to change the way the
computers actually execute the programs (or how the systems eventually
internally work).

That means more work for the compilers to figure out how to make the same old
imperative program out of a functional one, which is a good thing (it's
generally the direction the compilers evolve).

Benefits of functional programming are not in how programs are executed (quite
to the contrary - it's actually more effort to make them as efficient as good
imperative programs), but in how the programs are written by people. I think
the article is a little confused about this.

For another example to see this, even notion of non-pure function goes already
in this direction. Today, having lots of (small) functions seems to have
negligible downsides, but historically this wasn't the case at all, look at
any better program that had to fit into memory of an 8-bit computer. These
were rarely written in this style, because compilers were simply not capable
enough to produce a reasonably compact spaghetti machine code out of those (by
means of inlining, for instance).

~~~
wott
To sum up: harder to write, harder to compile, harder to make efficient.
Hum... difficult to qualify it as 'better' after this.

~~~
js8
I agree with you. Yet, strangely enough, it is better. Maybe we could say,
easier to read, easier to modify, easier to reuse?

Let me return to that last example. Take a program written in procedural
style, and an identical program written in a big ball of mud style (all
variables are global, one big control flow). This is a discussion from like
1960s. It's harder to write for human, and harder for compiler to compile and
make efficient program in procedural style.

Yet, I am sure today, you would prefer procedural style. It makes sense (trust
me, I actually work with big-ball-of-mud programs written 30+ years ago at
work, AMA). I don't care what work the compiler has to do, I care about my own
time.

Functional programming is just another step on that road.

As a side note, I really think people who prefer FP should avoid (over)selling
it as more computationally efficient approach, because it still isn't (even
though it probably will be in the future). It's a little bit of optimistic
dishonesty that IMHO hurts adoption of FP and feeds the misconception that I
talk about.

------
smt88
This isn't directly related, but if this person wants FP + Java ecosystem, why
not use Clojure or Scala?

There are functional options for almost all of the big ecosystems now.

~~~
wyager
I mean, there are tons of features in Haskell that one misses when using
Scala. The type system isn't as useful, Scala's version of ADTs (case classes)
are really inconvenient to work with, different typeclass system, etc. Can't
speak for clojure.

~~~
smt88
I know that Clojure has its warts, but it seems to have a better reputation in
the functional community than Scala. Scala seems to want to support all
paradigms (or many paradigms simultaneously), whereas Clojure was created to
be more tuned to FP.

~~~
shark0
The difference between Clojure and Scala is that Clojure is a dynamically
typed LISP whereas Scala is statically typed. In the FP community, in general,
statically typed languages have a better reputation and are considered to be
more tuned to FP. Yes, Scala mixes OOP and FP but OCaml(famous FP language if
you've never heard of it) also does exactly that.

~~~
didibus
I wouldn't agree to that. LISPs were the first Functional Languages as FP has
its roots in Lambda Calculus. Scala is much more multi-paradigm, and I think
its further away from the FP languages. Even Wikipedia agrees: "An interesting
case is that of Scala[28] – it is frequently written in a functional style,
but the presence of side effects and mutable state place it in a grey area
between imperative and functional languages."

A lot of FP practitioners tend to come from academia and most of the research
currently lies in provability, so a lot of the FP community seems interested
in strongly typed languages, because they overlap the language research
communities, but I doubt anyone in the community would claim they are more
tuned to FP, because that's just a lie. In fact, a lot of the challenge of
typed FP languages is designing a type system powerful enough to express all
types of functions, so they're often more restrictive in how they can
implement FP.

[https://en.wikipedia.org/wiki/Functional_programming](https://en.wikipedia.org/wiki/Functional_programming)

~~~
shark0
Yes, Scala is multi-paradigm and it support OOP as well as imperative
programming but the community is very much dedicated to FP. All I see is typed
FP that expands my mind.

------
paulddraper
I think the essence of the point was made for me by reading "C is Purely
Functional" [http://conal.net/blog/posts/the-c-language-is-purely-
functio...](http://conal.net/blog/posts/the-c-language-is-purely-functional)

Functional and imperative are paradigms that can "encode" the other, so to
speak.

~~~
marssaxman
Appel's classic "SSA is functional programming" offers another interesting way
to look at this equivalence.

------
michaelklein
I don't get this. Any program that interacts with the outside world isn't
"pure", by this definition. What's wrong with using monads? With monads, you
can still do all those side-effecting operations, but be encouraged to
separate out the pure bits.

------
Ace17
From the article: The "Land of purity" lies above the "Dirty sea of data" .

Wouldn't "Dirty sea of state" be more appropriate?

~~~
yrashk
Perhaps!

------
KirinDave
Why do people, even obviously skilled and well-read people, conflate
functional programming with pure programming?

You so not need to have pure code to have functional code. You don't even need
to have pure code to use a monadic approach.

~~~
runT1ME
What do you think "Functional Programming" means? Obviously people and various
groups have their own made up definitions, but a commonly agreed upon
definition in the PL community might be "Programming with _Functions_ ".
Functions, by definition, are pure.

~~~
KirinDave
> Functions, by definition, are pure.

That's just not true in our domain. While it may be true in some categories,
we do not program in an abstract category. In our domain, "pure" functions are
distinct enough that we call them "pure" functions and even in Haskell we draw
a line between effectful code and pure code. As a core concept in modern
programming, the word "function" makes no judgement about how many side
effects are there.

I'm not sure why people think otherwise. Or perhaps all Lisp and OCaml
programmers are just liars and cheats.

EDIT: I just had a long conversation twitter about this and I'd like to offer
an example of a functional style we commonly use even with side effects: tail
recursive loops. We often use this modeling technique even in handling I/O
because it dramatically simplifies the logic for consuming a stream.

~~~
uryga
>> Functions, by definition, are pure. >That's just not true.

I think there's some naming confusion here. That's because programmers
overloaded the original meaning of "function" so that it's equivalent to
"procedure". So now when something behaves like an actual mathematical
function, we have to explicitly call it "pure".

PS. i remember seeing you in some Yogscast videos, used to be a huge fan of
those. funny to meet you like this.

~~~
KirinDave
It's perhaps confusing because people think the constructs they read about in
category theory have 1:1 mappings to the world of programming and they don't.
It's why we talk about the category Hask.

Every single concept is overloaded.

P.S., Wow. Someone here who knew about my hobby? I figured it'd never happen.

~~~
wz1000
> people think the constructs they read about in category theory have 1:1
> mappings to the world of programming and they don't.

Of course they don't. But they can still be considered a useful model for
programming in the same sense that Newtonian physics is a useful model of our
world.

~~~
KirinDave
Of course, but I still think it's important to remind people that functions
need not be pure to invoke the benefits of functional programming.

The article in question acts like it is a big surprise gotcha that functional
programs have imperative elements. This shouldn't be a surprise to anyone and
in fact it's a feature! The accessibility of that feature is often a major
component of what languages are judged on.

This isn't a point of semantics, it's definitely the case that we use
functional techniques in an imperative paradigm to great success.

~~~
yrashk
Thanks for the feedback!

It's not that functional programs have imperative elements or not. That's kind
of besides the point.

The point is that putting functional components into workflows that deal with
arbitrarily mutable data is reducing the potential we have with the functional
model.

The article is simply an open-ended invitation for a discussion on how to do
this (and it spark a little bit of that conversation) with some of the
proposed options on the same blog.

------
bobthechef
Why has this been upvoted? The author is a novice and provides no insight.
This just reads like he finally got to the second page of your standard book
on functional programming and somehow came to believe that everyone else is
still on page one. What village is this guy from?

~~~
skrebbel
> _What village is this guy from?_

I know this thread is about functional programming and so condescension is the
norm, but isn't it about time we change that part of our culture a bit?

You offer significantly fewer insights than the OP. Zero arguments, just name
calling. The author reads this thread and is a real person. Are you proud?

I, for one, found the article an insightful articulation of things I kinda
sorta already knew but hadn't acted on. Also our team is in the middle of
building an Elixir backend with a classically designed mutable DB so the
article helps me reflect. Maybe now is the better time to change this.

~~~
keithnz
I liked Elixir, other than it wasn't statically typed, but I found the
ecosystem quite young which means you will have to spend a bunch of time
purely keeping your code up to date with libraries as they change and if your
tech integration doesn't exist, you are on your own.

After a bit of consideration, I figured F# makes more sense for me. It has a
large ecosystem covering many technologies, its all moving to open source /
any platform. It also has lightweight processes, and lots of tooling.

~~~
skrebbel
I agree that there's little point in using Elixir currently if you don't need
its concurrency/robustness story.

