>> I think the advantage to Lisp is that the programmer can generate and evaluate arbitrary expression trees at run time.

That's the one! Code is data - data is code. While this can be done in other languages, it isn't done without considerable effort or going 'off road' so to speak, macros are Lisp. cheers.

Isn't eval part of the cause of many security holes in other languages, e.g. Javascript? That is, not eval alone but combined with an unintended path from unvalidated user input to the snippet that gets eval'ed.

Is there anything special Lisp does to prevent user input from getting into eval'ed data-code? Or any sandboxing provided by Lisp's eval?

You never ever eval user input.

I thought this was super common knowledge, yet I reviewed a co-workers pull request the other day and found files filled with eval (easily 30 usages) as well as global state (treated and mutated as if it was thread local).

The most annoying part was that what they wanted to do didn’t even require eval and they refused to fix it even after I’d found a safe, non-eval way to do it.

This rule is true for Javascript and PHP too, yet it happened all the time. If Lisp relies heavily on eval, what specific protection measures does it employ?

Mainstream Lisp dialects do not "rely heavily" on eval. Its use is broadly discouraged in favor of other mechanisms like apply or macros.

Newbies sometimes learn about backquote before learning about apply, and when they need too pass a dynamic list of arguments to a function, they end up writing (eval `(fun 1 2 ,@args)) instead of (apply fun 1 2 args). Or doing some metaprogramming using (eval `(defun ...)) in the middle of a function, instead of making a function-defining macro.

In JavaScript and PHP, not to mention numerous other languages, eval is the only meta-programming you have. If you need to generate code, you end up using eval. Moreover, eval is textual. Textual code requires very careful escaping to avoid injection problems. Lisp's eval is AST-based, so it doesn't suffer from that.

If I have a user-data variable that holds untrusted user data and put it into an evaluated code template, as in (eval `(list ... (some-api ',user-data) ...), I can completely trust that user-data will not "go live". It's inserted under a quote, and that's that. There is no way that content can bypass the quote, no matter what object it is.

> Haskell, OCaml, probably F# too.

Lisp has macros, read-macros, and eval. These things enable DSLs. You're saying strongly-typed functional languages have features of equivalent power for this purpose?

Yes, for example F# has quotations, type expressions and type providers.

Also .NET has attributes, compiler plugins and expression trees, which allow to do some kind of similar stuff even for C#, although not as straightforward as in Lisp.

On the Java side, you also get the attributes (aka annotations), compiler plugins, AOP (yay CLOS interceptors).

Haskell has Template Haskell and OCaml has ppx extensions.

Those are so distant to what Lisp macros achieve. Also, I can't believe you brought up Java annotations in this discussion.

They are, but as they say back home, those who don't have dogs, hunt with cats.

Writing EDSLs (E for embedded) is fairly common in Haskell. I don't know if it's as easy as with Lisp macros though since I have no exposure to that.

Many DSLs are written on Haskell (Elm and Purescript come to mind) as well.

It's all about ergonomics though. In Lisp, it's super easy, and even fun with macros. They can probably do roughly equivalent things in the other languages, but it's so fucking painful it's relegated to rare use and for relatively short code sections.

For Lisp users, it's like holding the knife by the handle. For them it's like holding the knife by the blade.

Hum... Yes.

Not exactly equivalent, but monad-based DSLs have almost the same power as Lisp macros.

You can't escape the syntax restrictions, the same way you can't escape Lisp's syntax restrictions. And it's a bonus for Lisp (in power) that its syntax is much more flexible. But in semantics they are equivalent.