Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Research What Puzzles You Most About Functional Programming?

What Puzzles You Most About Functional Programming?


InfoQ's research widget has been deprecated and is no longer available.

UPDATE - 16 Oct 2013: We had to reset this research item, and contact participants to submit their votes again, due to "two conflicting labels on the x-axis" as a user mentioned in the comments.

Functional programming is a hot topic in many programming language communities. Java 8 will add lambdas, or anonymous functions, in its next release. Also on the JVM, Scala has attracted a lot of attention. Microsoft’s C# has had lambda expressions for many years now, and they even added a separate functional programming language – F# – to their .NET platform. And not to forget, C++ has added lambda expressions to its 2011 standard.

With so much diversity, it’s hard to define the exact scope of what exactly functional programming is. Is it a question of how to design your program, that is, using functions as the primary abstraction? Or is it about programming with mathematical functions, meaning pure functions that do not have side effects? And what are those monads again? 

In this InfoQ research, we ask you: what puzzles you most about functional programming? The following is an incomprehensive list of things that might puzzle you about functional programming. 

  • How to work with immutable data structures: How do immutable data structures, like Clojure's persistent data structures, work. How expensive are they in terms of memory usage (GC memory pressure, overhead) or algorithmically (indexed access for vectors, etc).
  • Is referential transparency ("purity") useful? Referential transparency means that a function call can be replaced with its result without changing the program’s behaviour. This implies that functions can’t have side effects and behave more like mathematical functions. This is sometimes also called purity.
  • How do functional languages handle program state? If we program with pure functions and immutable data structures, can our programs actually do something useful?
  • What are functional patterns like monads, applicatives?
  • What are these different types of functions and where do I use them: anonymous, lambda, higher-order, closure. An anonymous function, sometimes also called lambda, is a function that is not necessarily bound to a name. Higher-order describes functions that have take other functions as parameters or return a function. Closures are those functions that capture some of their surrounding program state.
  • Is strong static typing necessary?
  • Do I have to replace all my for-loops with map/filter/fold functions?
  • How do functional languages help control side-effects?
  • Where can the map-filter-reduce style of programming be applied?
  • Isn’t pattern matching just an instanceof check in disguise?
  • Are there benefits to separating data and behaviour? Object-oriented programming conflates data and the operations/methods on them. Functional programming tends to separate these two.
  • Where is lazy evaluation useful? Lazy evaluation means delaying the evalution of parts of the program for as long as possible. Ideally, this avoids evalutions that are never needed, for example, a function argument that is not used.
  • Can we better reason about programs when they’re functional?
  • Does type inference make programming easier? Type inference means that we can omit types when writing code and the compiler infers them from the exising code. Most programming languages already have type inference to a varying degree, for example, C++’s auto or C#’s var.
  • Are recursive functions really the only way to write code in functional languages?
  • Are continuations essential or just a fancy gimmick?