Hacker News Reader

Comment by SeanLuke | Hacker News Reader

Wait, since when did functional programming imply immutability? I think fifty years of lisp would like to have a few words with this fellow.

View on HN

Functional programming means working with referential transparency by definition and an expression is said to be referentially transparent if it can be changed with its value without changing the behavior of the program (i.e. you receive the same output for the same input). And that's actually the definition of functions in mathematics that children learn in school - functional programming does not refer to the "functions" that we know from regular imperative programming ;-)

This implies immutability, because pieces of code, or functions that mutate variables / objects / data-structures are NOT referentially transparent.

> I think fifty years of lisp would like to have a few words with this fellow

LISP is not really a family of FP programming languages, even though LISP in general does apply concepts from lambda calculus and does have everything needed for FP. LISP in general is more like a multipurpose swiss army knife. For example the style people use to develop in Common Lisp is often very far away from FP. There are exceptions of course, like Clojure, which comes with immutable data-structures by default, strived to make uncontrolled mutation more painful and the culture around it does encourage FP.

Functional Programming is so poorly defined.. It clearly means whatever the op appears to think it means for the context of the current discussion.

Don't all scalable modern functional languages depend on immutability? So they can move function execution to different processes/virtual machines freely. Or something.

Most modern functional languages encourage immutability to a greater or lesser extent, but allow or even encourage workarounds. I don't think they depend on immutability but it's a bigger deal than it is in some other paradigms.

Most modern FP languages (and quite a few non-FP languages these days as well) do immutable by default, with carefully controlled explicit mutability where necessary. It's basically the flip of older traditional languages where unless specifically stated otherwise everything was mutable. Doing immutable by default encourages you to use mutability only where you really need it. Immutable references allow all kinds of desirable compiler optimizations to be implemented which leads to better performing code with fewer bugs, but it doesn't need to be an all or nothing, you can have both mutable and immutable references in the same code, it just means the mutable parts don't benefit from the same optimizations the immutable parts do.

Reply on news.ycombinator.com