I'm sorry about my basic question. Back in the 80s, AI was betting on Lisp machines — https://en.wikipedia.org/wiki/Lisp_machine — now, of course obsolete.
Is Lisp still relevant in the AI space?
It's 2023, so of course I'm learning Common Lisp
191–200 of 346 posts
Re: It's 2023, so of course I'm learning Common Lisp
#192Me too buddy. I'm not even sure how I got to this point, but I can't go back.
Care to share what you’re using CL for?
I automate my workflow for approval of rhel kernel content to customers. Keeping the wheels on the delivery of 12 different streams of kernels to customers.
It also controls the workflow of delivery of intermediate "hot fix" kernels between scheduled releases when fixes are needed immediately.
I also use it for gathering metrics on gitlab ci and internal pipelines, alerting if the system is stalling or performing outside acceptable limits.
Re: It's 2023, so of course I'm learning Common Lisp
#193Earlier quoted context omitted.
It took me a while to grok monads, and the IO monad, and longer still to figure out how to compose them in safe ways, and manipulate execution order, etc. But: now I can write typesafe applications, and I produce fewer bugs when I work in non-FP languages (I get paid to write Java.) Lisp is a starting point. Haskell is where it's at. I recommend learning the style, even if you never produce production code in it.
Let’s say I want to do something simple but slightly beyond the scope of a traditional toy demonstration: * Read some environment variables and a local file * Start a monitoring thread that consumes from a channel or something similar, then every X s or X events writes to a local temp file and then sends a request batching some metrics to an external system * Configure and start an http server * Said server has a han…
I don't have time to try it atm but this looks like it would be quite easy to implement in Clojure (that falls under "Lisp", right?)
Re: It's 2023, so of course I'm learning Common Lisp
#194Wow, wasn't expecting to see my post on here! Eventually, I want to write a follow-up, but I'm still a beginner. Here's what I've liked about Common Lisp so far: * The condition system is neat and I've never used anything like it -- you can easily control code from afar with restarts * REPL-driven programming is handy in situations where you don't quite know what will happen and don't want to lose context -- for exam…
I have some cons! Last time I checked on it, QuickLisp doesn't support fetching packages over anything except for plain http, with no encryption and no verification mechanism in place to detect files that may have been tampered with during transmission. I think not supporting encryption or authentication for something as important as fetching source code makes QL a non-starter for me and hopefully for anyone else who…
These issues get mentioned a lot, you just haven't noticed I guess. Sourceforge is also an issue with some C libraries too, I'm guessing because it was done a long time ago? not sure.
I use ECL because it has really good C interop. It actually lets you inline C and access macros directly, making it a great glue language for C libraries. It's what I'm using it for now. I think you might even be able to avoid the GC entirely and use it to script C programs together in a performant way, by using the C FFI to allocate and manage the memory, including the ECL types, instead of the GC. And that's actually doable because of how good the inspector/debugger for lisp is. You can even inline assembly. I'm working on a bunch of CL stuff around this sort of thing, I plan to do a writeup of it and share it once I've developed it more.
Lisp has it's downsides, but the C FFI/embeddability, along with the excellent low-level debugger/inspector, interactivity, and conditions and restarts, makes it worth the time for me to invest in it. And the stability of the language. My main gripe is the reader, but it's easy-ish enough to avoid the problems with named-readtables, or a simple lisp parser for `read` or whatever. I like Clojure, but it's missing some key stuff from the old lisp world that I'd love to see. Shadow-cljs is awesome.
Re: It's 2023, so of course I'm learning Common Lisp
#195Wow, wasn't expecting to see my post on here! Eventually, I want to write a follow-up, but I'm still a beginner. Here's what I've liked about Common Lisp so far: * The condition system is neat and I've never used anything like it -- you can easily control code from afar with restarts * REPL-driven programming is handy in situations where you don't quite know what will happen and don't want to lose context -- for exam…
I have some cons! Last time I checked on it, QuickLisp doesn't support fetching packages over anything except for plain http, with no encryption and no verification mechanism in place to detect files that may have been tampered with during transmission. I think not supporting encryption or authentication for something as important as fetching source code makes QL a non-starter for me and hopefully for anyone else who…
When I started using CL 20 years ago, libraries were stored on cliki and any malicious user could put malware there. Any source you asdf-installed was generally GPG signed and the installer automatically checked signatures against your personal trust-chain.
Learning CL back then was my first introduction to GPG (and Emacs, and Linux)
Re: It's 2023, so of course I'm learning Common Lisp
#196Earlier quoted context omitted.
> You are able, in Mathematica, to write Plus[a, b] with your own fingers on your own keyboard and it will be interpreted as the same thing as a+b Sure, but it is not Mathematica's InputForm: https://reference.wolfram.com/language/ref/InputForm.html The majority of code is written not in FullForm. In Lisp 100% of the code is written in s-expressions. > Clisp is not the only lisp - I can name 10 others that cannot be…
>Racket Do you really know what you're talking about here? https://docs.racket-lang.org/raco/make.html >The raco make command accept filenames for Racket modules to be compiled to bytecode format. That's not a compiler... I don't claim to be an expert on lisp, so further googling I find https://racket.discourse.group/t/chez-for-architectures-with... which has some discussion about this and that native backend. Suffic…
From the Racket documentation:
https://docs.racket-lang.org/reference/compiler.html
"18.7.1.2 CS Compilation Modes
The CS implementation of Racket supports several compilation modes: machine code, machine-independent, interpreted, and JIT. Machine code is the primary mode, and the machine-independent mode is the same as for BC."
CS is the new implementation of Racket on top of the Chez Scheme runtime. Chez Scheme is known for its excellent machine code compiler.
"Machine code is the primary mode"
> Do you really know what you're talking about here?
Read above.
Re: It's 2023, so of course I'm learning Common Lisp
#197Earlier quoted context omitted.
Cl Condition system + repl = godmode. Your software crashes? Do you go back and set a breakpoint? No, because you’re already in the stacktrace in the repl exactly where the crash occurred. You fix the code, reload it, tell it to ether run where it left off, or restart from an earlier point.
Flask and Django have the exact same functionality - I've already said that this thing you guys keep talking is just a matter catching exceptions. https://flask.palletsprojects.com/en/2.3.x/debugging/ https://docs.djangoproject.com/en/dev/ref/settings/#debug
exceptions unwind the stack in all languages I know except in CL
Re: It's 2023, so of course I'm learning Common Lisp
#198Earlier quoted context omitted.
>Common Lisp programs run by default in a way that calls to undefined functions are detected. Cool so what you're telling me is that by default every single function call incurs the unavoidable overhead of indirecting through some lookup for a function bound to a symbol. And you're proud of this?
I thought you know Lisp? Now you are surprised that Lisp often looks up functions via symbols -> aka "late binding"? How can that be? That's one of the basic Lisp features. Next you can find out what optimizing compilers do to avoid it, where possible or where wanted.
At no point in time did I claim to know lisp well. I stated my familiarity at the outset. But what you all did was claim to know a lot about every other interpreted runtime without a grain of salt.
>Next you can find out what optimizing compilers do to avoid it, where possible or where wanted.
But compilers I am an expert in and what you're implying is impossible - either you have dynamic linkage, which means symbol resolution is deferred until call (and possibly guarded) or you have the equivalent of RTLD_NOW ie early/eager binding. There is no "optimization" possible here because the symbol is not Schrodinger's cat - it is either resolved statically or at runtime - prefetching symbols with some lookahead or cabinet is the same thing as resolving at calltime/runtime because you still need a guard.
Re: It's 2023, so of course I'm learning Common Lisp
#199I use Clojure at work but wow do I miss just about everything about Common Lisp whenever I have to debug anything or want performant code. Being able to be in nested errors and click at any part of the stack to inspect lexical bindings is extremely useful, and more importantly, clicking on an object then pushing M- to copy it to my REPL is much nicer than what Clojure offers (tap>, which I consider a glorified pretty…
[deleted]
Re: It's 2023, so of course I'm learning Common Lisp
#200Wow, wasn't expecting to see my post on here! Eventually, I want to write a follow-up, but I'm still a beginner. Here's what I've liked about Common Lisp so far: * The condition system is neat and I've never used anything like it -- you can easily control code from afar with restarts * REPL-driven programming is handy in situations where you don't quite know what will happen and don't want to lose context -- for exam…
I have some cons! Last time I checked on it, QuickLisp doesn't support fetching packages over anything except for plain http, with no encryption and no verification mechanism in place to detect files that may have been tampered with during transmission. I think not supporting encryption or authentication for something as important as fetching source code makes QL a non-starter for me and hopefully for anyone else who…
Solutions for the lack of https:
- add in https://github.com/rudolfochrist/ql-https (downloads packages with curl)
- use another package manager, CLPM: https://www.clpm.dev (or the newest ocicl)
> CLPM comes as a pre-built binary, supports HTTPS by default, supports installing multiple package versions, supports versioned systems, and more.
- use mitmproxy: https://hiphish.github.io/blog/2022/03/19/securing-quicklisp...