19 ms·

Functional Programs Are Imperative Pumpkins

56 points by yrashk 10y ago

smt88 10y 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 10y 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 10y 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.
  - smt88 10y 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.
    - shark0 10y ago
      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 10y ago
        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 10y ago
        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.
        GFK_of_xmaspast 10y ago
        A lot of lisp people get testy when you call lisp a functional language.
  - paulddraper 10y ago
    It goes the other way too though. Records, for example.
Chinjut 10y ago
What does the word "pumpkins" mean in this context?
- mrow84 10y 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_Perrault https://en.wikipedia.org/wiki/Cinderella#Cendrillon.2C_by_Pe...
  - yrashk 10y 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 10y 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.
smallnamespace 10y 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 10y 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/ http://www.datomic.com/
  - smallnamespace 10y 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?
    - mamcx 10y ago
      Now I trying to use Event Sourcing (mainly for sync) for a "normal" invoice app, I find several problems. The thing is that the event log is good for write but awful for read. Re-compute everything is problematic and the true is 90% of the time you want the last version, not all the history. Also, the split in logic from the app / engine is stupid. I think is good if we move past the idea that the DB engine is more dumb than a rock, and embrace it. But current tools are not ideal (sadly, I know what is live like this: I have used Visual FoxPro!) Where I think this could lead to something great is if the DB is alike this: - Relational - You have normal tables. Consider them your up-to-date cache. Most scenarios will be covered here (ie: The log recomputing is NOT at the app level, but at the DB level). - You have a event log where everything is stored, plus your "tables" for the info you need up-to-date. But you don't need all to be a table if not make sense, and do full re-computation if desired. - Your backup, sync and load history is around the event log. - You don't even need a "table" if you wanna only a "index", this lead to me: - You submit a data request (like a POST), and the DB convert it to the tables and log, but: - You can instead (or also!) hook here and build secondary indexes and do other stuff. You can do it async, put the computation in a queue, do validations, etc as fit. So, what is not here and need tooling is marry the "normal tables" + "event log" + "logic that route this", so putting: Data -> WAL -> Router -> Event Log | Tables | Index | ping external tools And Request Data -> Router -> Get it from:Event Log | Tables | Index | ping external tools
deleted 10y ago
[deleted]
michaelklein 10y 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 10y 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?
- djfm 10y 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?
  - yrashk 10y ago
    My research into this topic has led me to lazy event sourcing so far https://blog.eventsourcing.com/lazy-event-sourcing-ed7e59007e17#.v3yqh7ukh 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.
    - djfm 10y ago
      Yeah, now this is a nice continuation to the conversation :) I too have been mildly obsessed with the kind of thinking you're developing in your post - very nice article! I've been very attracted to event-sourcing since I realized that now that React and redux have mostly solved the UI problem what remains to be solved is the problem of how to store our beautiful event-driven data. EDIT: re-read your comment, felt the need to say that your "current view" is exactly mine too
      - yrashk 10y ago
        I am happy to continue this conversation off-HN, perhaps Gitter? http://gitter.im/eventsourcing/eventsourcing http://gitter.im/eventsourcing/eventsourcing
KirinDave 10y 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.
- runT1ME 10y 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.
  - deleted 10y ago
    [deleted]
  - KirinDave 10y 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.
    - uryga 10y ago
      >> 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.
paulddraper 10y 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-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 10y ago
  Appel's classic "SSA is functional programming" offers another interesting way to look at this equivalence.
torkable 10y ago
I just read an entire blog post that simplifies down to "IO is not pure". Can I have my time back?
Ace17 10y ago
From the article: The "Land of purity" lies above the "Dirty sea of data" . Wouldn't "Dirty sea of state" be more appropriate?
- yrashk 10y ago
  Perhaps!

56 points by yrashk 10y ago

smt88 10y 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 10y 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 10y 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.
- smt88 10y 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.
  - shark0 10y ago
    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 10y ago
      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 10y ago
        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.
      - GFK_of_xmaspast 10y ago
        A lot of lisp people get testy when you call lisp a functional language.
- paulddraper 10y ago
  It goes the other way too though. Records, for example.

Chinjut 10y ago

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

mrow84 10y 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_Perrault https://en.wikipedia.org/wiki/Cinderella#Cendrillon.2C_by_Pe...
- yrashk 10y 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 10y 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.

smallnamespace 10y 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 10y 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/ http://www.datomic.com/
- smallnamespace 10y 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?
  - mamcx 10y ago
    Now I trying to use Event Sourcing (mainly for sync) for a "normal" invoice app, I find several problems. The thing is that the event log is good for write but awful for read. Re-compute everything is problematic and the true is 90% of the time you want the last version, not all the history. Also, the split in logic from the app / engine is stupid. I think is good if we move past the idea that the DB engine is more dumb than a rock, and embrace it. But current tools are not ideal (sadly, I know what is live like this: I have used Visual FoxPro!) Where I think this could lead to something great is if the DB is alike this: - Relational - You have normal tables. Consider them your up-to-date cache. Most scenarios will be covered here (ie: The log recomputing is NOT at the app level, but at the DB level). - You have a event log where everything is stored, plus your "tables" for the info you need up-to-date. But you don't need all to be a table if not make sense, and do full re-computation if desired. - Your backup, sync and load history is around the event log. - You don't even need a "table" if you wanna only a "index", this lead to me: - You submit a data request (like a POST), and the DB convert it to the tables and log, but: - You can instead (or also!) hook here and build secondary indexes and do other stuff. You can do it async, put the computation in a queue, do validations, etc as fit. So, what is not here and need tooling is marry the "normal tables" + "event log" + "logic that route this", so putting: Data -> WAL -> Router -> Event Log | Tables | Index | ping external tools And Request Data -> Router -> Get it from:Event Log | Tables | Index | ping external tools

deleted 10y ago

[deleted]

michaelklein 10y 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 10y 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?

djfm 10y 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?
- yrashk 10y ago
  My research into this topic has led me to lazy event sourcing so far https://blog.eventsourcing.com/lazy-event-sourcing-ed7e59007e17#.v3yqh7ukh 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.
  - djfm 10y ago
    Yeah, now this is a nice continuation to the conversation :) I too have been mildly obsessed with the kind of thinking you're developing in your post - very nice article! I've been very attracted to event-sourcing since I realized that now that React and redux have mostly solved the UI problem what remains to be solved is the problem of how to store our beautiful event-driven data. EDIT: re-read your comment, felt the need to say that your "current view" is exactly mine too
    - yrashk 10y ago
      I am happy to continue this conversation off-HN, perhaps Gitter? http://gitter.im/eventsourcing/eventsourcing http://gitter.im/eventsourcing/eventsourcing

KirinDave 10y 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.

runT1ME 10y 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.
- deleted 10y ago
  [deleted]
- KirinDave 10y 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.
  - uryga 10y ago
    >> 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.

paulddraper 10y 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-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 10y ago
Appel's classic "SSA is functional programming" offers another interesting way to look at this equivalence.

torkable 10y ago

I just read an entire blog post that simplifies down to "IO is not pure". Can I have my time back?

Ace17 10y ago

From the article: The "Land of purity" lies above the "Dirty sea of data" . Wouldn't "Dirty sea of state" be more appropriate?

yrashk 10y ago
Perhaps!