Hacker News Reader

Comment by behnamoh | Hacker News Reader

I agree with this. But CL programmers seem to think Lisp is timeless and its best days are ahead of it still. I wonder if they're already awesome programmers and that's why they pick Lisp for maximum freedom (macros?). Most people aren't wizards, and can't (nor do they want to) invent small DSLs on the go.

With great power comes great responsibility, and most people don't want that responsibility.

View on HN

I can assure you that most people are not considering Lisp and thinking, "huh, this is too much responsibility, so not for me."

Lisp has a higher barrier to entry compared to Python or Rust or other languages available. For that simple reason alone, it's not used. None of these imagined reasons about the theoretical power or anti-power of macros, or being a wizard, or whatever are part of the calculus of choosing a language.

Learning Lisp has a tricky part, and one of my classmates in undergrad despaired of ever learning it, but surely Rust is harder to learn than Lisp, which makes me wonder what you mean by "Lisp has a higher barrier to entry".

You have to first install a Lisp compiler whose REPL is so spartan than even using arrow keys causes errors in your terminal. You have to learn Emacs. Figure out wtf SLIME and Paredit are from docs written in piecemeal plaintext READMEs. Then learn from a book that's older than you that makes no reference to any of the tools you just labored over installing. Then get a bunch of conflicting information about proper Lisp style from random patches of internet.

Who has time for that these days, except for the very determined and dedicated?

I think Lisp is a superlative language with excellent tools—once learned. But it hasn't had its UI revolution from anybody who cares enough to do the work.

I've been writing Lisp for 40 years, and still haven't started using SLIME or Paredit.

And the reason it is called "style" is that it is not essential to actually getting things done.

Style is not essential to getting things done, but it's essential to building a community and having labor be multiplicative in its impact. Lisp is a language ripe for expressing a personal style, and that's antithetical to collaboration in a variety of ways. It can be managed, if the community can rally around a common set of principles.

I likewise have written Common Lisp for decades. But I also get paid to do it, manage a team that does it, and see immense value in doing these extra things that hackers don't much care for, such as:

- making Lisp compatible with other languages through ABIs

- developing stylistic guidelines

- developing systems for static typing in Lisp to assist long-term development and maintenance of Lisp code

- etc.

So does style or the lack of any of the aforementioned bullets "block" the ability to "get things done"? Strictly speaking, no, but it inhibits outside interest in your project.

> Lisp is a language ripe for expressing a personal style, and that's antithetical to collaboration in a variety of ways.

I concede that point. Also, I'm the only user of most or all of the Lisp I've written over the last 40 years.

IDK why you're being downvoted. The things you mentioned are actually true and I've faced them too.

Lisp early on exposes its dual nature of code and data. Even in interactive environments. This ever-present meta-level is unusual.

None of the assignments my classmate struggled with required him write code that processes code, so I don't think that was the source of his confusion.

My guess is that it has more to do with the fact that CONS takes a whole list as an argument, then returns a different whole list, which superficially seems too computationally expensive to do in a loop.

> None of the assignments my classmate struggled with required him write code that processes code

That's not what I meant. What Lisp with s-expressions already makes more difficult is that the data syntax is used to express programs.

    (defun foo (list1 list2)
      (quote (defun foo (list1 list2) (list list1 list2))))

-> A symbol can be an identifier and just a piece of data.

Above, the first DEFUN is a standard identifier of the programming language Common Lisp. The second DEFUN is just a symbol.

The first DEFUN form is a program. The second DEFUN expression is just data. Thus it makes no sense to indent the second DEFUN expression like a program. We don't know if it is a program, it could be just anything.

-> A list can be data and a program.

This specific double nature of built-in data structures, here symbols and lists, is already a hurdle to get over.

The developer has to know which lists are data lists, which are forms and which are expressions in inside a form.

    (cond ((quote (a))))

    (cond ((quote (a)))) is a form, which is meant to be evaluated

    (a) is data

    ((quote (a)))  is a clause of COND, which is neither data, nor a form to be evaluated

Thus the user has to understand that in Lisp these lists serve different purposes. Which is which depends on the context and the Lisp syntax & evaluation rules.

This then even may make functions possible which contain their own definition as data:

    CL-USER 9 > #1=(defun foo (list1 list2)
                     (quote #1#))
    FOO

    CL-USER 10 > (foo '(1) '(2))
    #1=(DEFUN FOO (LIST1 LIST2) (QUOTE #1#))

Reply on news.ycombinator.com