Functional Programs Are Imperative Pumpkins

https://blog.eventsourcing.com/your-functional-programs-are-imperative-pumpkins-d722ec1358b7

by yrashk • 10 years ago

56 72 10 years ago

blog.eventsourcing.com

smt882• 10 years ago

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.

subway• 10 years ago

Probably because as the author mentions, they weren't trying to rationally decide on a language/ecosystem, but looking to rationalize the decision they already made.

wyager• 10 years ago

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.

smt882• 10 years ago

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.

paulddraper2• 10 years ago

It goes the other way too though.

Records, for example.

Chinjut• 10 years ago

What does the word "pumpkins" mean in this context?

mrow84• 10 years ago

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

yrashk8• 10 years ago

Yes, that's the allusion!

The implication was that rather systems composed of functional programs but non-functional databases are not functional (i.e. the functional components are dwarfed by the imperative nature of mainstream databases)

nickbauman• 10 years ago

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.

smallnamespace7• 10 years ago

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.

mtrn• 10 years ago

While not new, I find the discussion around immutable storage important and interesting. Datomic[1] comes to mind. There are many scenarios and applications, where it would be nice to just write things to a structured log and build an application on that log.

Unfortunately there are some roadblocks, like little information and conversation about the topic and no real mainstream implementation of these ideas.

I've been working on a system, that has is based on an immutable data layer and it is just a wonderful thing to work with, as long as you have enough disk space.

[1] http://www.datomic.com/

smallnamespace7• 10 years ago

I'm curious, how is this different from using an event oriented database, or using your normal DB but changing the schema to be oriented around immutable events?

clusmore2• 10 years ago

Offtopic to the OP but related to Datomic.

I saw Rich Hickey's talk about Datomic recently and immediately thought it would be ideal as part of a distributed runtime. Without having actually programmed in Erlang, but having seen plenty of Joe Armstrong's talks, I understand that the point of replicating data in messages rather than passing around pointers is so that if a machine dies, the data isn't lost. But if you built a distributed runtime that used Datomic as a distributed heap on which you allocate large amounts of data which you expect to pass around a lot, you could instead pass around only pointers to the data and not worry about data loss, and save big time on message throughput. Does anybody know if something like this already exists?

wz10002• 10 years ago

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.

js82• 10 years ago

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

ridiculous_fish• 10 years ago

Monad is not itself an escape hatch, but Haskell's escape hatches are mostly monads (ST, IO, etc). Monads may be a functional programming idiom, but monads in Haskell are deeply magical. So "monad = escape hatch" has some basis in reality.

It's important to distinguish between imperative code and IO. Many pure algorithms are most naturally expressed imperatively. Viewed in this way, Haskell is actually pretty bad at imperative programming.

Myers Diff is an example. See diffST2 at https://hackage.haskell.org/package/uni-util-2.3.0.1/docs/sr... for the Haskell version. Notice how simple expressions in Myers's paper, such as `V[k−1] < V[k+1]`, explode into ugly things:

    vkplus <- readArray v (k+1)
    vkminus <- readArray v (k-1)
    (x,l0) <- if vkminus < vkplus...

Here we've paid a syntax tax for mixing the "imperative" array-read with the "pure" value comparison. Similarly, notice how the 10-line recursive `scan` is a less-readable implementation of a one-line while loop in the Myers paper.

So in practice, Haskell is rather painful to use as an imperative programming language.

Silhouette• 10 years ago

Monads are just another functional programming idiom, defined by two regular functions, `return` and `(>>=)`.

But in terms of I/O with the outside world, monadic patterns become useful in Haskell because the type of your main function is also `IO ()`. That's the "escape hatch", not the use of monads in itself.

KirinDave5• 10 years ago

Everyone knows the real escape hatch is unsafePerformIO!

seagreen• 10 years ago

  no program can be purely functional

Pure functional programming means building up a machine. This machine will eventually be executed by the runtime system (at which point IO will happen) but from the programmer's perspective a program can still be purely functional.

By this I mean that a function that takes an Int and outputs an Int will have type `Int -> Int`, and a function that takes an Int, does logging, and outputs an Int will have type `Int -> IO Int`. Both are purely functional -- they're pure transformations from an Int to some other thing. For the first function that other thing is another Int, for the second that other thing is an action that can be performed by the machine which will return an Int.

So from the perspective that matters to us a developers programs can be purely functional.

(This becomes even more useful with something like PureScript's granular effect tracking https://github.com/purescript/purescript/wiki/Differences-fr...)

smallnamespace7• 10 years ago

Yes, in Haskell monadic functions are strictly speaking still pure functions, but it's the set of mutations performed by the package of runtime + your code that matters.

Do-notation shows that there's a trivial mapping between monadic code and imperative code. For all practical intents and purposes, things happening in the IO Monad are not 'functional', because your mental model needs to consider the mutations they represent.

What functional programming encourages you to do (as opposed to OOP) is segregate the pure aspects of your program, under the theory that pure code is easier to write, maintain, and test.

charlieflowers• 10 years ago

No, that's not exactly what he is saying. He's saying we write logic in pure functions, but then save the data in a mutable database. But he's saying we don't have to -- with event sourcing, even the data we store is immutable, so more of the system can be purely functional.

agumonkey• 10 years ago

All but benchmarks.

clusmore2• 10 years ago

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

I agree with the point that a program can't be purely functional, but lately I've been wondering if you could still have a programming language that is purely functional (preferably also total). It is designed for writing data transformation libraries and needs to be called into by a stateful language that handles IO and orchestration. If you've seen Gary Bernhardt's talk Boundariers [1], this language would be the purely functional core.

[1] https://www.destroyallsoftware.com/talks/boundaries

michaelklein• 10 years ago

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.

bobthechef• 10 years ago

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?

djfm2• 10 years ago

Probably because event-sourcing is beginning to trend.

The article is not that interesting in itself, but the conclusion is a good starting point for a conversation that may be.

Systems are largely not functional. But they can be.

So, how?

yrashk8• 10 years ago

My research into this topic has led me to lazy event sourcing so far https://blog.eventsourcing.com/lazy-event-sourcing-ed7e59007...

My current view is that by eliminating or reducing the need to serialize domain objects, we're creating a system which is easier to argue about and provides an easy way to adjust domain models as the understanding or circumstances evolve.

skrebbel3• 10 years ago

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.

jdeisenberg• 10 years ago

Elixir has more to offer than just a functional approach; there is OTP, lightweight processes, etc. If these are things you need, Elixir might still be an excellent choice.

keithnz• 10 years ago

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.

KirinDave5• 10 years ago

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.

runT1ME2• 10 years ago

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.

KirinDave5• 10 years ago

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.

paulddraper2• 10 years ago

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

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

marssaxman• 10 years ago

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

Ace17• 10 years ago

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

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

yrashk8• 10 years ago

Perhaps!

Functional Programs Are Imperative Pumpkins

Related Stories