A road to Lisp: Why Lisp • Hacker News Board

Re: A road to Lisp: Why Lisp

#181

Post by Pay08 » Fri, Jul 10, 2026, 9:16 AM UTC

gf000 wrote: post #164

throwaway81523 wrote: post #157

Earlier quoted context omitted.

> If you squint enough, JS is a lisp.. Yes, that is true. I'm not big on the idea that Lisp is defined by parentheses. The implementation strategies are another way to look at it. That doesn't capture it either, but it's an angle to try.

So then what it is? Because otherwise it's a magical nothing-term to which everything lisp people like applies, but no criticism can ever reach it because "that's not really lisp, see it's different in this other implementation"

In my mind, it's 2 distinct criteria: interactivity and the manipulation of symbols (whether those are implemented as symbols or identifiers doesn't really matter). I don't know about Erlang, but from the admittedly little JS I've written, I believe it achieves both criteria, even if it's worse at them than a "proper" Lisp.

Re: A road to Lisp: Why Lisp

#182

Post by solumunus » Fri, Jul 10, 2026, 9:21 AM UTC

GMoromisato wrote: post #70

patrickmay wrote: post #57

Earlier quoted context omitted.

I like your metaphor but I'd argue that trusting programmers with power is the Light Side. Relevant PG: https://paulgraham.com/langdes.html

That's a great essay--thanks. And you have a good point. Maybe it's a weakness in the metaphor if one can see it either way. I fundamentally believe that there is no perfect language, instead one merely chooses a set of trade-offs. What's interesting about Lisp is that it is simultaneously well-respected and yet not widely used in productions (compared to C, C++, Python, JavaScript, and even Rust). It's almost like L…

I think it’s just that the syntax is more difficult to grok. When I first saw code (PHP and JS) it was fairly easy to read and figure out what was going on. I’m now experienced but I’ve never tried Lisp, but reading Lisp code takes considerably more effort than when I first saw the PHP/JS. I’m sure with very little experience it becomes just as easy, but to the novel eye I think it’s simply less intuitive to reason about.

Re: A road to Lisp: Why Lisp

#183

Post by __patchbit__ » Fri, Jul 10, 2026, 9:33 AM UTC

deterministic wrote: post #139

frwrfwrfeefwf wrote: post #96

[dead]

I would be very interest in seeing how "getting lisp" enables you to write software that is more successful than the C and C++ software that runs the world. Perhaps you have written software in Lisp demonstrating this? Something you can show us?

The reference text on time keeping used to be implemented in Lisp.

Alan Kay says a lot of problems with C/C++ go away when using the higher math more easily expressible in Lisp and like minded languages.

Jürgen Schmidhuber says the problem with computers from a mathematician's point of view are the numbers.

Re: A road to Lisp: Why Lisp

#184

Post by _ph_ » Fri, Jul 10, 2026, 9:38 AM UTC

peter_retief wrote: post #143

The real test of a programming language is its readabilty. I looked at lisp many times and it just doesn't do it for me.

That might be, on the other side, I consider Lisp highly readable, but quite a few modern languages quite unreadable. For example parsing type signatures with a complex syntax.

Any style of writing you are not familiar with will require a lot of training. Try reading anything written in the Greek alphabet for example.

Re: A road to Lisp: Why Lisp

#185

Post by _ph_ » Fri, Jul 10, 2026, 9:44 AM 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?

I think the best explanation, how Lisp macros are different from most other macro system is, that a Lisp macro is a function executed during compilation. It gets fed the parameters passed to it in literal form and then computes the source to actually compile by the compiler.

The power of this is that this function is also written in plain Lisp and it also sees all definition already existing in your Lisp image. Also, it is completely unlimited in power. So while being run, or as it is called "during macro expansion" the function could google for one of the things passed and use the result to create the output. Of course, this is not a practical example, but shows how flexible the system is.

Re: A road to Lisp: Why Lisp

