Re: novice: mapcan use?



Pascal Costanza wrote: 
Kenny Tilton wrote:


Pascal Costanza wrote:

It cannot be stressed enough: Don't use the destructive functions as your regular tools, and better forget completely about them in the beginning. They should be used exactly like the non-destructive versions, and only ever for optimizations. There's no other advantage in using them, and you should only optimize those parts of your code that you have measured before so that you know that optimizations actually buys you anything. Everything else is a waste of your (valuable!) development time.


Rubbish. That is a defense of ignorance, and a recipe for newbies writing code so painfully slow they abandon Lisp.

/Always/ use the destructive version if one can get away with it. Understanding when one can get away with it is not so hard, and requires no more than the same understanding one needs anyway to program in Lisp.


Code doesn't get automagically faster by replacing non-destructive functions with destructive ones.

Uh, yeah, actually it does. You are simply defending ignorance. In any given situation I can safely use delete or I cannnot. If I can use delete, then using remove conses for no better reason other than to save me from thinking. Or, in the case of newbies, from learning Lisp.

btw, this is not about optimization. Optimization is doing extra work and maybe even obfuscating things a little to get better performance than is possible with straightforward code. There is nothing un-straightforward about destructive functions.

Except I am starting to think /you/ are not sure when destructive functions can be safely used. Hey, good question. Do /you/ follow your own recommended practice of always using non-destructive functions? Is the only time you use delete when you have a performance problem and are trying to fix it?

--
Kenny

Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film

"I've wrestled with reality for 35 years, Doctor, and I'm happy to state I finally won out over it."
Elwood P. Dowd, "Harvey", 1950

.

Relevant Pages

  • Potential speed
    ... Lisp is generally a good deal slower than C unless you do heavy ... optimizations on the bottlenecks that you identify through profiling. ... C's for loop doesn't offer much information about what sort of looping ... Then it is more likely to be optimized by a C compiler by making the ...
    (comp.lang.lisp)
  • Re: off-topic: Why is lisp so weird?
    ... Common Lisp has declarations you can use to hint that the ... compiler should perform optimizations that make the compilation more ... do some very strong optimizations in the inner loops of your code. ... > and it was a lot faster than in Scheme. ...
    (comp.lang.lisp)
  • Re: introspection in SML
    ... when I program with MLton, *I* do not optimize the code. ... which has a Lisp interpreter in it). ... by using an optimizing compiler. ... clever optimizations, caches, search hints, and so on. ...
    (comp.lang.functional)
  • Re: Redundant match clauses (Re: Which programming language is better to start)
    ... it's nonsensical to ask that Lisp performs pattern match optimisation since Lisp doesn't have pattern matching (unless you use ... The compiler will need explicit annotations to decide how the data structure at hand should be interpreted - and, of course, annotations are the exact opposite of inference. ... it would be possible to perform type based optimizations unsafe primitive operations when it is known to be safe) using macros." ... However, it's very, very easy to "infect" an ML program with typeless data, so you immediately lose static typing. ...
    (comp.lang.functional)