5 ms·

>I don't get point of functional programming. Machines don't work that way. FP is useful because it provides an abstracted model that is pretty easy to reason

by growse 7y ago

>I don't get point of functional programming. Machines don't work that way. FP is useful because it provides an abstracted model that is pretty easy to reason about. It doesn't matter how it gets implemented, that's the point of the abstraction. We don't write programs for machines to understand. We write programs for humans to understand.

sorokod 7y ago
That works if an abstraction doesn't leak. Since we are not quite there yet, could you explain in broad terms how a large collection is sorted while maintaining performance and immutability.
- throwaway17_17 7y ago
  The simplest way, but which essentially dodged the question, is to utilize a language with uniqueness types. Where the data structure may only exist in a single place and there can be no aliasing. Then any operation on the data structure occurs and can be done ‘in place’ returning the new unique data structure. This is similar (but not identical) to linear and affine type systems, of which Idris is the only language I know of that actually implements such a type system. Also, along the same lines, it is certainly possible to craft types in some FP languages which allow for this same logic to be captured, mostly via some monad construct.
  - steveklabnik 7y ago
    Rust has an affine type system, and https://docs.rs/im/14.3.0/im/ https://docs.rs/im/14.3.0/im/ implements this https://docs.rs/im/14.3.0/im/#in-place-mutation https://docs.rs/im/14.3.0/im/#in-place-mutation
    - throwaway17_17 7y ago
      This reply is late, so if you don’t see it or care I don’t blame you. To start, I am aware of Rust and left it out of the above comment purposefully. While Rust does indeed make many ‘functional programming’ idioms available and, some would say, is basically an impure, eager functional language, I don’t tend to view Rust as a language featuring persistent, immutable data structures. I certainly don’t think that is a negative characterization, just how I see things. I find that one of the defining features of the functional programming ‘persistent’ data structure is the structural sharing that is all too frequent in most of the mainline FP languages (Haskell, ML, Clojure, etc.). Rudy’s focus on low level/systems level programming is much more likely to use standard imperative data structures without the sharing and deep pointer chasing style seemingly inherent in FP implementations. I have had a few spirited web-discussions with people about the claim that Rust has an affine type system. I don’t think that stance is accurate, from a type theoretic stance. I subscribe to the theoretical standpoint that Rust has a standard non-substructural type systems with constraints placed on types that meet a mutability predicate. I think that those constraints are better described as a uniqueness constraint per instance of a type. But the sequent calculus presentations for Rust (especially concerning mutable data) would look very similar and act very similar as well. So really it’s much ado about nothing, just fun to talk about. Sorry for the wall of text, and rambling about type theory. Stay safe.
- growse 7y ago
  > That works if an abstraction doesn't leak. It seems like you're saying that abstractions are worthless unless they're perfect, which is obviously not true. > Since we are not quite there yet, could you explain in broad terms how a large collection is sorted while maintaining performance and immutability. What do you mean by "maintaining performance"? Relative to what? Who's asking for the sorted collection? How are they going to access it? What are the resource constraints? Give me a real-world example. Don't get me wrong, I'm not saying that FP is the answer to everything. It's a useful tool, and part of being good at software development is knowing what tools to use and when.
  - sorokod 7y ago
    No need for a real-world example or an exact definition of performance or efficiency, just make up something sensible. How can efficient sorting be implemented with immutable data structures? Genuinly curious.
- Athas 7y ago
  Here is a worked example of how to implement radix sort using only immutable data-parallel operations: https://futhark-lang.org/examples/radix-sort.html https://futhark-lang.org/examples/radix-sort.html There will of course be "impure" writes at the machine level, but at the language level, the abstraction doesn't leak.
dirtydroog 7y ago
> We don't write programs for machines to understand. We write programs for humans to understand. True, but that program ends up executing on a machine. You normally want that program to execute as efficiently as possible. 'Efficiency' can be measured several ways... time to complete, resources required, financial cost. A case in point is our company switched from using Cassandra (JVM based) to ScyllaDB (a C++ clone of Cassandra). Query latencies were the same if not faster, and we needed fewer nodes to handle the same load. All because the language used has some mechanical sympathy for the CPU it's going to run on, and no GC. I see Scala is somewhat the defacto language used for 'big data' stuff. I have no idea why. I reckon if some bean counter translated that choice into $$$ things would change.
- growse 7y ago
  > True, but that program ends up executing on a machine. You normally want that program to execute as efficiently as possible. 'Efficiency' can be measured several ways... time to complete, resources required, financial cost. No, you normally want that program to execute efficiently enough to do its required job. Abstractions are often necessarily costly, but that's ok because their value is greater than their cost. Otherwise, you'd just throw all the abstractions away and use assembler. > Query latencies were the same if not faster, and we needed fewer nodes to handle the same load. All because the language used has some mechanical sympathy for the CPU it's going to run on. It seems like there's a whole load of reasons why it might have been more efficient on ScyllaDB that are unrelated to what language it was written in. Maybe the software design fit your requirements better? Maybe it was just better implemented? Maybe it was easier to configure for your load? Etc. etc. Programs aren't magically "more efficient" because they're written in C.
  - jcelerier 7y ago
    > No, you normally want that program to execute efficiently enough to do its required job but... the "required job" is to go as fast as possible - in two ways : 1/ You must go faster than your competitors. Else people will switch, your software will get bad reviews, etc. 2/ you must go fast enough for anything that people will throw at you. And, in many cases, people can throw arbitrarily large problems to your program, and telling them "sorry but it will take 1 hour to process your 2TB dataset" just won't cut it at all. And even when you manage to cut it, then people come at you like "now can this run on a raspberry pi?" Take for instance image processing software, audio or multimedia software... they will never be fast enough, and there is always an use case where getting a 1% perf improvement will allow a project to make instead of break (especially when working with uncompromising artists).

