3 ms·

Before there were tens of thousands of open source developers across a dozen or so language ecosystems using collaborative source control and the hard won, but

Before there were tens of thousands of open source developers across a dozen or so language ecosystems using collaborative source control and the hard won, but sometimes forgotten, wisdom of decades of internet systems development; we had to build so much more of our stack ourselves. It was much less about finding the appropriate "libraries" or "frameworks" -- their were not that many to even choose from. You would have to build the layers of your stack from first-principals, or perhaps second-hand mimicry of third hand descriptions. Understanding your problem, and building exactly the tool needed is a very different approach from picking the tool with the momentum, growing developer base, checklist of features, and knobs to twiddle to somehow get something approaching a solution to your problem. In that setting, Common Lisp has a very powerful feature set; macros, CLOS, interactive debugging with restarts, dynamic redefinition and a fast runtime made to be interactively modified. It is a few days work to make a minimalist ORM, a HTML template language, or a functional query language and engine and proceed to tune it for purpose. I think we are approaching an inflection point. The software ecosystem complexity, and the specialization of developers into frontend, backend, or specific frameworks and the absolutely unfathomable and delicate chains of transitive trust in the layers and layers of abstraction will become a liability . Doing "more" of the same, throwing more bodies at it, rewriting the world because your UI or ORM needs a reboot, trying to attach checksums and technical proxies for dependencies as a substitute for the basic fact that you need to know what code you are running and why to be a responsible software vendor; none of this will work. Truly powerful languages and runtimes with appropriate technology fit for purpose are the way out of this conundrum and the best path to being a responsible and effective computer programmer. Keep your parens sharp.

deleted 4y ago
[deleted]
quanticle 4y ago
Doing "more" of the same, throwing more bodies at it, rewriting the world because your UI or ORM needs a reboot, trying to attach checksums and technical proxies for dependencies as a substitute for the basic fact that you need to know what code you are running and why to be a responsible software vendor; none of this will work. You're assuming that the "bodies" being thrown are going to continue to be human. But what if they aren't? We've already seen what can be done with the very early, relatively primitive AI programming assitants that we have today. What happens when we're competing against an army of Java/Python/Go programmers, all of whom have extensive AI assistance? I love Lisp. All Lisps. Common Lisp. Scheme. Clojure. Even elisp. And, for a long time I thought Lisp was the future. I thought, like you, that the ever expanding size of codebases written in more conventional programming languages would necessitate a switch to something more functional and more amenable to building non-leaky layers of abstraction because that would be the only way to continue to build without introducing at least one bug for every new feature. However, the advent of LLM powered coding assistants (like OpenAI's Codex, or Github's Copilot) has made me reassess my view. LLMs benefit from having more training data. Now, the thing that I thought would kill Java/Python/Go codebases, i.e. the sheer number of lines of code required to do even the simplest thing, turns out to be a strength. Because each line (and all its variants) now represents a datum point in the training set for the AI. Can Lisp be enhanced with AI support. Sure it can, in theory. But in practice, there's far less Lisp code out there. Primarily this is because far fewer people use Lisp on a regular basis. But it's also because, for any given task, far less code is required to accomplish it. Just like Java's greatest weakness turned out to be a strength in a world where we have AI assistance, Lisp's greatest strength turns out to be a weakness. I'm going to continue to use Lisp wherever I can. If not at work, then in my projects at home. But I'm far less sanguine today about the eventual dominance of Lisp (and Lisp-like languages) than I have been at any time in the past.
- cbrozefsky 4y ago
  We've reached peak HN irony when someone asks and then poo poos the idea of Lisp being enhanced with AI support...
  - quanticle 4y ago
    I appreciate the irony, but the kind of AI that Lisp was designed for (i.e. automated reasoning, expert systems, etc) is really not the same as the kind of AI that we have today. The AI we have today is very much a "worse-is-better" [1] AI. There's no elegance. No craftmanship. Just scale and raw power. And just like worse-is-better programming languages conquered Lisp, worse-is-better AI approaches conquered the classical approaches that were pioneered along with Lisp. It might be ironic, but I don't see any particular contradiction in saying that worse-is-better AI magnifies the advantages of worse-is-better programming languages. [1]: https://www.dreamsongs.com/WIB.html https://www.dreamsongs.com/WIB.html
    - cbrozefsky 4y ago
      I paid for a house for myself, and one for my family with lisp, oh and a small cabin in the woods and a couple touring motorcycles. It was clojure specifically. It was precisely the automated reasoning and expert system you say is not the same kind of AI. We did some of that too, but it was peripheral and at most was an input and support for the captured and encoded and refined knowledge of human experts. That project helped pay for many houses and send kids to college, and otherwise help hundreds make a living. Before that, I did some java and ruby, which was fun and helped pay rent. But before that I helped pay for many houses and even apartment buildings with Common Lisp. That project has paid for houses and school and living for many dozens of people over the last 20 years. It's still going. I am not interesting in conquering anything, or winning anything, or what momentum or the power law, or economies of scale, or momentum or other efficiencies of industrial software production. People trot out those arguments all the time to explain why something can't be done, or why they can't do what they want to do, or why something they hate is winning or inevitable. Believe in yourself and your compatriots, and if you wanna do it with lisp, find some better compatriots. Cheers.

