5 ms·

Ideally, a good compiler that understands FP will, behind the scenes, detect when it's safe to mutate the old data rather than creating a copy. That's a big par

Ideally, a good compiler that understands FP will, behind the scenes, detect when it's safe to mutate the old data rather than creating a copy. That's a big part of why Haskell manages to be neck-and-neck with C despite being functionally pure. Where it gets tricky is in an environment like the JVM where programming in that style was not anticipated, and introducing any optimizations along these lines for the benefit of the proverbial Scala fans needs to be balanced against the obligation not to adversely impact idiomatic Java code. That said, even without that, it's not necessarily crazy. It's just a value call: Do you believe that more functional code is easier to maintain, and perhaps value that above raw performance? I'm old enough to remember similar debates about how object-oriented C++ code should be, and to have at least encountered Usenet posts from similar debates about how structured C code should be. I don't bring this up by way of trying to weasel in some "historical inevitability" argument - these are legitimate debates, and there are still problem domains where coding guidelines may discourage, or even prohibit, certain structured programming practices. For very good reasons.

nonsense1234 6y ago
Haskell is only close to C in extremely rare cases or when using unsafe features and the FFI.
- the_af 6y ago
  Would you say idiomatic Haskell is faster or slower than idiomatic use of Java and the JVM? I'm interested in actual experience and preferably benchmarks of real cases, no thought experiments please :) (If this sounds harsh, it's not my intention. In another HN thread I had someone "explain" to me how Java and Java's OOP is "not suitable for business software development". If this seems like a bizarre statement which disregards more than a decade of business software development -- this is why I ask for actual experience and not opinions or "I think this can't be right").
  - wtetzner 6y ago
    “Unsuitable” doesn’t mean it can’t be done. Having written a lot of business software in Java, I actually agree it’s unsuitable. The only way I’ve been able to make it bearable is by using Lombok and pcollections.
    - the_af 6y ago
      > I actually agree it’s unsuitable How so? Performance? Reliability? Verbosity? Which language is suitable in your opinion? To me this kind of opinion-based... um, opinions... fly in the face of evidence. Java has been used for more than a decade to deploy business software to great success. What more evidence does one need? It'd be like arguing "COBOL is unsuitable for banking". In the meantime, opinions have shifted on best engineering practices, and Java has naturally run the gamut of all these opinions. And because there are tons of Java systems, there's no shortage of examples of failed/bad projects one could pick on. I wonder how many languages/platforms would have fared better...
      - wtetzner 6y ago
        "Unsuitable" meaning it's not a great choice. Yes, it's been done a lot (whether or not you can really say "to great success" is another matter, I think). What I mean is that I think using Java meant the company was required to spend more resources than should have been necessary to accomplish their goal. BTW, when I say "Java", I mean the language, not the platform. Java-the-platform is very suitable to business software. Java-the-language, less so. Java OOP brings with it a ridiculous amount of incidental complexity, boilerplate, and impedance mismatches. Of course you can make it work, I do it every day. I just think it's a poor choice. It's certainly not the worst choice, and the platform + available libraries is definitely a plus. And as I mentioned in my original post, there are way to make it more suitable through various hacks (like Lombok) and libraries, but other languages are more suitable out of the box (including other JVM languages).
    - mrkeen 6y ago
      If you liked pcollections, you might also like https://www.vavr.io/ https://www.vavr.io/
chrisseaton 6y ago
> That's a big part of why Haskell manages to be neck-and-neck with C despite being functionally pure. Come on... that's not what you typically get with Haskell, is it.
- nicoburns 6y ago
  Rust gives you FP-style without loads of copies and C-like performance. Immutable data-structures aren't idiomatic, but it's ownership gives you most of the same benefits.
  - entha_saava 6y ago
    And many string types, like Haskell /s
  - zozbot234 6y ago
    The nice thing about Rust is that it gives you the main benefits of FP even when you're not programming in "FP style". The Rust "sharing xor mutability" default model provides underlying semantics and ease of analysis that's quite comparable to what you get with a pure-functional language. Of course extended mutability as with Cell<>, RefCell<> etc. undermines this, but these are only used when necessary.
entha_saava 6y ago
> Ideally, a good compiler that understands FP will, behind the scenes, detect when it's safe to mutate the old data rather than creating a copy. That's a big part of why Haskell manages to be neck-and-neck with C despite being functionally pure. Not talking against Haskell or FP; The disadvantage is being hard to reason about performance. Ensuring compiler will optimize something will take more cognitive load than simply writing straightforward code. Imagine having a map() method on an array that produces another array. In a long chained pipeline of such things, compiler may be able to elide extra allocations and generate asm very near to handwritten for loops. But the abstraction breaks when the method does I/O or has side effects - you can't reorder anything in order to elide allocations. (Well this example may not make sense in Haskell because Haskell is lazily evaluated). However there is a limit to what compiler can do, and it might manifest in edge cases like variation in order of imports. I'd rather have straightforward code than relying on compiler optimizations. I am not arguing "against abstractions" like some Go fanboys tell you map and filter are less efficient. It is always possible to apply same map filter to iterators/lazy streams instead of arrays and get same performance in straightforward code. But that's not same as keeping in mind what heuristics compiler uses to optimize the code.
- hopia 6y ago
  I suppose in FP/Haskell you would structure your code differently, so that it wouldn't have side effects when mapping arrays. That way you could even parallelize it trivially. High level languages produce a lot less code than than less optimized implementations. Difficulties with reasoning about execution/performance is the penalty you potentially have to pay. In my experience it indeed may be hard to understand performance with Haskell. That said, it comes with excellent tooling to overcome it in most of the cases.

