A road to Lisp: Why Lisp • Hacker News Board

Re: A road to Lisp: Why Lisp

#71

Post by aidenn0 » Thu, Jul 09, 2026, 9:35 PM UTC

sroerick wrote: post #4

I must admit - I still don't understand macros. I get that they're code that's generated at compile time. But I don't understand how that's different than a function which evaluates other functions. I guess the latter would actually be evaluated at runtime? I think I get it conceptually but I'm not sure I have the muscle memory to reach for them. Anybody here have an "ah hah!" Moment with macros?

Many problems can be solved with either macros or higher-order-functions. The advantage of macros is two-fold (macros also have disadvantages, and Lisp allows you to use either solution; deciding which to use is often a matter of taste):

1. Syntax can be more familiar

2. Performance (to the extent that there is overhead for functions-calling-functions).

For example, let's consider a hypothetical lispy language that doesn't have a short-circuiting "and" operator. Macros would let you implement something to used like this:

  (and (foo x) (bar y))

Higher order functions would require you to do something more like:

  (and (lambda () (foo x) (lambda () (bar y))

More noise, and more work for the optimizer (or in the worst-case, more work at run-time). Languages that rely heavily on higher-order-functions will tend to have terser syntax for anonymous functions. For example in javascript you might do:

  and(()=>foo(x), ()=>bar(y))

Re: A road to Lisp: Why Lisp

#72

Post by AnimalMuppet » Thu, Jul 09, 2026, 9:38 PM UTC

dang wrote: post #54

sph wrote: post #36

Earlier quoted context omitted.

Yeah but apart from SBCL, Viaweb, Hacker News, Emacs, Clojure, Scheme, Racket, garbage collection, macros, homoiconicity, the REPL, S-expressions, symbolic computation, what has Lisp ever done for us?

...booleans, conditional expressions, first-class functions, lambdas, closures, eval...

Booleans? I think some guy named Boole might have prior art...

(Yeah, OK, he didn't have a programming language...)

Re: A road to Lisp: Why Lisp

#73

Post by iLemming » Thu, Jul 09, 2026, 9:38 PM UTC

veqq wrote: post #66

jolt42 wrote: post #20

Earlier quoted context omitted.

But with Clojure and immutable by default, hot reload is a real thing, it sounds like not just on JVM but even among lisps.

Clojure barely let you import packages without restarting the JVM recently in its life.

But it has this capability and had it for a while. What's your complain?

Re: A road to Lisp: Why Lisp

#74

Post by metroholografix » Thu, Jul 09, 2026, 9:38 PM UTC

malkia wrote: post #25

I've been wondering - Is lisp (common lisp, clojure, scheme) easier for iterative work with LLMs?

Current SOTA models work great with Emacs Lisp and Common Lisp. Giving access to the REPL enables them to do an amazing job but they still work well with Unix input/output static code processing paradigm.

Re: A road to Lisp: Why Lisp

#75

Post by lenkite » Thu, Jul 09, 2026, 9:43 PM UTC

abetusk wrote: post #32

There are many articles extolling the virtues of Lisp. I would like to see some articles that have a level-headed criticisms or critique of Lisp, it's ideas and it's place in the ecosystem of languages. Articles like this, and the PG articles it references, amount to "if you know, you know". I understand the appeal and I understand the explicit and implicit arguments this article is making. Computer programming has m…

> I would like to see some articles that have a level-headed criticisms or critique of Lisp, it's ideas and it's place in the ecosystem of languages.

Standardized Concurrency is basic table-stakes for a language today. CL does not have a standardized async/await or concurrency model. The standard hasn't been updated since 1995 so it will never happen.

Re: A road to Lisp: Why Lisp

#76

Post by Jtsummers » Thu, Jul 09, 2026, 9:51 PM UTC

lenkite wrote: post #75

abetusk wrote: post #32

There are many articles extolling the virtues of Lisp. I would like to see some articles that have a level-headed criticisms or critique of Lisp, it's ideas and it's place in the ecosystem of languages. Articles like this, and the PG articles it references, amount to "if you know, you know". I understand the appeal and I understand the explicit and implicit arguments this article is making. Computer programming has m…

> I would like to see some articles that have a level-headed criticisms or critique of Lisp, it's ideas and it's place in the ecosystem of languages. Standardized Concurrency is basic table-stakes for a language today. CL does not have a standardized async/await or concurrency model. The standard hasn't been updated since 1995 so it will never happen.

And it remains in a state of almost getting to the point of generic collections (like C++, Clojure, many others) using the standard functions, but not quite getting there. There are functions (not generic functions) which operate on sequences, but no standard way to extend what types are considered sequences (as one example). It makes sense that the 1995 version of the spec would be incremental, but without a further development (or consensus amongst the implementations if no official standard) it's difficult to continue moving forward to make better use of the language's generic function capabilities.

That's where Clojure, Julia, and many others have advanced beyond what CL (by the standard) provides. The language needed at least one or two more standards to drive those features forward, but never got them.

Re: A road to Lisp: Why Lisp

#77

Post by DonaldFisk » Thu, Jul 09, 2026, 9:53 PM UTC

busfahrer wrote: post #28

GMoromisato wrote: post #22

Programming is in tension between the Light Side and the Dark Side. The Light Side is about preventing the programmer from making mistakes: Get rid of go-tos! Add static types! Do not allow a bug to be expressible. The Dark Side is about giving power to the programmer: Macros? Obviously. Operator overloading? Self-modifying code? Multi-line reg-exps? Go to town! The Light Side knows programmers are flawed and imposes…

> Or maybe Lisp is so pure that it embodies both Light Side and Dark Side, like a god that spawned the programming universe. This isn't so far off, considering that some people consider the "Lisp in Lisp" bit from the 1.5 manual to be the "Maxwell's Equations in Software": https://michaelnielsen.org/ddi/lisp-as-the-maxwells-equation...

I have always assumed that Alan Kay compared Lisp to Maxwell's Equations because of the similarity between the interplay of eval and apply in Lisp on the one hand, and the interplay of the electric and magnetic fields in Maxwell's equations on the other.

Re: A road to Lisp: Why Lisp

#78

Post by chamomeal » Thu, Jul 09, 2026, 9:58 PM UTC

lenkite wrote: post #75

abetusk wrote: post #32

There are many articles extolling the virtues of Lisp. I would like to see some articles that have a level-headed criticisms or critique of Lisp, it's ideas and it's place in the ecosystem of languages. Articles like this, and the PG articles it references, amount to "if you know, you know". I understand the appeal and I understand the explicit and implicit arguments this article is making. Computer programming has m…

> I would like to see some articles that have a level-headed criticisms or critique of Lisp, it's ideas and it's place in the ecosystem of languages. Standardized Concurrency is basic table-stakes for a language today. CL does not have a standardized async/await or concurrency model. The standard hasn't been updated since 1995 so it will never happen.

CL may not but other lisps do. Clojure’s concurrency is just so hawt

Re: A road to Lisp: Why Lisp

#79

Post by BeetleB » Thu, Jul 09, 2026, 9:58 PM UTC

sroerick wrote: post #4

I must admit - I still don't understand macros. I get that they're code that's generated at compile time. But I don't understand how that's different than a function which evaluates other functions. I guess the latter would actually be evaluated at runtime? I think I get it conceptually but I'm not sure I have the muscle memory to reach for them. Anybody here have an "ah hah!" Moment with macros?

> But I don't understand how that's different than a function which evaluates other functions.

You want a function that takes in arguments, but does not evaluate the arguments when called. So:

   func(foobar(), foobar())

Normally, foobar() will be called twice - at the time of the call. With macro expansion, you can ensure that it's not the result of calling foobar that goes into the func, but this expression.

A canonical example is if you want to write an if/then/else function:

    if(condition, then_path, else_path)

It's quite possible that the else_path is invalid and will terminate the program if the condition is true. But if you wrote a function this way, it will evaluate both then_path and else_path - not something you want to do in a regular if expression!

Re: A road to Lisp: Why Lisp

#80

Post by munificent » Thu, Jul 09, 2026, 10:11 PM UTC

zbentley wrote: post #12

There are some truly powerful and unique things about Lisps, but I wish articles like this would stop including REPLs and hot-reloading. The former have been table stakes for interpreted languages (and some compiled ones!) for years, and the latter is neither unique nor particularly widely used (hot reloads have to tangle with state and patching, so resetting the world for ease of reasoning is considered a best pract…

> and the latter is neither unique nor particularly widely used (hot reloads have to tangle with state and patching, so resetting the world for ease of reasoning is considered a best practice for a reason).

For what it's worth, hot reload is very widely used in Dart/Flutter. When you are writing UI code using a reactive style framework where rendering the UI appears to be "generate a new UI from scratch on each frame", it's more straightforward to have an intuition about what does and doesn't get reloaded.

It's not perfect, of course. But it works really well for the kind of changes you make when iterating on a user experience.