Chade on 28/7/2010 at 02:40
Quote Posted by Kolya
Kick them in their fat bourgeois arses
I can't kick them in their fat bourgeois arses, on account of my abstract foot factory is currently producing skis. Now you might think that skis are a poor tool for walking down the street, but more fool you: then we couldn't use them to hold my luggage! We've grown a pair of skis with feet attached instead, which I think we can all agree is the most intelligent approach to this situation.
Kolya on 28/7/2010 at 12:07
Haha, my example may have been a bit too social... Seriously though, the theory of incidental complexity separates problem solving into the "problem space" or "essential complexity" - which you will have to find an abstract or theoretical solution for - and the problems that arise from finding the correct approach to take, the right tools to use etc. Basically the annoying circumstances of
implementing the solution you already have.
It isn't too surprising that this idea would be persistent in the Java programming scene. They always seem to have their heads in the clouds. But it should make you wonder when Rich Hickey - one of the loudest advocates of incidental complexity - first creates a new tool: His own programming language called "Clojure" (spoken "closure"). Of course Clojure is supposed to be the tool to end all tools, hence the name. But exactly how many times have you heard that before?
Note that Fred Brooks who already (
http://en.wikipedia.org/wiki/No_silver_bullet) defined essential and accidental complexity in the 80s to show why software development will never make such jumps as hardware development assumed that programmers spent most of their time on essential complexity. Something you probably don't agree with.
Anyway, what I mean when I say incidental complexity doesn't exist, is this: To solve a problem you need a precise description of the problem and that might give you an idea of how to solve it. But it doesn't end there. Finding the correct approach to take and tools to use is an integral part of the problem solving process. It's not just something annoying that happens on the way. It reconnects your idea with reality: The solution you came up with first may not be implementable with a reasonable amount of work or may have unwanted side-effects. AND there may be more than 1 solution to your problem and this will help you find it.
So it's back to the drawing board. That's what problem solving is all about: Making a theoretical solution fit for real use. Otherwise we'd know Leonardo Davinci as the inventor of the helicopter. Calling it "incidental complexity" diminishes that relation by saying:
"Solving essential complexity is the important part. The rest is incidental complexity which should be minimised." Or it gets really hazy by talking about
"exploring the problem space", which is an euphemism for: The model didn't map reality.
With an idea like incidental complexity the theoretical solution tends to become static and the programmer lazy. It's tempting. But really there is no such thing as incidental complexity.
Now since you spoke about incidental complexity in social contexts: If you have a perfectly good solution for a social problem but for whatever reason no one agrees with you, then your perfectly good solution stops being a solution. Because you cannot factor out the persons involved by calling their disagreement "incidental complexity". You might tell yourself that the solution is good but the world isn't ready yet. But that's not for you to decide and you'll just have to find a different solution.
Chade on 28/7/2010 at 23:38
I'm not sure where you're going with the clojure angle. You don't seem to reach any conclusions. I can almost guarantee that Rich Hickey does not believe clojure is the "tool to end all tools", as the language contains a number of complications making it more practical to integrate with today's technology.
I'm also not sure where you're going with the whole "tempting to believe in lazy programmer" angle. Why start talking about "lazy programmers"? What is tempting about this? I don't understand why any of this is relevant.
As for the actual issue ...
For any problem, do you deny that there are a range of different solutions, some of which are easier then others? Essential complexity is just the lower bound. Whether you consider the range of theoretical approaches, or the range of currently practical approaches, or some other range entirely, it is still meaningful to talk about a lower bound.
Your post, which admittedly I struggled to understand, seems to work by redefining the problem so that the decision making process becomes part of the problem. You then state, without any justification that I can see, that the solution/decision-process which occurred is the least complex one.
Firstly, there is no rule saying that you must consider the decision making process when talking about solutions. Obviously, at some stage, a decision must be made, but along the way you will want to talk about possible solutions without letting someone say "my stupid approach is the best approach because I refuse to believe it is not the best approach".
Secondly, redefining the problem to include the decision making process does not make the concept of incidental complexity redundant. There are still multiple ways of making decisions, some of which will be better then others, and there will still be a lower bound on the complexity of the decision making process. And likewise if you keep redefining the problem in the same manner.
Thirdly, it doesn't make any sense to say "the solution/process we have arrived at is the least complex one, because it's the one we have arrived at".
Finally, there are multiple reasons to look at a range of different solutions to a problem. We are not necessarily interested in actually implementing a solution to a problem. We could look at the range of solutions we chose from six months ago, for instance. Realising that a particular decision added a lot of incidental complexity may be useful in the future.
Tocky on 29/7/2010 at 02:58
You mean like the decision to add a lot of incidental complexity to this thread with a discussion of decision theory? I see what you mean. I could have avoided this thread. Watch that equal and opposite reaction when you go kicking butt though. The bourgeois tend to take an Alexander approach to gordian knot problem solving.
Chade on 29/7/2010 at 03:14
Hey now, I was originally on topic.
We should talk about this.
Tocky on 29/7/2010 at 03:34
Heh. You didn't make me read it. I was just reprocessing through practicalities. It's a feet on the ground approach. ;)