That is an incredibly condescending way of arguing. On the other side of the coin you could claim that imperative programming is more practical, concerned with the actual steps needed to solve a problem, instead of an ideal, indirect formulation. Imagine having to explain someone how to bake an apple pie without being able to state any specific steps how to do it but instead describing the pie as some set of interrelationships of the ingredients. (That is probably not a fair characterization of FP, but it's at the same level as "[imperative programmars] love the machine").
Actually, I would point out that Lisp is not limited to any single paradigm...
But something else you wrote brought to mind this rather interesting statement from - of all places! - the introduction to Michael Barnsley's famous book, 'Fractals Everywhere':
'In deterministic geometry, structures are defined, communicated, and analysed, with the aid of elementary transformations such as affine transformations, scalings, rotations, and congruences. A fractal set generally contains infinitely many points whose organization is so complicated that it is not possible to describe the set by specifying directly where each point in it lies. Instead, the set may be defined by "the relations between the pieces." It is rather like describing the solar system by quoting the law of gravitation and stating the initial conditions. Everything follows from that. It appears always to be better to describe in terms of relationships.'
I have no idea how your reply relates to my comment. I wouldn't claim that Lisp is limited to a single paradigm, nor do I see how fractals are related to the discussion at hand.
The point is that Lisp can be imperative too. But, because the language was not constructed according to the underlying physical architecture, it's not bound by the limitations of ALGOL-like languages.
So, rather than condescending, I find this interesting: these are two dissimilar approaches to solving problems.
Your comment about baking an apple pie 'without being able to state any specific steps how to do it but instead describing the pie as some set of interrelationships of the ingredients' was also an excellent statement of the differences between these points of view.
Barnsley's perspective was that relationships may indeed be a better way to describe structures. His concern was fractals, but perhaps the analogy extends to the logical structures that comprise a program.
What are the "limitations of ALGOL-like languages"? As Turing-complete languages, they probably do not have actual limitations, rather, they suggest a style of programming which may be more or less applicable to particular problems. Functional programming, depending on how pure it is, does have limitations, notably avoiding mutable state.
You can claim that it's interesting that there are these two approaches, but the quotation you gave was definitely condescending, because it flatly states that one approach is better than the other, despite the widespread success of the latter. The argument that it's good to abstract as much as possible from the machine is interesting, but to me it is by no means obvious.
I don't really see the relation with fractals. Although it is an interesting quotation, the relation of fractals to real world phenomena is often very dubious.
> without being able to state any specific steps how to do it
All functional languages can express a sequence of steps. More yet, on most of them you can later decide to transform the sequence, instead of just generating code from it.
