>>234 It goes very predictably like this.
1.LISP has a unique feature X.
2.Feature X shown to be possible in Language z.
3.LISP advocates claim that proper X could be only implemented in LISP.
4.Feature X shown to be equivalent to Feature Y.
5.LISP advocates claim that Y isn't X, despite Y being far more useful than X in language Z, while doing 90% of what X does.
6.goto #1
LISP is obviously not the sum of specific features/functions, its
paradigm of computing based on functional lambda calculus.
Its possible to graft LISP features(even EVAL) into low-level languages like C, without much benefit to C.
C programmers have obviously much more elegant solutions that
don't require EVAL or CALL-CC being used pervasively, as they understand the performance implications and incompatibility with C design due its language model being static and type-centric.
LISP programmers view these C solutions as inflexible and awkward,
since in their mind they could liberally use eval/call-cc to introduce whatever construct they like inside LISP.
Whats the point of arguing about applicability of feature X
to different paradigms? X is meant to be used for specific paradigm of computation where its invocation and cost are
already factored in.