"An elegant weapon, for a more civilized age." Heavy opinion: Combined with AI, there is a story for unified app development. Something like Ada for the L1 and trust reciprocation, then something that creates app domain vocabularies for L2 development. That of course would be lisp.
Sorry, but I don't get the meaning of your phrasing. I think that to use AI you must be very explicit and clear about what you want to design, and if Lisp provides some advantages one should define accurately the specific tool to use and when, how, and why.
I recall Norvig mentioning that other computer languages have taken many ideas from Lisp, those languages are also in the new civilization. Just to give an example: destructing-bind, apply and others are now done in javascript with a shorter syntax, and javascript without macros has excellent speed.
The quoted portion is a reference to an XKCD strip from earlier this century, https://xkcd.com/297/, which is a reference to Star Wars.
Their use of L1 and L2 should be read as "L" as "level" L1 is lower level, L2 is higher level. They're suggesting using Ada (or some other well-suited language) for the lower level trusted systems language and Lisp for the application language.
What it has to do with AI, I don't know. People want AI everywhere now.
Exactly. So let's expand. A good reason to have AI everywhere is that it is capable of giving you a fair answer for just about anything. So ask it to do some data analytics stuff, like what Tableau or PowerBI can do. It can provide maybe 60% of the same functionality that most users require (provided data access, blah blah). Ask it do patient pre-triage. It will get you within 60% of a ballpark answer. Ask it to diagnose a car problem, or a crop rotation plan. Once again, it get's you in the ballpark. So what I'm suggesting is, the current state of the art has no Dunbar limitation and no bias toward any particular domain. It's like a 10k person team that doesn't care what it's solutioning (L1). Generalize the L1 to provide high assurance foundational functionality (workflows, custom workitems, some general way and tools to get from a strategic opinion to an executable fact).
People are still limited by Dunbar's number, so they need domain specific vocabularies to help them describe solutions to smaller groups. Maybe a direction exploitable by lisp at the L2 level.
But with an AI native L1, it doesn't care about the domain but would need to hold up the whole organization. Ada assurance. So it produces a 60% solution that has to be consumable by any particular L2. Multiple enterprise apps with a common base layer. No need to provide connectors or bridging apps for separate ERP, SCM, BI, HR vendors. Complete line of site, real time analytics and real time budget adjustments, eliminating need for budget cycles. It's kind of the Deus Ex God app. Deprecates need for separate Salesforce, Oracle Fusion, Tableau apps, separate vendor expenses, etc.
It's great but some chosen libraries are a bit too random or early. You can look at a curated list of Common Lisp libraries here: https://github.com/CodyReichert/awesome-cl/
Perhaps instead of coding many small one day projects one could program one day projects that compose with each other. For example, I was thinking about developing a library that implements a version of J in Common Lisp (but I think fuel is lacking) so that, for example, the one day project named random-sample could be just:
randomSample =: 4 :'(x ? #y){y' NB. can't repeat.
randomSample =: 4 :'(? x # #y){y' can repeat.
So that, in many cases, one day projects could be reduced to one or two lines definitions (for those that know J that is the caveat).
Thanks, it seems you are right. The random-sample project seems so short that I thought it was a one day project and that the other would be also short projects.
Thanks for the April reference. In the post [1] there are just 11 comments and also it seems that the intended audience could maybe two dozen people!, not very encouraging to create a J in Common Lisp.
I'd be a very interested admirer, if not user, of such a project. I'm playing with J this past week, and otherwise have a couple of CL books under my belt. No other real experience programming, but I certainly think that sounds like a cool idea.
I wonder where April would fit in, with your idea? Joining forces with the fellow who made April might be a possibility. Strength in numbers, and all that.
I am 99% percent sure that for most of your use-cases Common Lisp has a way to do it and/or is flexible enough to change the language so that it is possible. You are talking about one of THE most malleable languages to exist. Literally a programmable programming language.
I can't hit reply on the top level comment anymore (it's flagged and now is 'dead'). I just wanted to say that is a text-book example case of how to tell the world "I am a dilettante in my field".
Experienced pros usually recognize when they don't know something well enough to critique it meaningfully. The harshest critics often have the least hands-on experience - while people who've actually built substantial systems in various technologies tend to be more measured in their assessments.
You can sense all of the psychological patterns in that paragraph - frustration displacement, confirmation bias, cognitive shortcuts, social signaling, Dunning-Kruger effect, etc.
I guess it's quite normal, if I start reflecting on my own history of comments on HN, Reddit and other forums, perhaps I will find a few examples from my own past of knee-jerk reactions such that comment.
We all have technologies we've formed opinions about based on limited exposure, early bad experiences, or just cultural osmosis. I bet if any of us looked back, they'd find comments where they'd be responding more to the reputation of a technology or the perceived attitudes of its community rather than deep technical experience.
The key difference is usually how the criticism is framed. Compare:
- "Lisp is impractical for real work" (broad dismissal)
- "I struggled with Lisp's syntax when I tried it briefly" (personal experience)
- "I haven't used Lisp much, but I'm curious how you handle XYZ" (honest engagement)
Forums like HN reward quick, confident takes over nuanced "it depends" responses. The incentive structure almost encourages this behavior, even from people who know better in calmer moments. As we gain experience, we often become more aware of what we don't know and more cautious about sweeping statements.
I recall Norvig mentioning that other computer languages have taken many ideas from Lisp, those languages are also in the new civilization. Just to give an example: destructing-bind, apply and others are now done in javascript with a shorter syntax, and javascript without macros has excellent speed.
Their use of L1 and L2 should be read as "L" as "level" L1 is lower level, L2 is higher level. They're suggesting using Ada (or some other well-suited language) for the lower level trusted systems language and Lisp for the application language.
What it has to do with AI, I don't know. People want AI everywhere now.
People are still limited by Dunbar's number, so they need domain specific vocabularies to help them describe solutions to smaller groups. Maybe a direction exploitable by lisp at the L2 level.
But with an AI native L1, it doesn't care about the domain but would need to hold up the whole organization. Ada assurance. So it produces a 60% solution that has to be consumable by any particular L2. Multiple enterprise apps with a common base layer. No need to provide connectors or bridging apps for separate ERP, SCM, BI, HR vendors. Complete line of site, real time analytics and real time budget adjustments, eliminating need for budget cycles. It's kind of the Deus Ex God app. Deprecates need for separate Salesforce, Oracle Fusion, Tableau apps, separate vendor expenses, etc.
[1] https://news.ycombinator.com/item?id=22225136
I wonder where April would fit in, with your idea? Joining forces with the fellow who made April might be a possibility. Strength in numbers, and all that.
https://lispcookbook.github.io/cl-cookbook/strings.html
https://clojuredocs.org/clojure.string
What's the equivalent lisp?
Experienced pros usually recognize when they don't know something well enough to critique it meaningfully. The harshest critics often have the least hands-on experience - while people who've actually built substantial systems in various technologies tend to be more measured in their assessments.
You can sense all of the psychological patterns in that paragraph - frustration displacement, confirmation bias, cognitive shortcuts, social signaling, Dunning-Kruger effect, etc.
I guess it's quite normal, if I start reflecting on my own history of comments on HN, Reddit and other forums, perhaps I will find a few examples from my own past of knee-jerk reactions such that comment.
We all have technologies we've formed opinions about based on limited exposure, early bad experiences, or just cultural osmosis. I bet if any of us looked back, they'd find comments where they'd be responding more to the reputation of a technology or the perceived attitudes of its community rather than deep technical experience.
The key difference is usually how the criticism is framed. Compare:
- "Lisp is impractical for real work" (broad dismissal)
- "I struggled with Lisp's syntax when I tried it briefly" (personal experience)
- "I haven't used Lisp much, but I'm curious how you handle XYZ" (honest engagement)
Forums like HN reward quick, confident takes over nuanced "it depends" responses. The incentive structure almost encourages this behavior, even from people who know better in calmer moments. As we gain experience, we often become more aware of what we don't know and more cautious about sweeping statements.