nonsense1234 6y ago

Haskell is only close to C in extremely rare cases or when using unsafe features and the FFI.

the_af 6y ago
Would you say idiomatic Haskell is faster or slower than idiomatic use of Java and the JVM? I'm interested in actual experience and preferably benchmarks of real cases, no thought experiments please :) (If this sounds harsh, it's not my intention. In another HN thread I had someone "explain" to me how Java and Java's OOP is "not suitable for business software development". If this seems like a bizarre statement which disregards more than a decade of business software development -- this is why I ask for actual experience and not opinions or "I think this can't be right").
- wtetzner 6y ago
  “Unsuitable” doesn’t mean it can’t be done. Having written a lot of business software in Java, I actually agree it’s unsuitable. The only way I’ve been able to make it bearable is by using Lombok and pcollections.
  - the_af 6y ago
    > I actually agree it’s unsuitable How so? Performance? Reliability? Verbosity? Which language is suitable in your opinion? To me this kind of opinion-based... um, opinions... fly in the face of evidence. Java has been used for more than a decade to deploy business software to great success. What more evidence does one need? It'd be like arguing "COBOL is unsuitable for banking". In the meantime, opinions have shifted on best engineering practices, and Java has naturally run the gamut of all these opinions. And because there are tons of Java systems, there's no shortage of examples of failed/bad projects one could pick on. I wonder how many languages/platforms would have fared better...
    - wtetzner 6y ago
      "Unsuitable" meaning it's not a great choice. Yes, it's been done a lot (whether or not you can really say "to great success" is another matter, I think). What I mean is that I think using Java meant the company was required to spend more resources than should have been necessary to accomplish their goal. BTW, when I say "Java", I mean the language, not the platform. Java-the-platform is very suitable to business software. Java-the-language, less so. Java OOP brings with it a ridiculous amount of incidental complexity, boilerplate, and impedance mismatches. Of course you can make it work, I do it every day. I just think it's a poor choice. It's certainly not the worst choice, and the platform + available libraries is definitely a plus. And as I mentioned in my original post, there are way to make it more suitable through various hacks (like Lombok) and libraries, but other languages are more suitable out of the box (including other JVM languages).
  - mrkeen 6y ago
    If you liked pcollections, you might also like https://www.vavr.io/ https://www.vavr.io/

chrisseaton 6y ago

> That's a big part of why Haskell manages to be neck-and-neck with C despite being functionally pure. Come on... that's not what you typically get with Haskell, is it.

nicoburns 6y ago
Rust gives you FP-style without loads of copies and C-like performance. Immutable data-structures aren't idiomatic, but it's ownership gives you most of the same benefits.
- entha_saava 6y ago
  And many string types, like Haskell /s
- zozbot234 6y ago
  The nice thing about Rust is that it gives you the main benefits of FP even when you're not programming in "FP style". The Rust "sharing xor mutability" default model provides underlying semantics and ease of analysis that's quite comparable to what you get with a pure-functional language. Of course extended mutability as with Cell<>, RefCell<> etc. undermines this, but these are only used when necessary.

entha_saava 6y ago

> Ideally, a good compiler that understands FP will, behind the scenes, detect when it's safe to mutate the old data rather than creating a copy. That's a big part of why Haskell manages to be neck-and-neck with C despite being functionally pure. Not talking against Haskell or FP; The disadvantage is being hard to reason about performance. Ensuring compiler will optimize something will take more cognitive load than simply writing straightforward code. Imagine having a map() method on an array that produces another array. In a long chained pipeline of such things, compiler may be able to elide extra allocations and generate asm very near to handwritten for loops. But the abstraction breaks when the method does I/O or has side effects - you can't reorder anything in order to elide allocations. (Well this example may not make sense in Haskell because Haskell is lazily evaluated). However there is a limit to what compiler can do, and it might manifest in edge cases like variation in order of imports. I'd rather have straightforward code than relying on compiler optimizations. I am not arguing "against abstractions" like some Go fanboys tell you map and filter are less efficient. It is always possible to apply same map filter to iterators/lazy streams instead of arrays and get same performance in straightforward code. But that's not same as keeping in mind what heuristics compiler uses to optimize the code.

hopia 6y ago
I suppose in FP/Haskell you would structure your code differently, so that it wouldn't have side effects when mapping arrays. That way you could even parallelize it trivially. High level languages produce a lot less code than than less optimized implementations. Difficulties with reasoning about execution/performance is the penalty you potentially have to pay. In my experience it indeed may be hard to understand performance with Haskell. That said, it comes with excellent tooling to overcome it in most of the cases.