Has there been any exploration into an idea where the problem with side effects is not that they make functions impure, but they are often against the metaphor of the instructions being given? That is, if the metaphor that one is trying to model is traditional mathematics, then of course side effects are terrible.<p>However, consider a program where the main metaphor is controlling something. Logo, for example. Few people argue, I would think, that the traditional imperative styling there hurts and confuses things.<p>More extreme, consider stack based languages. These are strictly based on the current state of the program, yet my understanding is if you can fit your mind to that metaphor, it works very very well.<p>Or, my favorite category, cookbooks. Look at traditional baking directions: "Begin heating oven to XXX, mix dry ingredients in bowl, add butter, whip, ..." Doesn't get any more imperative than that, and yet people around the world often have great success replicating the desired results. (Granted, I often think that the difference in programming and teaching is that humans make an effort to understand what you were communicating, computers typically don't.)<p>Does this make sense?
Rich Hickey has a great description of how to think about working with immutable values - what we usually want when we change a variable is simply the next value and so long as we are getting the value we expected, there's no need to name it.<p>In other words if our current position in an array is 2, what we need to access the next position is the value 3. Creating a variable <i>int i=2;</i> and then mutating it <i>i++;</i> introduces the possibility of side effects. This not to say that at an abstraction layer below our programming language a register won't get incremented, only that our brains don't need to worry about the mechanisms most of the time if we use a functional language.
As someone who still doesn't get functional programming, I would like to see a real-world example of how to deal with side effects. Eg: write something into a file or a DB. Because <i>of course</i> methods/functions with no side effects are easier to deal with, it sounds good, but I don't think it would be easy nor convenient to separate every side effect in a real-world program (as opposed to academic programs, where you just write a Fibonacci or whatever). Even in good OOP, you can have lots of side effects in a method.<p>Halp!
I want to take a leap and talk about 2 core concepts that I got after spending last week learning Clojure. I'd love some comments about them.<p>I've been writing javascript for years but functional programming didn't make sense until I realized:<p>1) It's essentially inverted callbacks. You can read and reason about your code by working from the inside out. The results of a function are passed up to the outside.<p>2) When you stop modifying variables and just pass them around, it becomes a lot easier to think about code in abstract ways. There are of course some situations where modifying a variable is needed, but it really feels icky and you think twice about doing it.<p>The problem I found trying to learn this stuff is that once you learn to think functional its hard to think like someone who doesn't get it. That makes it hard to translate concepts in ways that non-functional people can get easier. I'm keeping mental tabs on ideas as I understand them to hopefully help with this problem.<p>Also, macros. Clojure people love talking about them. They aren't explained well most of the time though.<p>Simplest explanation is that you can write a bunch of your own functions, even ones that will override native functions, i.e macros. Since clojure is a compiled language, at compile time all the source code gets read in and pre-processed. When the compiler reaches some code that was defined in a macro, it keeps rewriting that code until all the macros are processed and the code has been re-written. Then everything is compiled to bytecode for the jvm.
I found LightTable* as a great way to grok functional programming - you can actually see how data moves around. Really brilliant.<p>*Lighttable IDE: <a href="http://www.chris-granger.com/lighttable/" rel="nofollow">http://www.chris-granger.com/lighttable/</a>
> It always returns the same result given the same arguments. This is call "referential transparency" and you can add it to your list of five-dollar programming terms.<p>> It doesn't cause any side effects, e.g. it doesn't "change the external world" by changing external mutable objects or outputting to i/o.<p>These have little to do with one another. "sort :: [a] -> [a]" sorts a list, perhaps using quicksort. If you want to randomize the pivots, it's "sort :: [a] -> IO [a]", and everything in your program that sorts things has a different type, even though it produces the same value.