1

I have been reading up on functional programming and I have two questions that I was hoping someone could help me with.

  1. I've read that lazy functional programs can be inefficient if you are accessing the same data often because of the extra overhead of checking whether the expression has been evaluated. I have also read in the first answer of the following thread (Are functional programming languages suitable for graphics programming?), that functional programming can be resource demanding in the context of graphical programming because it creates a lot of temporary objects (I assume this has to do with having to create new objects to simulate state?).

Are there any other areas where functional programming might end up being resource heavy / inefficient in compairison to OOP/procedural programming?

  1. I have read in the first answer in the following thread (Pitfalls/Disadvantages of Functional Programming), that "it is very difficult to predict the time and space costs of evaluating a lazy functional program". Could someone give a simple (if that exists) explaination of why this is the case? I assume it has to do with lazy evaluation only evaluation expressions when needed, but why is it not simple to predict kind of a worst case scenario that is similar to imperative programming where everything is evaluated?
Community
  • 1
  • 1

1 Answers1

1

I've read that lazy functional programs can be inefficient if you are accessing the same data often because of the extra overhead of checking whether the expression has been evaluated.

This involves checking a tag bit on a pointer. It is cheap.

functional programming can be resource demanding in the context of graphical programming because it creates a lot of temporary objects

This depends on the implementation. Allocation in pure FP languages is cheap, as immutability means you can avoid some write barriers. Object allocation is roughly similar to OO languages, though some GCs, such as GHCs, are very efficient compared to e.g. Java.

Are there any other areas where functional programming might end up being resource heavy / inefficient in compairison to OOP/procedural programming?

There are plenty of problems that require very tight resource usage. E.g. operating systems. In such environments you need libraries for direct access to hardware and the ability to mutate memory in place. Depending on the functional language implementation you're using, you may or may not have this.

it is very difficult to predict the time and space costs of evaluating a lazy functional program

It is harder to model lazy evaluation costs because the amount of work done, and when it is done, depends on the input data, which is only available at runtime.

Practically, languages let you choose whether you want to use strict or lazy evaluation, as neither are appropriate for all situations.

Don Stewart
  • 137,316
  • 36
  • 365
  • 468
  • Is checking the tag bit (first point) done through a branch? How is this cheap? – is7s Oct 11 '14 at 21:17
  • Checking a bit pattern in the pointer you already have in a register and branching is cheaper than a memory fetch and making the same branch. The point of pattern matching is to do branches... – Don Stewart Oct 12 '14 at 11:49