On Thursday 15 September 2005 04:38 am, Jerzy Karczmarczuk wrote: > is for me a biased view of the problem. Justified only by the fact that > at the beginning of functional programming (sixties) nobody cared about > the efficiency. Now, such languages as Clean, or good implementations of > Scheme are very well optimized. OCaml as well, and Haskell is improving > every 3 months. Functional languages did take off, but since a pure > functionalism requires particular, quite sophisticated techniques in > GOOD algorithm design and implementation, they are less adapted to the > brutal world than C or Python. The reasons of relatively small popularity > are much less technical than psychological, and this is KNOWN.
This is ludicrous sophistry. The technical reason for having ANY high level languages is "psychological". Computers are happier with binary code, over ANY language that must be interpreted. So, presumeably, would some perfect intellectual being not limited by "mere psychology". Programming languages are an interface to Human minds, so the argument that one system of representation is easier to understand is an argument that that system is *better* in that it is a better interface. > (Terry Hancock formulated this plainly, he prefers dumb ways because > he wants to solve problems, and he doesn't like to perform gymnastics > with his brain. We have to accept those attitudes. But I believe that > this is the effect of teaching standards; people don't learn high-level > algorithm design when they are young enough...) Clearly Jerry here believes that arrogance and intelligence must go hand in hand: just for your education, there is a difference between *being* intelligent and feeling like you have to *prove* it to everyone you meet. I learned a long time ago, that there are plenty of *unavoidably* complex problems out there, so that there's so need to make simple ones complex, just to prove how clever you are. You're darned right I avoid wasting time on problems that don't require it. As for the education claim, you are just *so* out of your depth ... Humans learn to program about as early now as they can handle the subject. Many working programmers today started learning to program in grade school, most of the ones under 30 or so started in high school at the latest. As a matter of observable fact, people tend to solve problems in certain ways more naturally than others (and not necessarily the same way as other people). There's nothing "more natural" about functional programming than procedural. In fact, it would appear that some problems are more intuitive to solve one way or the other. The FP camp (apparently) wants to advance the claim that FP will *always* reduce bugs. I find that very hard to believe. It seems to me that programmers will always have an easier time reducing bugs in programs they *understand* well. While cleverness in algorithm design is always respected for the intellectual prowess it demonstrates, it is almost always bad engineering. "Keep It Simple Stupid" is just as good a rule in computer science as in any other area of engineering -- and given the natural complexity of CS, it clearly needs such admonitions more. I don't avoid complex code because I *can't* understand it. I avoid it, because complex code gets in the way of solving problems. You might argue that FP code is simpler because it is shorter or encodes fewer conceptual steps (within the FP framework), but this is just as false a measure, IMHO, as Perl (or C) advocates' tendency to measure complexity in keystrokes or lines of code. Just because something involves fewer symbols doesn't necessarily make it simpler. There's a correlation -- but other factors, like the amount of time the reader is going to have to spend visualizing or stepping through the process are just as important. Rules like estimating project complexity in lines of code rely on assumptions that the average level of understanding required to deal with average lines of code are about the same. It would seem that in practice this is true. But that is tangential to this argument: if you insist on a difficult methodology, then you are violating the assumption of the LOC estimation model, and it will no longer be accurate. To the degree that FP makes each LOC harder to understand, it is cancelling out any LOC savings it makes. So, when FP is intuitive AND reduces code complexity AND is reasonably efficient, it's a good buy, and I'll use it -- but to argue that it will *always* do so seems insane. -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com -- http://mail.python.org/mailman/listinfo/python-list