deleted 4y ago

[deleted]

quanticle 4y ago

Doing "more" of the same, throwing more bodies at it, rewriting the world because your UI or ORM needs a reboot, trying to attach checksums and technical proxies for dependencies as a substitute for the basic fact that you need to know what code you are running and why to be a responsible software vendor; none of this will work. You're assuming that the "bodies" being thrown are going to continue to be human. But what if they aren't? We've already seen what can be done with the very early, relatively primitive AI programming assitants that we have today. What happens when we're competing against an army of Java/Python/Go programmers, all of whom have extensive AI assistance? I love Lisp. All Lisps. Common Lisp. Scheme. Clojure. Even elisp. And, for a long time I thought Lisp was the future. I thought, like you, that the ever expanding size of codebases written in more conventional programming languages would necessitate a switch to something more functional and more amenable to building non-leaky layers of abstraction because that would be the only way to continue to build without introducing at least one bug for every new feature. However, the advent of LLM powered coding assistants (like OpenAI's Codex, or Github's Copilot) has made me reassess my view. LLMs benefit from having more training data. Now, the thing that I thought would kill Java/Python/Go codebases, i.e. the sheer number of lines of code required to do even the simplest thing, turns out to be a strength. Because each line (and all its variants) now represents a datum point in the training set for the AI. Can Lisp be enhanced with AI support. Sure it can, in theory. But in practice, there's far less Lisp code out there. Primarily this is because far fewer people use Lisp on a regular basis. But it's also because, for any given task, far less code is required to accomplish it. Just like Java's greatest weakness turned out to be a strength in a world where we have AI assistance, Lisp's greatest strength turns out to be a weakness. I'm going to continue to use Lisp wherever I can. If not at work, then in my projects at home. But I'm far less sanguine today about the eventual dominance of Lisp (and Lisp-like languages) than I have been at any time in the past.

cbrozefsky 4y ago
We've reached peak HN irony when someone asks and then poo poos the idea of Lisp being enhanced with AI support...
- quanticle 4y ago
  I appreciate the irony, but the kind of AI that Lisp was designed for (i.e. automated reasoning, expert systems, etc) is really not the same as the kind of AI that we have today. The AI we have today is very much a "worse-is-better" [1] AI. There's no elegance. No craftmanship. Just scale and raw power. And just like worse-is-better programming languages conquered Lisp, worse-is-better AI approaches conquered the classical approaches that were pioneered along with Lisp. It might be ironic, but I don't see any particular contradiction in saying that worse-is-better AI magnifies the advantages of worse-is-better programming languages. [1]: https://www.dreamsongs.com/WIB.html https://www.dreamsongs.com/WIB.html
  - cbrozefsky 4y ago
    I paid for a house for myself, and one for my family with lisp, oh and a small cabin in the woods and a couple touring motorcycles. It was clojure specifically. It was precisely the automated reasoning and expert system you say is not the same kind of AI. We did some of that too, but it was peripheral and at most was an input and support for the captured and encoded and refined knowledge of human experts. That project helped pay for many houses and send kids to college, and otherwise help hundreds make a living. Before that, I did some java and ruby, which was fun and helped pay rent. But before that I helped pay for many houses and even apartment buildings with Common Lisp. That project has paid for houses and school and living for many dozens of people over the last 20 years. It's still going. I am not interesting in conquering anything, or winning anything, or what momentum or the power law, or economies of scale, or momentum or other efficiencies of industrial software production. People trot out those arguments all the time to explain why something can't be done, or why they can't do what they want to do, or why something they hate is winning or inevitable. Believe in yourself and your compatriots, and if you wanna do it with lisp, find some better compatriots. Cheers.