Why Lisp? (2015)

> Shared understanding is important for building and maintaining software.

I think this is where Go (the language) really shines. Go is "boring" -- there are no macros, no operator overloading, no default arguments, none of that sort of thing. But if your goal is shared understanding, "boring" is a compliment. "Boring" means "after using the language for a few years, I can be confident that I will never be surprised by a piece of Go code again." (This has been true for me for at least 4 years.)

In the same vein, Go famously doesn't support user-defined generics; the only generics it has are reified "builtins," baked into the language. People gripe about that, but the upshot is that every Go programmer understands the semantics of those builtin functions. They're Schelling points! When user-defined generics are added in the next version of Go, I worry that we'll lose some shared understanding. It will be a subtle shift, but the language will feel a bit less "cozy." :/

This is no different from any other language lacking libraries, except that with Lisp you're using a proven, powerful language. And if you want libraries there's a python bridge and a whole CL on the JVM with interop.

> That article partially validates my idea on why some people think that Lisp is such a force multiplier. The idea would be that compilers are one of the most important tool productivity-wise, and that Lisp allows you write your compilers yourself

This is a huge selling point for me personally. lisps allows you to have a solution AND its compiler in lisp, without a need for another language. As far as I know Common Lisp is the only industrial strength dialect of lisp to allow this, and with an unmatched interactive development environment

> Shared understanding is important for building and maintaining software. You could also argue that it's important to make programmers more replaceable

in a business sense, if i wanted to hire for a large team of 'developers' i would hire for java / python / js. if i wanted to hire for a small team of 'hackers' i would hire for common lisp / haskell

Coffeescript, Babel and Typescript are not macros.

> ... it goes well beyond any Lisp/Scheme (and many modern languages) in terms of having a practical but expansive ecosystem with a strong set of idiomatic conventions.

Does it, really?? Common Lisp is an ANSI Standard, I don't know how you get a more "strong set of idiomatic conventions" than that. And it's been "done" for 20 years now! People continue to use it just as it is, and there's very little pressure to change it because it simply works!

You're trying to justify a new wave of "modern" languages with a very weak argument... just call it for what it is: you want "cool", hyped languages to succeed despite the fact they offer nothing that the CL standard did not 20 years ago.

I'm not exactly a Lisp fan (I'm firmly in the statically typed camp), but this is a weak argument. Common Lisp specifically is one of the most cohesive experiences one can find out there, the language has had a long time to mature, it's ANSI standardized and the ecosystem is largely built on top of that cohesive base.

can you write compilers in elixir ? how does its interactive programming compare to that of Lisp ?

mmh Elixir definitely has its gems and I need to try it for real. Where I can see it's lacking: no compile-time type warnings (unless you're using a new language on top or using a third-party library, but then we should compare more thoroughly), no compilation with a keystroke function per function. No static executable (even though deployment options are getting better in Elixir (we had to wait though)). Some compilation times, when you change one file and Elixir needs to compile a dozen. We are not inside a live image. I tried Alchemist mode for Emacs: no function signature? No "eval this expression"? Can you switch projects from inside a REPL, or you have to start a new one? No cross-reference capacities built-in? (who calls this function, this macro, who sets, etc) No inspect? No trace? No interactive debugger and no stepper? If only available with LSP and VSCode, then it's strictly inferior. Elixir is less performant in crunching numbers. Less to no GUI framework choice (WxWidgets). No industry-grade theorem prover? (ACL2) Unfit for quantum computing? Unable to program Intel chips? (Barefoot Networks) No computer algebra system? No music composition suite (Opus Modus)?

CL's ecosystem might be better than one thinks: https://github.com/CodyReichert/awesome-cl & https://lisp-journey.gitlab.io/blog/state-of-the-common-lisp...

There was one cohesive tribe in the 00s centered around the quasi-annual European Common Lisp Meeting. I miss that and wish I could find the same thing again now. Maybe it exists somewhere online?

The ELS community is still going strong. They have done a great job with continuity and moving forwards. That's a related but different tribe though.