by growse 7y ago

sorokod 7y ago

That works if an abstraction doesn't leak. Since we are not quite there yet, could you explain in broad terms how a large collection is sorted while maintaining performance and immutability.

throwaway17_17 7y ago
The simplest way, but which essentially dodged the question, is to utilize a language with uniqueness types. Where the data structure may only exist in a single place and there can be no aliasing. Then any operation on the data structure occurs and can be done ‘in place’ returning the new unique data structure. This is similar (but not identical) to linear and affine type systems, of which Idris is the only language I know of that actually implements such a type system. Also, along the same lines, it is certainly possible to craft types in some FP languages which allow for this same logic to be captured, mostly via some monad construct.
- steveklabnik 7y ago
  Rust has an affine type system, and https://docs.rs/im/14.3.0/im/ https://docs.rs/im/14.3.0/im/ implements this https://docs.rs/im/14.3.0/im/#in-place-mutation https://docs.rs/im/14.3.0/im/#in-place-mutation
  - throwaway17_17 7y ago
    This reply is late, so if you don’t see it or care I don’t blame you. To start, I am aware of Rust and left it out of the above comment purposefully. While Rust does indeed make many ‘functional programming’ idioms available and, some would say, is basically an impure, eager functional language, I don’t tend to view Rust as a language featuring persistent, immutable data structures. I certainly don’t think that is a negative characterization, just how I see things. I find that one of the defining features of the functional programming ‘persistent’ data structure is the structural sharing that is all too frequent in most of the mainline FP languages (Haskell, ML, Clojure, etc.). Rudy’s focus on low level/systems level programming is much more likely to use standard imperative data structures without the sharing and deep pointer chasing style seemingly inherent in FP implementations. I have had a few spirited web-discussions with people about the claim that Rust has an affine type system. I don’t think that stance is accurate, from a type theoretic stance. I subscribe to the theoretical standpoint that Rust has a standard non-substructural type systems with constraints placed on types that meet a mutability predicate. I think that those constraints are better described as a uniqueness constraint per instance of a type. But the sequent calculus presentations for Rust (especially concerning mutable data) would look very similar and act very similar as well. So really it’s much ado about nothing, just fun to talk about. Sorry for the wall of text, and rambling about type theory. Stay safe.
growse 7y ago
> That works if an abstraction doesn't leak. It seems like you're saying that abstractions are worthless unless they're perfect, which is obviously not true. > Since we are not quite there yet, could you explain in broad terms how a large collection is sorted while maintaining performance and immutability. What do you mean by "maintaining performance"? Relative to what? Who's asking for the sorted collection? How are they going to access it? What are the resource constraints? Give me a real-world example. Don't get me wrong, I'm not saying that FP is the answer to everything. It's a useful tool, and part of being good at software development is knowing what tools to use and when.
- sorokod 7y ago
  No need for a real-world example or an exact definition of performance or efficiency, just make up something sensible. How can efficient sorting be implemented with immutable data structures? Genuinly curious.
Athas 7y ago
Here is a worked example of how to implement radix sort using only immutable data-parallel operations: https://futhark-lang.org/examples/radix-sort.html https://futhark-lang.org/examples/radix-sort.html There will of course be "impure" writes at the machine level, but at the language level, the abstraction doesn't leak.

dirtydroog 7y ago

> We don't write programs for machines to understand. We write programs for humans to understand. True, but that program ends up executing on a machine. You normally want that program to execute as efficiently as possible. 'Efficiency' can be measured several ways... time to complete, resources required, financial cost. A case in point is our company switched from using Cassandra (JVM based) to ScyllaDB (a C++ clone of Cassandra). Query latencies were the same if not faster, and we needed fewer nodes to handle the same load. All because the language used has some mechanical sympathy for the CPU it's going to run on, and no GC. I see Scala is somewhat the defacto language used for 'big data' stuff. I have no idea why. I reckon if some bean counter translated that choice into $$$ things would change.

growse 7y ago
> True, but that program ends up executing on a machine. You normally want that program to execute as efficiently as possible. 'Efficiency' can be measured several ways... time to complete, resources required, financial cost. No, you normally want that program to execute efficiently enough to do its required job. Abstractions are often necessarily costly, but that's ok because their value is greater than their cost. Otherwise, you'd just throw all the abstractions away and use assembler. > Query latencies were the same if not faster, and we needed fewer nodes to handle the same load. All because the language used has some mechanical sympathy for the CPU it's going to run on. It seems like there's a whole load of reasons why it might have been more efficient on ScyllaDB that are unrelated to what language it was written in. Maybe the software design fit your requirements better? Maybe it was just better implemented? Maybe it was easier to configure for your load? Etc. etc. Programs aren't magically "more efficient" because they're written in C.
- jcelerier 7y ago
  > No, you normally want that program to execute efficiently enough to do its required job but... the "required job" is to go as fast as possible - in two ways : 1/ You must go faster than your competitors. Else people will switch, your software will get bad reviews, etc. 2/ you must go fast enough for anything that people will throw at you. And, in many cases, people can throw arbitrarily large problems to your program, and telling them "sorry but it will take 1 hour to process your 2TB dataset" just won't cut it at all. And even when you manage to cut it, then people come at you like "now can this run on a raspberry pi?" Take for instance image processing software, audio or multimedia software... they will never be fast enough, and there is always an use case where getting a 1% perf improvement will allow a project to make instead of break (especially when working with uncompromising artists).