Not Lisp again (2009) (funcall.blogspot.com)

2. The data is also list, and your program is also a list.

3. Algorithm are basically List Manipulation(Stacks, Queues, Trees, Adjacency lists). So its easy to write complex algorithms in Lisp.

4. Tail call recursion. This part amplifies 3. further.

5. Functional programming features.

6. REPL. I mean like a real REPL.

7. Macros.

1 - 7 helps you to express problems and their solutions with code which represents exactly that. The boiler plate and other assisting code is largely non existent.

Another reason is if a thing has been there around for the longest, more people have thought about it. Both quality and quantity of literature of it are higher than others.

For example, it is a homoiconic language, so any piece of data can be evaluated as if it is code.

The only way to really understand it is probably to learn it :)

- Structural simplicity. Instead of having a huge mess of syntax to keep track of, it has only a very small number of constructs. Simplicity is beautiful.

Criticizing it on the basis of parenthesis would be roughly equivalent to criticizing someone talking about the beauty of mathematics on the basis of the color of the piece of chalk they're using. It's true that it's criticism about aesthetics, but it's not criticism about the aesthetics that the mathematician was talking about.

Once you've understood in what sense people mean that Lisp is beautiful, you can disagree, but this disagreement will not concern parentheses.

As an aside: I have a similarly shallow aesthetic aversion to JS syntax for the same reason. When I encounter a 12-line ragged cascade of curly brackets, square brackets and parentheses, sprinkled with semicolons, I wonder how that can be considered OK.

Aside 2: with Lisp, you edit programs structurally, meaning that their position is essentially managed for you. This is what people refer to when they mean that "the brackets disappear after a while." You're not focusing on them; they're handled by something else.

In my editor, I have the closing brackets faded nearly into the background, which reflects how concerned I am about their existence.

Contrast this with most other languages, where there are many things the language does that you can not do. At least, not easily.

There aren't actually more parens in a Lisp program than a program written in a C-like syntax (which is really an algol-like syntax). They just stand out more for two reasons:

1. There is less punctuation in general, so the parens are more obvious. Instead of f(x, y, z) you write (f x y z). Without the commas, the parens stand out because that's all that is left.

2. There is only one kind of parens in Lisp whereas C-like languages use at least three: (), [], and {}, so that makes any particular kind of paren less prominent.

I'm still fond of Lisp, but languages like Python, D, Nim (and increasingly, Rust) offer a lot of the Lisp affordances that I really valued -- in particular, easy compile-time metaprogramming. The biggest missing bits are Lisp's deeply integrated REPL-driven programming, and the use of program images -- which have many drawbacks but also some benefits.

IMO, everyone should write and maintain a medium-sized program in a modern Lisp (SBCL, CCL) at least once, just to get an appreciation for how different the programming / debugging experience is. So many well-integrated tools at your disposal, even at runtime.

They are all available on the ETH website and his homepage (in various revisions). Basically everything you need to know about imperative programming on CS bachelor level for free.

The threading macro is great, but the GP one-liner tells me more about lisp.

    (defmacro -> (&rest args)
      (loop for item in (reverse args)
            for result = (list item) then (list item result)
            finally (return result)))

   ovov@ovov ~> cat repl.py
   while True:
       print(eval(input(">>> ")))
   ovov@ovov ~> python3 repl.py
   >>> x = 1
   Traceback (most recent call last):
     File "repl.py", line 2, in <module>
       print(eval(input(">>> ")))
     File "<string>", line 1
       x = 1
      ^
   SyntaxError: invalid syntax

puts and gets are string functions. read and print are code deserializers and serializers.

eval is a function that takes a data structure representing code (as deserialized by read) and computes its value as a data structure, and serializes it.

While you might get the same effect as a user, the mechanics and metacircularity are lost.

I'm self-taught and it's what made me fully "grasp" programming and the power of abstraction.

(The ANSI standard was 1994. Still nowhere near 20 years).

    constexpr double delta = 1.0e-6;
    
    constexpr auto deriv = [] (auto f) { 
        return [=] (double x) { 
            return (f(x+delta) - f(x)) / delta; 
        };
    };

    constexpr auto f¨ = [] (auto f) { return deriv(deriv(f)); }; 

    double res = f¨([] (double x) { return x*x*x; })(2.0);

I find that it follows the functional spec quite closely, thanks to Go functions being first class citizens.