3 ms·

One of the things Dr. Parsons mentions here is how functional programming makes it easier to reason about programming because of the lack of side-effects. That

by pohl 15y ago

One of the things Dr. Parsons mentions here is how functional programming makes it easier to reason about programming because of the lack of side-effects. That makes sense to me, and I heard it frequently whenever someone is giving the FP sales pitch. I wonder, though, whether there is a tradeoff that is going unmentioned, and I suspect that it is that it makes it more difficult to reason about costs. I feel trapped when I'm writing in a language like Java, but at least the cost model is obvious to me. Am I off base here? Is there some way to develop a similar intuition about costs in an FP language?

soc88 15y ago
I think the best way is to have a good taste when choosing how to solve the problem. Going purely functional (Haskell) has its own benefits but also a lot of drawbacks. If you don't go purely functional, it doesn't make sense to avoid imperative or OO features where they make sense. In that sense, I think languages which fuse and unify functional and OO approaches are a good strategy. There is a bit of negativity towards them, because they manage to piss off both OO evangelists as well as functional preachers, but that doesn't detract from the technical benefits of such an approach.
spacemanaki 15y ago
Most of my functional programming experience is with Clojure, and it's not very deep experience, so take this with a grain of salt. However I think reasoning about performance in Clojure isn't tremendously different than reasoning about performance in Java, and in some cases it might even be easier. Yes, it's true that you might have to learn some new idioms, like passing accumulators to tail recursive calls. But once you start structuring programs primarily as a collection of pure functions that operate on data structures like vectors and maps, I think profiling those functions is easier much in the same way that testing them can be easier. Obviously, depending on the language, you might have to develop new mental models for how to use certain features performantly (like lazy seqs and persistent collections in Clojure), but that's mostly true of any new language or even a new library.
tobiasu 15y ago
Computer use has shifted from calculating tables for ballistic missiles to manipulating gigantic amounts of state. And (pure) FP is the answer because it doesn't have the ability to manipulate state?
- Peaker 15y ago
  On the contrary, pure FP excels at manipulating state. The name "pure FP" is a bit of a misnomer, because what people really mean by it is that instead of "side effects" we have "typed effects". The effects always appear in the types of our computations, so they're not really "side" effects anymore, they're a central part of the computation.
skew 15y ago
The cost model can be very simple. Take the cost model of Java and apply it to programs where all fields are final. Maybe costs are higher than you'd like, but it's simple to understand. Lazy evaluation seriously complicates the cost model, but few languages are lazy.
reycharles 15y ago
You should read the introduction to Chris Okasaki's "Purely Functional Data Structures". It says there may be higher lower bounds for some problems in functional programming languages, although it's often possible to come up with something that is as fast. I interpret that as it can require a lot of ingenuity to come up with efficient data structures in functional programming languages. It's not harder to reason about time complexity with strict evaluation. I think it's a bit harder with lazy evaluation, though. Okasaki uses both strict and lazy evaluation to achieve fast data structures.
- pohl 14y ago
  A copy of Okasaki's book arrived last night. This is exactly what I needed. Thank you again.
- pohl 15y ago
  Thank you for the pointer! I grabbed this pdf, and (by random chance) my eyes fell upon this somewhat-related gem (on page 129): "Ironically, pattern matching — one of the most popular features in functional programming languages — is also one of the biggest obstacles to the widespread use of efficient functional data structures. The problem is that pattern matching can only be performed on data structures whose representation is known, yet the basic software-engineering principle of abstraction tells us that the representation of non-trivial data structures should be hidden. The seductive allure of pattern matching leads many functional programmers to abandon sophisticated data structures in favor of simple, known representations such as lists, even when doing so causes an otherwise linear algorithm to explode to quadratic or even exponential time." http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf

by pohl 15y ago

soc88 15y ago

I think the best way is to have a good taste when choosing how to solve the problem. Going purely functional (Haskell) has its own benefits but also a lot of drawbacks. If you don't go purely functional, it doesn't make sense to avoid imperative or OO features where they make sense. In that sense, I think languages which fuse and unify functional and OO approaches are a good strategy. There is a bit of negativity towards them, because they manage to piss off both OO evangelists as well as functional preachers, but that doesn't detract from the technical benefits of such an approach.

spacemanaki 15y ago

Most of my functional programming experience is with Clojure, and it's not very deep experience, so take this with a grain of salt. However I think reasoning about performance in Clojure isn't tremendously different than reasoning about performance in Java, and in some cases it might even be easier. Yes, it's true that you might have to learn some new idioms, like passing accumulators to tail recursive calls. But once you start structuring programs primarily as a collection of pure functions that operate on data structures like vectors and maps, I think profiling those functions is easier much in the same way that testing them can be easier. Obviously, depending on the language, you might have to develop new mental models for how to use certain features performantly (like lazy seqs and persistent collections in Clojure), but that's mostly true of any new language or even a new library.

tobiasu 15y ago

Computer use has shifted from calculating tables for ballistic missiles to manipulating gigantic amounts of state. And (pure) FP is the answer because it doesn't have the ability to manipulate state?

Peaker 15y ago
On the contrary, pure FP excels at manipulating state. The name "pure FP" is a bit of a misnomer, because what people really mean by it is that instead of "side effects" we have "typed effects". The effects always appear in the types of our computations, so they're not really "side" effects anymore, they're a central part of the computation.

skew 15y ago

The cost model can be very simple. Take the cost model of Java and apply it to programs where all fields are final. Maybe costs are higher than you'd like, but it's simple to understand. Lazy evaluation seriously complicates the cost model, but few languages are lazy.

reycharles 15y ago

You should read the introduction to Chris Okasaki's "Purely Functional Data Structures". It says there may be higher lower bounds for some problems in functional programming languages, although it's often possible to come up with something that is as fast. I interpret that as it can require a lot of ingenuity to come up with efficient data structures in functional programming languages. It's not harder to reason about time complexity with strict evaluation. I think it's a bit harder with lazy evaluation, though. Okasaki uses both strict and lazy evaluation to achieve fast data structures.

pohl 14y ago
A copy of Okasaki's book arrived last night. This is exactly what I needed. Thank you again.
pohl 15y ago
Thank you for the pointer! I grabbed this pdf, and (by random chance) my eyes fell upon this somewhat-related gem (on page 129): "Ironically, pattern matching — one of the most popular features in functional programming languages — is also one of the biggest obstacles to the widespread use of efficient functional data structures. The problem is that pattern matching can only be performed on data structures whose representation is known, yet the basic software-engineering principle of abstraction tells us that the representation of non-trivial data structures should be hidden. The seductive allure of pattern matching leads many functional programmers to abandon sophisticated data structures in favor of simple, known representations such as lists, even when doing so causes an otherwise linear algorithm to explode to quadratic or even exponential time." http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf