6 ms·

Purely functional algorithms and data structures are typically slower. Imperative code is also more concise than equivalent functional code. The only real bene

• willtim 7y ago
  > Purely functional algorithms and data structures are typically slower. Functional persistent data structures bring many advantages, even to imperative programmers. For example, if your text editor used a persistent data structure, it probably wouldn't need to lock you out during a save and would support better undo. Mutation is efficient, but comes with many drawbacks, especially when state is shared or provenance is required. This is why functional data structures and ideas are appearing outside of functional programming, for example ZFS, git, Blockchain, Spark, Kafka etc etc > Imperative code is also more concise than equivalent functional code. This couldn't be further from the truth. Just as Fortran liberated arithmetic expressions from the verbosity of imperative programming, FP allows us to move beyond non-compositional word-at-time sequences of mutation commands and build much higher-level abstractions. Modern imperative languages have borrowed many ideas from FP, but are still no way near as expressive as e.g. Haskell. Of course, imperative programming is still very useful and that's why Haskell has good support for it.
  • h91wka 7y ago
    > This couldn't be further from the truth. In imperative languages you don't need Edward Kmett to invent lenses for you.
    • willtim 7y ago
      Lenses are not necessary to practice FP, just sometimes useful (and Edward didn't invent them). Try updating a deeply nested record in your favourite imperative language without mutating the original (!)
• rebeccaskinner 7y ago
  I find this to be largely untrue. There are certainly classes of algorithms and data structures that benefit from mutation for performance reasons, but at that point you can simply implement mutation in your pure functional language (e.g. with monads). Even ignoring that case, there are a great many data structures and algorithms that don’t meaningfully suffer from a lack of mutation at all, especially when the compiler is able to leverage assumptions from being in a pure language. This is born out in practice where Haskell for example may not necessarily out perform highly optimized C, but it is frequently able to keep pace with Java and will almost always beat imperative python code. In terms of being concise it’s laughable to me to even make the comparison. I’ve written a lot of C, Python and Ruby in my career in addition to Haskell, and Haskell wins on expensiveness to such an absurd degree that the comparison feels unfair. The one area that I think FP, although really Haskell in particular, suffers is being to reason about. Performance and memory usage of course are notoriously hard to reason about in lazy languages, but it can also be challenging to understand what’s happening in large code bases that may have some deep MTL stack or be using multiple interpreters over some free monad, since the semantics of how computations are being evaluated can often be defined very far from the computation itself.
  • deleted 7y ago
    [deleted]
  • thsealienbstrds 7y ago
    When it comes to Haskell, I want to add that especially when you start doing parallel programming, it becomes even harder to reason about. You might expect that doing that extra data type conversion in parallel rather than in sequence is going to make things faster, but you could find that the GC needs to do more work for whatever reason, and it ends up actually becoming slower. It's very counter-intuitive. It's a shame because writing parallel code in Haskell can be very elegant. If only the behavior was more obvious it would be so great.
• BoiledCabbage 7y ago
  > Imperative code is also more concise than equivalent functional code Functional code is almost always more concise than the equivalent imperative code. It's one of the main reasons why people prefer functional code. Almost everyone who looks at it pretty much agrees. The only cases where it will not be is if someone is directly re-writing an imperative algorithm into a functional language, then the functional can be longer. But for the most part, that's translating < 50 lines of code or something. Anything of substance functional is more concise. If you haven't seen that to be the case, then you may not have looked at any substantial functional code. Regardless of whether people prefer functional or not, that's almost a universal take-away from anyone re-writing an imperative project into a functional language. It's usually a factor of 2 or 3 shorter and simpler.
  • hota_mazi 7y ago
    First of all, please stop making sweeping generalizations, "people prefer", "almost everyone", etc... Without proper citations, these claims are meaningless. Second, more concise doesn't always mean better, let alone more readable or more maintainable. It's often the opposite. Third, functional programming is usually preferred because of aspects such as composition or immutability, not conciseness. Fourth, rewrites of an existing code base usually leads to shorter code bases, simply because of the acquired knowledge, regardless of the language or the techniques.
• robcohen 7y ago
  You are correct, that purely functional data structures are slower, but the differences is not as meaningful as you might actually think. Haskell is actually pretty fast, and I'd say for the vast majority of applications, Haskell is just fine performance-wise. See a few examples here: https://two-wrongs.com/on-competing-with-c-using-haskell https://two-wrongs.com/on-competing-with-c-using-haskell
• jolux 7y ago
  >Imperative code is also more concise than equivalent functional code. Okay, I'm really hoping there's a good surprise behind this, because I've been an imperative programmer for 10 years and a functional programmer for 5 and I have only rarely seen imperative code that was more concise than equivalent functional code. Faster? Sure. More efficient? I'll buy it. Perhaps even easier to read, especially when you get into point-free style on the functional side. But more concise overall? I find that hard to believe, but I'm genuinely excited now! The ultimate trump here would be APL but that's admittedly an eccentric case.
  • h91wka 7y ago
    In imperative languages you don't need Edward Kmett to invent lenses for you.
    • sullyj3 7y ago
      But, this is a problem specific to Haskell and its poor record syntax, not the functional paradigm in general.
    • tome 7y ago
      Firstly, that's a non-sequitur, but secondly, in an imperative language with immutable data structures, yes, you do.
    • jolux 7y ago
      I...sure? But you could get a lot of help from Phil Wadler and Simon Peyton-Jones!