> Rtml even depended heavily on keyword parameters, which up to that
time I had always considered one of the more dubious features of
Common Lisp. Because of the way Web-based software gets released,
you have to design the software so that it's easy to change. And
Rtml itself had to be easy to change, just like any other part of
the software. Most of the operators in Rtml were designed to take
keyword parameters, and what a help that turned out to be. If I
wanted to add another dimension to the behavior of one of the
operators, I could just add a new keyword parameter, and everyone's
existing templates would continue to work. A few of the Rtml
operators didn't take keyword parameters, because I didn't think
I'd ever need to change them, and almost every one I ended up
kicking myself about later. If I could go back and start over from
scratch, one of the things I'd change would be that I'd make every
Rtml operator take keyword parameters.
I like History but I'll comment about Lisp in web apps today, if I may. We have a choice of web servers and web libraries (https://github.com/CodyReichert/awesome-cl/#web-development), and we live in happy times where HTMX or Datastar are great fit for Lisp -as with any stack. See these Datastar examples built in CL: https://github.com/fsmunoz/datastar-cl I use and like the Mito ORM too, which comes with automatic migrations and, since last year, a composable query engine (SxQL).
Here you will find some screenshots of some of today's web applications built in CL: http://lisp-screenshots.org/ and here an opinionated tutorial: https://web-apps-in-lisp.github.io/ One example: ScreenShotBot https://screenshotbot.io/ a successful open-source product and company. It now replaced Facebook's automatic screenshot testing tool (source: their blog). So, web apps in Lisp are possible -with a right amount of learning time and elbow grease.
The incremental development and interactive top-level are still precious and unmatched.
The productivity high folks get from using tools like Claude Code are the same as what one gets from learning a Lisp and using something like Emacs as the editor.
There is obviously a difference in capability, but do the cost differences scale linearly?
Maybe when the party is over, the lost will yearn for the parentheses to get just a shadow of that high back.
I contributed to a contemporaneous large and complex system in Lisp (Scheme) that used most of those.
It was one of those things where 1-3 programmers, working with the right tools and thinking, could out-perform all competitors, no matter how much resources competitors threw at the problems. (I can't take credit for the initial architecture and implementation: that was all someone else.)
The system actually outlived Viaweb by decades, and I suspect still uses Scheme for a lot, especially for the necessarily complex backend.
(Half the problem for Scheme uptake was that most students only saw it school, as presented by a CS professor in an intro class, and then they did annoying homework, so they hoped never to use it again. They should've seen what we did with it, making it fly in ways that a CS professor wouldn't in first-year classes, compared to how it would've been done in other languages at the time.)
> One way we used macros was to generate Html. There is a very natural fit between macros and Html, because Html is a prefix notation like Lisp, and Html is recursive like Lisp. So we had macro calls within macro calls, generating the most complicated Html, and it was all still very manageable.
We just used lists and functions for HTML. And often with quasiquote, when we wanted to splice "dynamic" bits into a substantial chunk of "static".
I didn't try to use macros for HTML until a decade after this talk. I liked the simple DSL, and leaning on buffered I/O ports and string ports, but nobody else seemed to like it as much as I did (maybe because they didn't have a prolific colleague doing 10x code-writing in a rather more delicate way of generating HTML):
(Don't look at the code, though. I wrote it before Racket got submodules, which are great if you have a strict, non-CL-ish module system and syntax extension mechanism that otherwise make some things much harder than in CL. I have a TODO note in there to refactor it with submodules, but I had to redirect my time towards other languages, for reasons having nothing to do with language merit.)
> Rtml even depended heavily on keyword parameters, which up to that time I had always considered one of the more dubious features of Common Lisp. Because of the way Web-based software gets released, you have to design the software so that it's easy to change. And Rtml itself had to be easy to change, just like any other part of the software. Most of the operators in Rtml were designed to take keyword parameters, and what a help that turned out to be. If I wanted to add another dimension to the behavior of one of the operators, I could just add a new keyword parameter, and everyone's existing templates would continue to work. A few of the Rtml operators didn't take keyword parameters, because I didn't think I'd ever need to change them, and almost every one I ended up kicking myself about later. If I could go back and start over from scratch, one of the things I'd change would be that I'd make every Rtml operator take keyword parameters.
Here you will find some screenshots of some of today's web applications built in CL: http://lisp-screenshots.org/ and here an opinionated tutorial: https://web-apps-in-lisp.github.io/ One example: ScreenShotBot https://screenshotbot.io/ a successful open-source product and company. It now replaced Facebook's automatic screenshot testing tool (source: their blog). So, web apps in Lisp are possible -with a right amount of learning time and elbow grease.
The incremental development and interactive top-level are still precious and unmatched.
There is obviously a difference in capability, but do the cost differences scale linearly?
Maybe when the party is over, the lost will yearn for the parentheses to get just a shadow of that high back.
It was one of those things where 1-3 programmers, working with the right tools and thinking, could out-perform all competitors, no matter how much resources competitors threw at the problems. (I can't take credit for the initial architecture and implementation: that was all someone else.)
The system actually outlived Viaweb by decades, and I suspect still uses Scheme for a lot, especially for the necessarily complex backend.
(Half the problem for Scheme uptake was that most students only saw it school, as presented by a CS professor in an intro class, and then they did annoying homework, so they hoped never to use it again. They should've seen what we did with it, making it fly in ways that a CS professor wouldn't in first-year classes, compared to how it would've been done in other languages at the time.)
> One way we used macros was to generate Html. There is a very natural fit between macros and Html, because Html is a prefix notation like Lisp, and Html is recursive like Lisp. So we had macro calls within macro calls, generating the most complicated Html, and it was all still very manageable.
We just used lists and functions for HTML. And often with quasiquote, when we wanted to splice "dynamic" bits into a substantial chunk of "static".
I didn't try to use macros for HTML until a decade after this talk. I liked the simple DSL, and leaning on buffered I/O ports and string ports, but nobody else seemed to like it as much as I did (maybe because they didn't have a prolific colleague doing 10x code-writing in a rather more delicate way of generating HTML):
https://www.neilvandyke.org/racket/html-template/
(Don't look at the code, though. I wrote it before Racket got submodules, which are great if you have a strict, non-CL-ish module system and syntax extension mechanism that otherwise make some things much harder than in CL. I have a TODO note in there to refactor it with submodules, but I had to redirect my time towards other languages, for reasons having nothing to do with language merit.)
Which just links to the same ASCII-text link at https://sep.turbifycdn.com/ty/cdn/paulgraham/bbnexcerpts.txt, so it's exactly the same link as the one posted on HN here.