You bring up a good point about passing map and filter around. I hadn't really thought of that.
I still prefer to user list comprehensions, and don't think it would be so bad to have map, filter, reduce live in the itertools module. This would stylistically match what is done with the comparison operator functions living in their own module, which you can import if you need to pass the functions around.
List comprehensions are great, but they're sort of a DSL-- something the syntax recognizes as special and converts to something else. It's unusual that you can pass around higher-order syntactic elements, while every modern language worth its salt allows you to pass around functions.
Common Lisp has something similar, called LOOP. Implemented as a macro, it's a within-Lisp DSL for expressing looping constructs, e.g.
(loop for i from 1 to 10 sum i)
=> 55
(loop for c across "bar" collect c)
=> (#\b #\a #\r)
It's controversial within the CL community, because the loop language looks much more like traditional languages than Lisp.
The automatic distaste in our industry for things that are old is a disease, a form of vanity. Old ideas are not inadequate because they are old. Most great ideas are old. Sometimes, of course, an old thing is a vestige of some ancient limitation that no longer applies. Those ones are good to clear away. But the prevailing thought process in the software industry, no less dominant for its astonishing primitivity, is to reject the old per se. The will to novelty is so extreme that it doesn't matter if the new thing is worse, only that it is newer. We want to program in new languages like we want to drive new cars (a bad analogy in Common Lisp's case, unless you assume that the older car is both faster and more fuel efficient). Lisp in general, and Common Lisp in particular, is up against this dynamic. You can't understand the reactions to it without accounting for that.
That CL contains TAGBODY is a brilliant thing. It amazes me that a language can be at once so high-level and so low-level. I haven't had occasion to use it yet, but the fact that it's there, and that the higher-level abstractions are built in terms of it, is a thing of beauty to me. (I don't know about PROGV.)
You make a great point, and I think Lisp has enough fundamental value to deserve its place as the "100-year language". In 2060, people will still be using some descendant of Lisp. On the other hand, I think some aspects of CL are outmoded. I don't like the lack of support for maps as a top-level structure, and equality in CL is seriously broken, IMO.
I'd prefer to code in CL over Java/Blub, but I prefer Clojure over CL, and probably Haskell or ML over Clojure. (Lisp has better syntax, and macros are very cool, but static typing wins for large projects, in my opinion.)
I still prefer to user list comprehensions, and don't think it would be so bad to have map, filter, reduce live in the itertools module. This would stylistically match what is done with the comparison operator functions living in their own module, which you can import if you need to pass the functions around.