#186

Post by gf000 » Fri, Jul 10, 2026, 10:10 AM UTC

sdfsfdsdfs3d wrote: post #180

gf000 wrote: post #148

Earlier quoted context omitted.

This is the "fallacy by Turing completeness". Sure, and you may as well write full systems in Minecraft and create your own type system inside and whatnot. Macros can make some small specific uses safe, indeed. But they are not comparable to languages with type systems where everything is type safe, unless you literally have written a new type system and compiler to begin with. Which is trivially true in every other…

I have no horses in this race and I'm sorry if I misunderstand but I don't think he means to say Lisp is by nature superior to say Haskell. I take it as a statement on the generality inherent in its design. It is by its very nature very low on restrictions. Which is to say your freedom of expression is very nearly as complete as it'll ever be. Sure you can beat Minecraft into Lisp and then Lisp into Haskell - as Turi…

My issue is that a language is just as much about what it disallows, as much as about what it allows.

It's absolutely trivial to allow everything, you just have to make a Turing-complete extension either by design or accidentally.

It's much much harder to carefully choose more limiting primitives that only allow you to build stuff that keep certain important properties about them. You can't subtract stuff after the fact.

E.g. something like rust's borrow checker could not be realistically implemented as "a lisp" macro (what does lisp even mean in this case). For that to work you would literally build a rust compiler over s-expressions and you might as well leave off the s-expressions at that point.

And every part that was not compiled by that macro or whatever would be unsafe and could not interact with the "rust-lisp" compiled parts, as you can no longer assert anything about them (there is nothing mandating the usual single writer, xor multiple read-only references laws)

Re: A road to Lisp: Why Lisp

#187

Post by Charon77 » Fri, Jul 10, 2026, 10:12 AM UTC

I really love the idea of lisp but feels like the learning curve is steep. Sure you can learn basic lisp in an hour or so but then? You need to learn emacs, all of the plugins, module systems.

Maybe I just don't know where to start.

Re: A road to Lisp: Why Lisp

#188

Post by sdevonoes » Fri, Jul 10, 2026, 10:15 AM UTC

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…

But there are two types of “programming”: 1) programming per se (just you writing code for fun and perhaps building your own tools) and 2) a team of people with real-world constraints writing software for others for revenue

It’s clear why it feels so good to use something like Lisp for personal projects. It’s also clear why the vast majority of companies don’t use it

Re: A road to Lisp: Why Lisp

#189

Post by davidpapermill » Fri, Jul 10, 2026, 10:24 AM UTC

This is well-written.

I always thought that the "answer" to programming would be that one day everyone would use Lisp and with awesome tooling and libraries things would be wonderful. In fact, my plan for retirement was to build high-quality libraries for a Lisp language to accelerate this process.

Does the rise of AI bring an end to this dream? Is that, once again, we have solved the problem by adding more cruft? Rather than a superintelligent AI writing in the best programming language available, we're going to just spam lots of Python code until it works?

Does this matter? I don't know, I just wanted a world of elegance.

Re: A road to Lisp: Why Lisp

#190

Post by astrobe_ » Fri, Jul 10, 2026, 10:27 AM UTC

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…

I'll paraphrase someone who commented on HN once (about dynamic vs static typing, IIRC): permissive languages are enablers for solo programmers, but you need more restrictive languages for team programming.

This matches my experience because you don't chose who you work with. Skill level is uneven among the team. Less skilled co-workers will make mistakes that will have more consequences when the language is more permissive.

That's one of the reasons you want code reviews, but then you convert your skilled programmers to teachers. This is not a good trade, because the time they spend improving the skills of other programmers is partially wasted because programmers are free to come and go. AI could change this picture.

The name of the game is therefore to keep your teams small and skilled, but this is can be difficult because of typical company politics - e.g. "bus factor" considerations, shortening time-to-market is often achieved by adding more programmers.