> This difference gets worse with more complex expressions.
Actually, no - it's the other way around: more complex expressions really benefit from the uniform of syntax and using macros to simplify the code.
Not all macros are worthwhile, and some are detrimental to readability (and not writing those is one of the first Lisp lessons), but there are also macros (syntax extensions), which are elegant and powerful.
The common example is the `->` or `thread-first` macro, which chains a list of function calls, in the following manner:
With longer expressions, or longer chains of function applications, the difference becomes even more visible, with `->` version having way less parens (possibly less than in Python for equivalent expression) and less nesting, which makes it easier to read and modify.
But it doesn't end there - this is just one macro, out of many powerful syntax extensions, which make for much clearer code. There are macros for lazy evaluation, both sequences (like generators) or expressions (more like `lazy` in OCaml); for partial evaluation of functions, for changing name resolution policy, for declaring classes, for looping, for pattern-matching, for error handling, for FFI, for logic statements, for transactional memory, for async control flow, and so on and on.
Some of these are trivial to implement, but some are hard or just complicated, with many cases covered; so you're not necessarily expected to write them yourself. If a macro's semantics are well-defined - as in most popular examples - importing a package and reading docs is enough to use them to a good effect. You don't really have to use any of them, but they all exist to make certain patterns in code simpler, more readable, and more convenient to work with. Other languages often lack many of them.
Anyway, what I want to say is that the more complex the problem, or the larger codebase, the more readable Lisp becomes, at some point surpassing most other languages. This is what makes Lisp fans to be so good at "recursion and condescension", and is also something you can't see in a `(+ p 2)` kind of examples.
Actually, no - it's the other way around: more complex expressions really benefit from the uniform of syntax and using macros to simplify the code.
Not all macros are worthwhile, and some are detrimental to readability (and not writing those is one of the first Lisp lessons), but there are also macros (syntax extensions), which are elegant and powerful.
The common example is the `->` or `thread-first` macro, which chains a list of function calls, in the following manner:
into: With longer expressions, or longer chains of function applications, the difference becomes even more visible, with `->` version having way less parens (possibly less than in Python for equivalent expression) and less nesting, which makes it easier to read and modify.But it doesn't end there - this is just one macro, out of many powerful syntax extensions, which make for much clearer code. There are macros for lazy evaluation, both sequences (like generators) or expressions (more like `lazy` in OCaml); for partial evaluation of functions, for changing name resolution policy, for declaring classes, for looping, for pattern-matching, for error handling, for FFI, for logic statements, for transactional memory, for async control flow, and so on and on.
Some of these are trivial to implement, but some are hard or just complicated, with many cases covered; so you're not necessarily expected to write them yourself. If a macro's semantics are well-defined - as in most popular examples - importing a package and reading docs is enough to use them to a good effect. You don't really have to use any of them, but they all exist to make certain patterns in code simpler, more readable, and more convenient to work with. Other languages often lack many of them.
Anyway, what I want to say is that the more complex the problem, or the larger codebase, the more readable Lisp becomes, at some point surpassing most other languages. This is what makes Lisp fans to be so good at "recursion and condescension", and is also something you can't see in a `(+ p 2)` kind of examples.