Over time I’ve come to see LISP less as the natural collapse of artificial boundaries but the artificial collapse of natural ones. Where and how data is stored is a real concern, but where and how the program is stored isn’t. Security boundaries around data and executable code are of paramount importance. Data storage concerns don’t benefit from being mixed with programming language concerns but from computer and storage architecture concerns (eg column stores).

In toy programs, such as this one, those concerns can all be discarded, so LISP is a good fit. But in serious systems it’s soon discovered that what is offered is in fact “simplistic made easy”. That’s not to say that traditional systems don’t suffer from all the ills Hickey diagnoses in them, but that we differ on what the cure is.

> it solves the actual problem perfectly

The whole post was about how that doesn't solve the problem perfectly - there is no way to interactively edit the output.

> by embracing LISP principles directly

This could just as easily have been javascript+json or erlang+bert. There's no lisp magic. The core idea in the post was just finding a way for code to edit it's own constants so that I don't need a separate datastore.

Eventually I couldn't get this working the way I wanted with clojure and I had to write a simple language from scratch to embed provenance in values - https://news.ycombinator.com/item?id=43303314.

> It doesn't scale to massive collaborative systems where you need rigid interfaces between components. But I suspect many of us are solving problems that don't actually need that complexity.

Here's the issue. Starting out you almost certainly don't need that rigid interface. However, the longer the app grows the more that interface starts to matter and the more costly retrofitting it becomes.

The company I currently worked at started out with a "just get it done" approach which lead to things like any app reaching into any database directly just to get what it needs. That has created a large maintenance issue that to this day we are still trying to deal with. Modifying the legacy database schema in any way takes multiple months of effort due to how it might break the 20 systems that reach into it.

>> No SQL, no UI framework, no MVC architecture - yet it solves the actual problem perfectly.

No SQL but in it's place is some code. The point of SQL was to standardize a language for querying data. This is just using a language other than the standard. A UI is a way for people to avoid writing code.

Sure doing your own custom thing results in something easy for the programmer. Nothing new about that.

> Of course, there are tradeoffs. This works beautifully for personal tools and small-team scenarios. It doesn't scale to massive collaborative systems where you need rigid interfaces between components. But I suspect many of us are solving problems that don't actually need that complexity.

Spreadsheets. If you squint the right way, they embody the lisp principles for the non-programmers' world.

> "Any sufficiently complicated program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."

I have never seen that in practice (30+ years of industry experience working on very large applications).

I think it is one of those statements that fans of Lisp love to quote (a lot) without having any empirical data to back it up.

And yes I am sure that there are examples out there. You can probably find examples of anything if you look hard enough. But that doesn't make it a general rule.

This makes no sense to me. CL is not an astral technology. It’s just a parentheses-rich language that is worse than almost any other until you get to macros, continuations and psychotic polymorphism. Which are cool to talk about at hacker parties, no /s, but don’t do much business-wise.

>the collapse of artificial boundaries between program, data, and interface creates a more direct connection to the problem domain.

I always figured that was one of the reasons that Excel can tackle so many different problems.

Was this written by a LLM?

Glad I'm not the only lunatic who would do something like this. At least until I got my paws on dBASE.

I worked with somebody with your name in the early 90s on a Sequent/Dynix system, that wasn't you by chance was it?

This might be what you're looking for... https://gtoolkit.com/

I sometimes deal with such code.

I belive it works for you, and I can even say I think most projects have (a little) too few lines of embedded sql in them.

But arguing for code that isn't checked out with the rest of the code when I clone the repo, isn't greppable, and radically departs from everything most people are used to, that isn't something I'd accept.

Without bothering to try to enumerate minutiae, here's the One Thing that would control such a decision in any such "why not just" argument:

Complicated formats can't be meaningfully version controlled.

    PS C:\test> $x = Open-ExcelPackage book1.xlsx
    PS C:\test> $x.Workbook.Worksheets[1].Cells["B3"].Formula
    SUM(B1:B2)

tbf learning clojure is a more valuable spend of time then learning LibreOffice Calc.

And it's still a "!!!DRAFT!!!" ending with a TODO that ended up on the front page?

Ha! I see the resemblance, but they're actually opposites. Access adds visual layers between you and your data, while this LISP approach removes them. Access makes databases more approachable to non-programmers through GUIs, while this example makes programming more direct by collapsing all those abstraction layers into pure code. Same problems, completely different philosophies!

everything is trying to reinvent ms access these days, with a bit of RBAC on top. It was the original low code environment.

This was posted on scattered-thoughts.net ;-)

If this was a joke, I'm sorry for explaining it.

If this was not a joke, I point you to the giant

    <h1>!!! DRAFT !!!</h1>

as the first element of the <article>