4 ms·

The main things about Lisp: 1. The syntax: It's just parens/brackets, where the first item dictates the meaning of the rest, all separated by whitespace. That'

The main things about Lisp: 1. The syntax: It's just parens/brackets, where the first item dictates the meaning of the rest, all separated by whitespace. That's the whole syntax of Lisps. If you have a good IDE (e.g. Emacs + CIDER), this can make you slightly faster at editing code than normal. 2. Functional programming: Many lisps traditionally use recursion. It's not necessarily a core part of Lisp nor is it super great (I avoid it whenever possible). Most of the FP you get from Lisp you can also get from JavaScript and a good FP library (e.g. lodash). 3. Immutability: This isn't traditionally part of Lisps either, mostly just Clojure, and it can be done with libraries in JS. But people often mix these up and think it's a Lisp thing so I listed it here. 4. Macros: Many other languages have good macros now (Elixir, Rust, etc). It can be useful in certain situations, especially how it's used in Rust's stdlib and third party libs, but it's not a panacea as commonly thought. 5. Homoiconicity: This is one of the biggest touted features of Lisps and I just really don't think it's that great. It's mostly useful in writing macros, but other languages have macro systems that don't really suffer from not having this. 6. Bootstrapping: The original idea of Lisp being a language that can bootstrap an interpreter of itself using only a tiny set of special-cased evaluation rules ("special forms") is intellectually neat but not practically useful. 7. Common Lisp: This is its own thing. It's super complex and some people really love it and swear by it. It's kind of like a C++ competitor. It honestly shouldn't even be categorized with the rest of the Lisp family. That's like saying Europe is part of Italy.

papaf 6y ago
You make some good points but I disagree with: 4. Macros: Many other languages have good macros now (Elixir, Rust, etc). It can be useful in certain situations, especially how it's used in Rust's stdlib and third party libs, but it's not a panacea as commonly thought. For me, the big deal with lisp macros, is that you write the macros in lisp itself and can call lisp functions at compile time. The last time I wrote a Rust Macro they only supported pattern matching and templating -- any rust code was only run by the final compiled program. Have Rust macros got that much more powerful now?
- geofft 6y ago
  The built-in macros haven't but there's good support for procedural macros ("proc macros"), which are Rust code run at compile time that transform AST to AST. However, this is "just" a particularly well-polished form of compiler plugins - technically you can run C code at compile time with a GCC plugin, do cool things with libclang, etc. Writing project-specific compiler plugins is unusual but not totally unheard of: Linux has a couple, for instance.
- didibus 6y ago
  Ya, OP is underestimating Lisp macros, the biggest of which is that Lisps tend to bundle their compilers within their runtime, so macros can actually expand at runtime, since compilation happens at runtime. The other of which is that they are so easy to write, that they just become another tool you use on a constant basis, just like you'd write a function, you write a macro, no big deal. I don't know that most Rust users have busted out a Rust macro or ever will. And one more of which is that macros are so well integrated, the languages themselves are implemented almost entirely with them. The number of compiler forms you need is very small. I think Common Lisp has like 30 compiler forms, and Clojure like 20, Scheme must be even less. That's all you need. This is why Clojure has a JavaScript, C#, Erlang, C++ and Go dialect as well as the default Java one, because you don't have that much work to do in the compiler, everything else just re-use the macros. I'll give in to Elixir, whose macros are pretty good, and for which I like the language, obviously, since it's like a Clojure with a different syntax and Beam instead of Java :p. Still would have preferred they'd just go with a full Lisp syntax and macro system, but oh well, a Lispyfied Ruby shall do. But ya, most other languages, even those trying to have more macro support like Nim, Rust, Julia, don't fully approach Lisp macros, even if some gets pretty close, like Elixir. Also, I don't know if comparing other niche languages with a niche language is a very good overall comparison.
  - eigenspace 6y ago
    I'd say Julia's macros are basically at a lisp level. The main difference between Julia and lisp macros is that julia has more syntactic forms so macro writing has some extra cognitive overhead.

papaf 6y ago

You make some good points but I disagree with: 4. Macros: Many other languages have good macros now (Elixir, Rust, etc). It can be useful in certain situations, especially how it's used in Rust's stdlib and third party libs, but it's not a panacea as commonly thought. For me, the big deal with lisp macros, is that you write the macros in lisp itself and can call lisp functions at compile time. The last time I wrote a Rust Macro they only supported pattern matching and templating -- any rust code was only run by the final compiled program. Have Rust macros got that much more powerful now?

geofft 6y ago
The built-in macros haven't but there's good support for procedural macros ("proc macros"), which are Rust code run at compile time that transform AST to AST. However, this is "just" a particularly well-polished form of compiler plugins - technically you can run C code at compile time with a GCC plugin, do cool things with libclang, etc. Writing project-specific compiler plugins is unusual but not totally unheard of: Linux has a couple, for instance.
didibus 6y ago
Ya, OP is underestimating Lisp macros, the biggest of which is that Lisps tend to bundle their compilers within their runtime, so macros can actually expand at runtime, since compilation happens at runtime. The other of which is that they are so easy to write, that they just become another tool you use on a constant basis, just like you'd write a function, you write a macro, no big deal. I don't know that most Rust users have busted out a Rust macro or ever will. And one more of which is that macros are so well integrated, the languages themselves are implemented almost entirely with them. The number of compiler forms you need is very small. I think Common Lisp has like 30 compiler forms, and Clojure like 20, Scheme must be even less. That's all you need. This is why Clojure has a JavaScript, C#, Erlang, C++ and Go dialect as well as the default Java one, because you don't have that much work to do in the compiler, everything else just re-use the macros. I'll give in to Elixir, whose macros are pretty good, and for which I like the language, obviously, since it's like a Clojure with a different syntax and Beam instead of Java :p. Still would have preferred they'd just go with a full Lisp syntax and macro system, but oh well, a Lispyfied Ruby shall do. But ya, most other languages, even those trying to have more macro support like Nim, Rust, Julia, don't fully approach Lisp macros, even if some gets pretty close, like Elixir. Also, I don't know if comparing other niche languages with a niche language is a very good overall comparison.
- eigenspace 6y ago
  I'd say Julia's macros are basically at a lisp level. The main difference between Julia and lisp macros is that julia has more syntactic forms so macro writing has some extra cognitive overhead.