On Friday 16 September 2005 08:35 am, Michael Sparks wrote: > Steven D'Aprano wrote: > > But there is a difference: writing assembly is *hard*, which is why we > > prefer not to do it. Are you suggesting that functional programming is > > significantly easier to do than declarative? > > But there is a difference: writing assembly is *hard*, which is why we > prefer not to do it. Are you suggesting that object oriented programming is > significantly easier to do than old style imperative?
The answer in both cases, is that it depends very much on what you're trying to write. > FWIW, IMO once you've learnt functional programming's idioms it certainly > can be easier and more natural. In particular domains of problem-solving, yes. > The problem is the tools that make things > like recursion efficient aren't available normally in mainstream languages > meaning that most people simply don't get the practice. There's also an assumption here (which I regard as a fallacy), that different models of programming are equally intuitive. Some models, like OOP, draw heavily on experience *outside* the realm of programming (in many cases, you can successfully apply machine-shop experience to a programming problem if the program is object-oriented -- in fact, ISTM, this is the *primary* power of OOP, that it allows you to provide experience from the problem domain to the process of writing a software program to work with that domain). Functional programming (and I am no expert here), seems to me to draw heavily on the problem domain *of* computer science. So naturally, computer scientists think it's brilliant and intuitive. But for those of us who primarily regard computers as tools for solving problems in other domains -- such as image-processing, web-application, handling business transactions, or simulating supernovae -- FP just doesn't seem very natural at all. In fact it seems completely backwards, perverse, and twisted, as if the designer were simply trying to confuse and obfuscate the problem instead of solving it. Or at least, it frequently does. > Essentially it's about expressiveness. Yes, and expressiveness means keeping vocabulary and grammar for different applications, not throwing one out on the basis that it is somehow superior. If you *are* making the latter claim, then the burden is on you to prove that your method is really that much better. > Think of it this way - we normally write left to write, however some > languages read up and down. Neither is inherently better or easier > than the other, but for some things *may* be more expressive. I *really* doubt that, actually. ;-) But I heard what you meant. > If you think about it being about choosing the most clear/expressive way to > describe an algorithm, the argument may become clearer. After all, the > recursive definition of some things is clearer than the non-recursive. Yes. I think all we're claiming is that the reverse is equally true. In addition to this kind of elegance argument, there is also a pragmatic argument that, with existing technology, it is sometimes much more efficient to write an iterative solution than to insist on recursion. Even if it can then be shown for particular cases that a recursive solution that is also efficient exists, and even if it can be proven that, in general, all such efficient iterative solutions have equivalent recursive solutions, it does not defeat the simple point that the obvious iterative solution is faster and more efficient than the obvious recursive solution. Let's not forget that this started with an example of the Fibonacci series. Who in their right mind would *actually* be trying to solve the Fibonacci series for a practical programming application? It's a toy, like the "hello world" program. I have no doubt that I can handle the extra burden of understanding the cleverly structured "efficient recursive" algorithm, versus the alternatives. But I can also see that it *is* more of a burden to understand it -- it causes confusion. Now what happens when the complexity goes up ten-fold, and we add extra bells and whistles to it that theoretical programs usually skip over, and real world programs have in abundance? At that point, I *really* want that core problem to be simple to understand. Ideally, as simple as it can possibly be. -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com -- http://mail.python.org/mailman/listinfo/python-list
