A Brief Collection of Convenient Lies about Functional Programming 11
- A value is the instantaneous state of an object. – In OO languages, we have objects. In FP languages, we throw out the object and instead manipulate the values it would take on over time.
- Algebraic data types are classes. – Every case in an ADT is a state that an “object” can be in.
data Tree = Empty | Leaf Int | Node Tree Tree - The functions which we define over an ADT can be considered its public interface. – There’s a school of thought which says that encapsulation doesn’t matter in an functional programming language because values are immutable and corruption can’t happen. Nothing could be further from the truth. If we add or remove a case from an ADT all of the functions which pattern match against it are impacted. While we don’t need to have an encapsulation boundary as tight as we might have in an OO language – it pays to be conscious of how far ADTs travel in a program. Encapsulation is the act of forming a boundary by transforming an ADT into some other form of data.
Each of these statements is a lie, an artful simplification, but they are a convenient and not entirely false way of thinking about functional programming until it becomes second-nature.
Wow, I’m obviously a Novice at functional programming because almost none of this made sense. Where does a Novice go to get the information for this to make sense?
You can add to that the lie that a pattern matcher is a more powerful switch statement :)
Sorry, but where did you get this stuff? I’ve read tons of functional programming papers, texts, and I don’t think I’ve ever read something like “(...) encapsulation doesn’t matter in an functional programming language because values are immutable and corruption can’t happen.”
niv: It’s really just something I’ve heard in conversation. There’s this notion that we don’t really need to be concerned about the fact that the structures we match upon are not encapsulated. I don’t think I’ve run across a book which discusses the extent of an algebraic data type either except to point out that it can be restricted to a module. That seems a bit too narrow for much of the code I’ve seen.
For an algebraic type, the public interface is the algebra itself.
Functions that use algebraic types are dependent on the public interface of the type.
I don’t think I’ve run across a book which discusses the extent of an algebraic data type either except to point out that it can be restricted to a module. That seems a bit too narrow for much of the code I’ve seen.
yeah, you are absolutely right.
That seems a bit too narrow for much of the code I’ve seen and Never say more than is necessary.
Most problems happens before testing, nice post anyway!
would you mind updating your blog with more information?
But the discussion has its way of strengthening the definition overtime.