The thing about Common Lisp is, code doesn't rot. It doesn't matter if CL code is 5 years old or 30, it runs. I have yet to see even one ounce of bit rot. CL code is as eternal as solid gold, honestly. And sometimes, yes, there's a few ways your code will fail to run, mostly because you're shooting yourself in the foot (eg starting slime in a different directory than what you're meant to).

Versus Python, I didn't even get to use Python 2 before I started getting nagged and harangued by various exceptions in the terminal about how I had to migrate to Python 3.

And it depends what you're doing with CL, how well it works for you. As an algorithm designer, I use literally no libraries. I don't glue anything to anything. I just use the batteries that come included with Common Lisp (SBCL is great), forget about connecting to the internet, forget I/O, forget graphics and GUIs and OOP, and just focus on coming up with as many ideas as I can per minute, until I crack the algorithmic problem. Just with the austere tools that come included in SBCL: xor (#'logxor), popcount (#'logcount), #'sort, #'svref, #'pop, #'push, #'make-array, #'dotimes, 'lambda, 'labels, 'let, 'do, the basics.

There are three commercial lisp companies that continue to exist selling CL platforms. They exist despite SBCL being faster. They even make stuff like tools to build iOS and Android apps in CL. They didn't invest the money building that that out for no reason.

The companies that use lisp don't tend to talk about it. For example, a company I worked for only talked about their Ruby/rails and javascript stuff publicly. It was only after I hired that I found out that the mission-critical core software was written in Common Lisp.

also me o/ and https://github.com/azzamsa/awesome-lisp-companies/ (but I understand your feeling^^)

Probably because if you aren't paying that much attention to Lisp software, the almost 40 years of writing about Common Lisp will surface more so than the code and their authors. And a lot of code (millions of lines) isn't open and a lot is probably lost to time. Though it seems like you know about a handful of the current era superstars, yet you're forgetting or don't know about other superstars. And there's a long tail of less prolific developers. But sure, just comparing the open source stuff in Quicklisp, there's only about 2500 projects (vs 335k projects on PyPI), and the frequency of new stuff regardless of whether it shows up or not in quicklisp is slow enough that you could follow https://twitter.com/NewLispRepos/ and not have your timeline overwhelmed.

i am new to lisp in general and common lisp in particular. i will tell you the key reason why i will take my time to promote it on hn. for years i had large misconceptions about lisp: it is slow (in my case for numerical work), it is an academic language, the syntax is ugly unnatural and annoying. it was only by chance that i was (quite happily) proven completely wrong. so my rationale is that if there are people who are like i was then i will be happy to provide information about common lisp and perhaps something useful might come out of it

That is because it is a little secret. It is a secret hidden in the open.

We program in C#, we program in swift, C and C++, but we continue using so much Lisp as I did 20 years ago or way more.

With Lisp you don't need to write only Lisp, you can write swift or any other language in Lisp, as we do.

When people ask what programming languages we use, even competitors, we just tell them. They don't listen.

They just can't really understand. They probably believe we use Lisp because we depend on obsolete technology because they are under the influence. The influence of snake oil salesman that want to sell them their new shiny language.

For them anything new is shiny and old means dusty because things degrade over time, but computer languages do not.

If competitors can't "get it", much better for us. They probably believe that we try to deceive them and that in reality we are using this new language-paradigm of the week that solves all the problems. Let them.

Lisp guys have nothing to sell you but probably the software they create. And if they have a powerful tool, they are not that interested on you knowing their secret.

Lisp code is much terser than prose.

Here are over 16k repositories. They're certainly not all by 15 people.

https://github.com/search?q=language%3A%22Common+Lisp%22&typ...

Simple digestable examples that show off power is kind of a cart before horse situation. However, I will try to feed your curiosity.

One simple example I can describe is from the book Practical Common Lisp and it is talked about to some degree in the SICP videos. The idea of the environment being captured as well as what it points to is a big idea. At the risk of not getting it explained 100% to everyone's satisfaction I would suggest reading about it.

I also would suggest the problem of the N queens board. It is a pretty good starting point into how this problem can be solved in lisp. I suggest the MIT SICP lecture on it because it is well paced and interesting. Also it shows off some, for the time, advanced language features.

Another good read is Norvig's PAIP book that you can read on Github. Lots of problems you can jump to with pretty good explanation in my opinion.

I'm sure there are more interesting things I could point to. However, I still consider a read of Practical Common Lisp a good starting point. The book is fairly well paced and not bogged down with learn all the language first-isms. Also, the SICP videos are pretty good to watch. I hope these points are helpful to you.

I don't know much about Lisp. But you do realize you're asking sort of the following right?

Roman: what's so amazing about the decimal system? I can do addition just fine with X + X = XX.

Modern human: Well... you can do negative numbers easily, irrational numbers, you can show zero easily.

Roman: bah! I don't know what you're talking about. Half those numbers don't even exist.

Mathematician: actually have you heard about complex numbers?

The point is: you have to learn a new way of thinking compared to procedural/OOP style programming. And it might be the case that the problems it solves are not practical for your use-case.

I tell you, as a non-Lisp programmer, what I find amazing about Lisp. Disclaimer: I may be partially or completely wrong. I'm really not the one who should be writing this, but since our knowledge of Lisp isn't that far apart, I might be able to empathize with your perspective a bit more since I have been in it.

* Your code is the abstract syntax tree! Don't know what an abstract syntax tree is? It's a data structure that compilers use in order to generate code. In normal languages you have to first parse the language, compile it to the abstract syntax tree and then generate machine code from it. However, in the case of Lisp, it's already there. So this means that you can write compiler-esque programs much easier.

* One of the nice things that a direct AST provides that it allows partial live reloading of code. Imagine this:

``` myAge = 17 if (myAge >= 18) { print("Nice!") } else { print("Hello youngster!") } ```

With Lisp, you can basically swap out the first print function for another function while the program keeps running.

To be fair, other non-Lisp languages have come a long way. Still, I'll offer a few things that might pique your interest.

For a while in the development of Common Lisp, a sort of joke acceptance test for implementations was in three parts: 1) you type T and enter into the REPL, it responds T 2) you define the factorial function and calculate (/ (factorial 1000) (factorial 999)) and it responds 1000 3) You try (atanh -2) and if it returns a complex number it passes (extra credit for the correct complex number). Lisp has a great numerical tower. Besides being able to deal with huge and complex numbers, you also have convenient syntax for specifying numbers in base 2 and 16, and you can do things like bitwise operations on bit-vectors:

    (bit-and #*00110100
             #*10101010)
    -------> #*00100000

For macros, there's a lot of cool ones. Unlike C macros that just do string substitution, Lisp macros let you use the full Lisp language to write code that does something with expressions passed to the macro. A nifty one that's part of basically every implementation with uiop:nest is described here https://fare.livejournal.com/189741.html The problem it solves is that sometimes in Lisp you'll have a lot of nested forms, and your code begins to attack the bottom right corner of your screen. e.g.

    (multiple-value-bind (a1 b1 p1) (foo1)
      (with-open-file (f1 p1 ...)
        (let ((x1 (read f1)))
          (when x1
            (multiple-value-bind (a2 b2 p2) (foo2)
    ...

The macro lets you rewrite that as

    (nest
     (multiple-value-bind (a1 b1 p1) (foo1))
     (with-open-file (f1 p1 ...))
     (let ((x1 (read f1))))
     (when x1)
     (multiple-value-bind (a2 b2 p2) (foo2))
    ...

The macro definition is really straightforward:

    (defmacro nest (&rest r)
     (reduce (lambda (o i) `(,@o ,i)) r :from-end t))

(The list of forms are passed, unevaluated and at compile time, to nest, which rewrites them using a right fold to nest things properly.)

Somewhat similar is the arrow macro that Clojure popularized, which lets you get rid of (deep (nesting (like (this ...)))) where you have to remember evaluation order is inside-out and replace it with a flatter (-> (this ...) like nesting deep). Or (loop (print (eval (read)))) -- which will indeed give you a primitive REPL within Lisp -- with the more readable (-> read eval print loop). Its implementation is also easy -- many macros are easy to write because Lisp's source code is itself a list data structure for which you can write code to process and manipulate just like any other lists.

Another cool macro that's been around since 1993 is https://github.com/quil-lang/cmu-infix which lets you write math in infix style, e.g. #I( C[i, k] += A[i, j] * B[j, k] ) where A, B, and C are all matrices represented as 2D arrays. It's a lot more complicated than the nest macro, though.

There are some other things that still make Lisp great in comparison to other languages, but they don't exactly have one-line code examples like [::-1] and so I'll just describe them qualitatively. Common Lisp has CLOS, the first standardized OOP system. It's a lot more powerful than C++'s system. It differs from many systems in that classes and methods are separate; among other things this gives you multiple dispatch (you can define polymorphic methods that don't just dispatch to different code depending on the first argument (the explicit 'self' in Python, implicit 'this' in other langs) but all arguments). One thing it can be useful for is to get rid of many laborious uses of the Builder and Visitor patterns. e.g. the need for double dispatch is a common reason to use the Visitor pattern, but in Lisp there's no need. CLOS also does "method combination", which lets you define :before, :after, and :around methods that operate implicitly before/after/around a call. This gets rid of the Observer pattern, supports design-by-contract, and jives well with multiple inheritance in that you can create "mixins" that classes can "inherit" from with the only behavior being some :before/:after methods. (e.g. logging, or cleaning up resources, or validation.)

Everything is truly dynamic -- an object can even change its type at runtime, which may be an acceptable solution to the circle-ellipse problem, or just super convenient while developing. More fundamentally, "compile" is a built-in function, not something you have to do with a separate program. "Disassemble" is built-in, too, so you can see what the compiler is doing and how optimized something is. You have full flexibility to define and redefine how your program works as it's running, no need to restart and lose state if you don't want to. Besides being killer for development (and all the differences in development experience comprise a big part of why I still think Lisp is great compared to non-Lisp), this gives you a powerful way to do production debugging and hot-fixing too -- a footgun you might not necessarily want most of the time, but you don't have to do anything special for it when you do want it. It can be very useful, e.g. if you've got a spacecraft 100 million miles from Earth https://flownet.com/gat/jpl-lisp.html I've also put some hobby stuff on a server, just deployed as a single binary, but built so that if I want to change it, I can either stop it, replace the binary, and start again, or just SSH in and with SSH forwarding connect to the live program with my editor and load the new code changes just like I would when developing locally, and thus have zero downtime.

Lastly, Lisp's solution to error handling goes beyond traditional exception handling. Again this ties into the development experience -- you have some compile-time warnings depending on the implementation (e.g. typos, undefined functions, bad types) but you'll hit runtime errors eventually, Lisp provides the condition system to help deal with them. It can be used for signaling non-errors, which has its uses, but what you'll see first are probably unhandled errors. By default one will drop you into a debugger where the error occurred, the stack isn't immediately unwound. Here you can do whatever -- inspect/change variables on different stack frame levels, recompile code if there's a way to fix things, restart computation at a specific frame... You'll also be given the option of "restarts", which might include just an "abort" that unwinds to the top level (possibly ending a thread) but can include custom actions as well that could resolve the error in different ways. For example, if you're parsing a CSV file and hit a value that is wrong somehow (empty, bad type, illegal value, bad word, whatever), your restarts might be to provide your own value or some default value (which will be used, and the computation resumes to parse the next value in the row), or skip the whole row (moving on to the next one), or skip the whole file (moving on to the next file, or finishing). Again this can be very useful while debugging, but in production you can either program in default resolutions (and a catch-all handler that logs unhandled errors, as usual) or give the choice to the user (in a friendlier way than exposing the debugger if you please).

Given that it's a 'new paradigm' and enhances 'intuition', it's a bit hard to show simple examples which demonstrate that. You'll have to put in the work.

Will you be able to understand how to play the guitar if I show you a passage from a song ? You can play it with any other instrument, so it still won't be motivating enough for you to put in the time and effort required to learn it.

If I were to take you to a Led Zeppelin concert to see Jimmy Page playing, that still might not be motivation enough for you to pick up the guitar, but you'll be able to better understand what it can do to people :).

Back to LISP - it's a tool. The difference between other tools, is that you can program it too. The power lies in its simplicity and your ability to build programs iteratively while running them.

> I would appreciate a few concrete examples (very much like [::-1] and 100*100) that would allow me to get what LISP really is about.

You mean like (reverse "asd") and (* 10000 10000)? That's not really what gives you an impression of Lisp, rather a bit of syntax ([::-1], the paragon of readability) and large integers. :P

This article might help: https://www.defmacro.org/ramblings/lisp.html

Also, if you really want to see what it's about you can read SICP: https://xuanji.appspot.com/isicp/ https://github.com/sarabander/sicp

do you still use lisp ? i noticed a while ago you were working on a cryptographic project and i am sure you considered common lisp for this, but didn't pick it. is there a reason for this ?

Performance:

Getting Lisp to run as fast as C takes major effort when at all possible.

Resources:

Lisp needs a lot of space to do it's thing; and while it's certainly possible to downsize it, you're left with something that's not really Lisp anymore.

Ecosystem:

Finding solid libraries is tricky since it's not very popular professionally.

Power:

Unleashing the full power of Lisp in a diverse team is a recipe for an adventure, if not disaster.

no popularity, no money.

Can I be extremely shallow? Because the language feels like it's from the 60s. Like writing Fortran or Ada or Algol in 2021. C is timeless, it doesn't count.

I love lisps, but Racket, for example, feels more modern than Common Lisp to me. And for shallow people like me, feel and ergonomics are very important when writing code.

I cut my teeth on Lisp, but I've found that happiness comes from compile time guarantees. Maybe those two things aren't mutually exclusive, but a thoroughly robust type system seems like a big ask in such a dynamic language. None of the solutions I've encountered have satisfied me, but in fairness I haven't looked that hard.

I look at it as an intersection between the feature sets of Common Lisp, Clojure, Scheme, etc. In other words - the most basic features of these languages that are common - S-expressions, data is code is data, REPL-driven development, etc

> It's like mentionning JS in a conversation about C

It's not. It's like mentioning C++ in a conversation about OOP which is why Lisp is the appropriate umbrella term. For me, CL means Common Lisp.

I'd say the "python of lisp" is definitely racket.

Beginner friendly, lots of batteries included, large community with lots of libraries.

Here's an example of a simple webserver using the standard library: https://docs.racket-lang.org/web-server/run.html#%28part._se...

I'm also a fan of the first tutorial on the site. Instead of the boring stuff like hello world, 2+2, print your name etc, they use a built in library for drawing shapes to the console, and learn how to build up procedures for drawing more complex objects.

It feels like learning to code with logo (which they also have a clone built in of https://docs.racket-lang.org/logo/index.html)

All the good stuff said, I've never used it for system plumbing scripts like I do with python. I'd imagine it's worse for that due to the sheer popularity python has.

https://racket-lang.org/

I think babashka [1] is what you're looking for. It's a limited Clojure interpreter suitable for anything a bash script is suitable for.

1: https://github.com/babashka/babashka

Clojure through Babashka[0]. It's great for small tasks not related to your favorite editor. I use it for most of my scripting except for the really easy things in bash.

[0] https://babashka.org/

I’ve been having decent luck with babashka and more recently with nbb which is from the same developer but an npm install to start using it.

They both work really well for little scripts and tools where i found clojure startup time annoying.

Why wouldn't you use Emacs Lisp to automate small tasks? I think it's great for that purpose, it's usually pretty easy to give a utility a very comfortable user interface in Emacs.

Definitely Common Lisp. Instant startup time (load all your dependencies and then dump a new SBCL compiler with ‘save-lisp-and-die’), great emacs support, a mature ecosystem, and fast.

Clojure is great if you don’t care about the startup time, as it has good emacs support, and you can fall back on the JVM ecosystem. It’s the most concise of all the lisps I have tried, but also a tad opinionated.

I haven't tried it, but there is Janet (https://janet-lang.org/) that seems pretty well suited for building small scripts. It was submitted a few times recently here on HN.

Chicken Scheme is probably a nice middle-of-the-road scheme to try. It's "eggs" offer a lot of the functionality you'd want, the FFI for calling C is decent, and the documentation isn't bad.

If I may be so bold as to recommend my in-progress Bel implementation: https://github.com/masak/bel

Caveat: I'm still working towards being able to recommend Bel _unconditionally_, not just for small programs. Right now you'll experience unreasonable slowness, terse/uninformative error messages, and missing documentation -- probably in that order. All of those are being addressed. But already today, it's fun to play with.

Emacs Lisp is better than fine. You get a powerful Lisp (with a lot of goodies from CL) that is both portable and ultra-stable whilst having a self-contained VM and an enormous library of code available (Emacs) on every system imaginable.

Here is an example of scripting a small task:

https://gist.github.com/atomontage/64b767731b5896f1c6113adb9...

If you're already familiar with Python libraries, check out Hissp (https://github.com/gilch/hissp), which compiles to Python expressions.

Yes, but read the post anyway.

Plus, that can be in addition to having JSON too.

  This is the TXR Lisp interactive listener of TXR 271.
  Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
  1> '#J{"foo":[1,2,3,"bar"]}
  #J{"foo":[1,2,3,"bar"]}

What is that literal syntax?

  2> (typeof '#J{"foo":[1,2,3,"bar"]})
  cons

cons-cell based object under the hood.

  3> (car '#J{"foo":[1,2,3,"bar"]})
  json
  4> (cadr '#J{"foo":[1,2,3,"bar"]})
  quote

It has a (json quote ...) structure.

  5> (caddr '#J{"foo":[1,2,3,"bar"]})
  #H(() ("foo" #(1.0 2.0 3.0 "bar")))

Followed by a hash table object. We can convert that to a vector to see it all:

  6> (vec-list '#J{"foo":[1,2,3,"bar"]})
  #(json quote #H(() ("foo" #(1.0 2.0 3.0 "bar"))))

Now actually eval it instead of quoting

  7> #J{"foo":[1,2,3,"bar"]}
  #H(() ("foo" #(1.0 2.0 3.0 "bar")))

The embedded hash table denoted by the literal is regurgitated.

We can quasiquote JSON:

  ;; ^ is quasiquote in this dialect not `
  1> ^(,(+ 2 2) ,(list 1 2 3))
  (4 (1 2 3))

  ;; cannot use , in JSON for unquoting, so ~ is used:
  2> ^#J["foo", ~(+ 2 2.0)]
  #J["foo",4]

The quasiquote can be pattern-matched:

  3> (match ^#J[~x, ~y] #(1.0 "foo") (list x y))
  (1.0 "foo")

Or, using JSON syntax on the right side, which produces the same vector:

  4> (match ^#J[~x, ~y] #J[1.0, "foo"] (list x y))
  (1.0 "foo")

Exactly - it's not about whether it's possible to represent code as data (gcc is written in C, after all), it's about how easy it is. That's why Rust macros still don't come close to Lisp ones.

Lisp compiles to native code, TCL is forever parsing the strings it passes around.

Tcl is quite nice, having been part of a product similar to AOL Server, I never got the hype around Rails.

> If you look at mathematical notation, written with quill pens and paper…it’s even more concise.

Yes, but now mathematics publishing predominantly uses a typewriter-era language for achieving it:

  \documentclass{article}
  \usepackage{amsmath}
  \begin{document}

  \[
  M=
    \begin{bmatrix}
      1 & 2 & 3 & 4 & 5 \\
      3 & 4 & 5 & 6 & 7
    \end{bmatrix}
  \]

  \end{document}

Most programming takes place with what is more or less typewriting.

I disagree. I think a way to summarize this article is that the popular languages (Algol/C family) are like Roman numerals, and Lisp is like Arabic: it composes better. It's a powerful, qualitative difference.

Roman numerals were based on lines and slashes? I mean, for one, five, and ten, sure. Fifty? Maybe. Beyond that? Not so much.

It's funny because I consider other languages like roman numerals, unhomogeneous bunch of constructs that don't work well with themselves, meanwhile lisp is an infinite tower.

Now maybe there are better notations though. I'm all ears.

Lips dates back to Lambda calculus and the Church notation.

Far from a typewriter.