Why care about functional programming? Part 1: Immutability
miles.no
miles.no
Worse, nothing about functional programming is necessarily about immutability. It is a convenience on small and easy problems, but is far from required. Consider how your computer adds two numbers. Lots of things change state under highly timed situations to give you that answer. It is not some magic table lookup that works with immutable facts.
I may just be bitter by a system right now that is using immutable objects everywhere. I realize this is a straw man, but with heavy reliance on deep (3+ levels) of immutable relationships, it is not uncommon to find crap that is the equivalent of this:
String foo = "hello";
Character bar = foo.charAt(0);
...
//We need to make sure bar is capitalized everywhere
baz = bar.toUpperCase();
//Now to find everywhere this matters and let the caller know.
Can I recommend meditation? Maybe going for a run.
It is funny that this would lead to meditation, as there is a good parable that seems appropriate here.[1] Not all fads are processes, and I'm sure there is a "truly immutable patterns don't have this problem" hiding somewhere.
[1] http://www.ckwop.me.uk/Meditation-driven-development.html
A better example would be
SomeLargeTreeThing foo
bar = sanitizeTreeThing(foo);
//Now, make extra sure nobody uses foo.
//Not even accidentally in the future.
In this example, it's not about "making sure nobody uses foo". Nobody is making you use it again. If you don't want to use the variable again, just... don't use it again. Or, you can use it again, if you want to, but if you make an error your tests should fail or your compiler should complain about an unused variable. It's not rocket science.
public foo(Bar bar) {
Bar updatedBar = baz(bar);
//Lots (10+ lines) of code
return finishProcess(bar); //Note, this should have been updatedBar.
}
Also, I don't know why you're acting like this kind of error represents the ultimate failure of functional programming. Yes, sometimes you get your variables a little mixed up when you're using immutable data structures. You get used to it, and if that's the biggest headache that you come across when working with immutable data structures, then it seems like everything is more or less working as advertised.
Where did I say this was the ultimate failure of functional programming? I do not think it is. Nor do I think functional programming is a failure. It is a good skill to have. But so is understanding some of the non-immutable algorithms out there.
That said, that function looks strange. What were those other lines of code doing if they didn't contribute to the result? Doesn't look like a referentially transparent function to me.
This gets back to my point in a sibling about more types and better organization could have helped. Sure. I'm not even going to claim that immutability caused this bug. As it didn't. It also was not a silver bullet that helped make this code bug free.
public foo(Bar bar) {
bar = baz(bar);
//Lots (10+ lines) of code
return finishProcess(bar); //Note, this should have been updatedBar.
}
public foo(Bar bar) {
bar = baz(bar);
//Lots (10+ lines) of code.
bar = qux(bar);
//Lots (10+ lines) of code.
return finishProcess(bar);
}
Of course, usually when adding final to messy Java code I'm trying to understand, this ends up telling me that the whole piece of code was fragile, hard to understand and in dire need of a refactoring. All of which makes final useful to me.
How do you insure that a maintenance coder ten years from now doesn't use it again?
printf("butt\n");
This is not something that is not at all difficult to understand... for anyone who has ever actually worked on shipping code.
I don't know how anything I've said has even been slightly controversial.
If foo is immutable there is no harm if something else tries to manipulate it because it will just derive a new data-structure.
I'm not really trying to rain on your tirade---surely there are ways to misuse immutability---but I can't look at this example and not feel that immutability is telling you something about a better architecture.
//Now to find everywhere this matters and let the caller know.
Getting some help from language is nice, but after 10+ years of programming all those patterns (e.g. immutable) become so natural, that you don't really think much about them. Because you know what data structure you want, and see what language offers you. So the whole "which language" deal doesn't make so much difference (although it's easier/harder in some languages). Tooling/libs and community matters way more.
No one prevents you, but what about the code other people write?
I've got this renderer that takes a huge data structure and uses simple OpenMP constructs to draw images. There is an assumption that the underlying data will not change during a render. Do I need a functional language to enforce this? No. Would it be nice if C++ had a feature to enforce it? Yes. Will I eventually want to make something that can carefully modify the data while rendering? Maybe, but I'm not sure that even makes sense.
I think a bigger threat is event driven code which IMHO is notorious for making things happen in unexpected order.
The only difference between C++ and "immutable by design" languages is that in C++ you'd have to write your own little processor to ensure that your rule is followed (this is no big deal, and I've written much more complex processors to enforce C++ coding standards as part of the build.)
What do you mean by unexpected order? I find event driven code to be the easiest to understand and maintain. Typically, you will be forced to specify order explicitly, i.e. nesting callbacks for sequential execution or not for parallel.
Events are find if your app is stateless (boring). Otherwise you may get events when things are not ready for them. You can get around that with lots of checking, or perhaps building a nice OO system underneath may help. I have a hard time explaining this because it can be subtle. See the Therac 25 for an example.
You can probably do this in any language, but efficiency is another issue.
[1] http://package.elm-lang.org/packages/elm-lang/core/1.1.1/Sig...
This is unfortunate, because it could potentially be a very useful if every single atom of data came with a built-in list of previous states, with timestamps, and with an identifier for the code/process that last changed the state.
Obviously, this is usually what debuggers try to do. But there's no reason why something like this couldn't be built into a language.
(Yes, it would be slow. No, it wouldn't be that slow if done right. It wouldn't even have to be slower than many other standard practices. But yes, it could potentially use a lot of memory unless given a cutoff. Even so...)
CS generally still seems stuck in the "memory is a line pigeonholes" model, and immutability seems to be a crude memory management hack, not a complete state control solution.
I sometimes wonder if a lot of the issues with state are caused by the fact that languages have extremely limited tools for dealing explicitly with representations of historical causality and past/present/future, and not because state itself is inherently evil.
Well, it depends on which version control system we're imagining. In my mind, the immutable data-structure approach is like git, and I think what you're imagining is more like CVS.
Consider: immutability by itself doesn't enforce versioning; it just makes the state-of-the-world equivalent to state-of-the-root-pointers-of-your-heap, because the pointed-to things cannot change. (I.e., referential transparency.) So it pushes the versioning up to whatever agents manage the root pointers. This is sort of like git: you build an immutable DAG, and you have mutable HEAD pointers that move around in it. (The difference is that git has one HEAD for the tree while this world has one HEAD per global or stack-local root.) When you have a reference, you have a snapshot of the world in time that will never change.
Your "each slot has a list of previous states" is more like CVS in that it versions each "file" separately. This is also useful, but for a different reason: sometimes you really do want that history as a first-class concept. You can derive the per-file history in a git-like system too but it involves some computation. (And coming back from the analogy, in such a memory-management scheme, you would need to formalize the changes to root pointers into some sort of transaction system.)
All of that said, I think what you describe would be really useful for debugging, albeit probably pretty expensive (each store instruction touches an undo log?). Time-reversible debuggers may have done something like this?
There is a lot to recommend a functional programming style in general and forgoing mutation of data in particular, but these are programming practices. Clojure allows mutation. Common Lisp allows it in ways that are as mind blowingly difficult to grok as macros. The shared structure that allows efficient immutability semantics allows a tsunami of value changes if someone is careless or malicious.
Cheers!