Subject: Re: Please help From: Erik Naggum <erik@naggum.no> Date: 1999/04/09 Newsgroups: comp.lang.lisp Message-ID: <3132644015217581@naggum.no> * paul_rudin@scientia.com | But of course it's not for "no purpose". The purpose is to write correct | code first time round as often as possible. that is supposed to be the consequence of successful training or education. if you have to do something silly to get correct code, that _should_ have been a very strong warning sign. | If you *really* want to avoid waste write assembler, or indeed machine | code :-) idiot. | Then decide where things can be modified for effeciency. if you have no concept of what is or is not efficient before you start, doing it afterwards will be very, very inefficient, in programmer time. you appear from the above comment not to understand that "wanton waste" is not restricted to what the computer does. I suggest you broaden your perspective and appreciate that the whole idea of programming computers is to reduce the total cost of the tasks the computer is set to do. | Sometimes the code you writing doesn't suit this style, because the data | structures and algorithms you've decided are naturally expressed in an | imperative, destuctive fashion. (As it happens I've spend most of this | week writing code to shuffle bits around bit vectors, because this is the | only practical way to get the kind of performance needed for the task in | hand.) at least this looks like a redeeming quality, but I'm uncertain about how you decide on data structures and algorithms to begin with. in my view, functional programming is not usefully extended all the way down (i.e., we don't want non-destructive instructions or memory, which would have meant we'd need a new computer every billionth of a second), so clearly there's a point where the exported interface is functional and the implementation is not. I extend this view to functions at any level: functional programming is about a design style that _exports_ a clean interface, but I should _not_ care what it does inside. consequently, if I design a function with a clean interface, it matters not whether I use a "dirty" technique or not inside it as long as nobody is impacted by it. this, incidentally, leads to why I favor a more functional programming style: I don't have to deal with any "ownership protocol" of objects that have been allocated, but when I do know that I alone own an object, I have no compulsions about modifying it, or asking functions I call to modify it. and I _don't_ see this as betraying the Functional Style. #:Erik