kscarlet

Do you understand what P and NP mean?

I was so pissed when I wrote a cool data visualization tool then some people at work immediately assume Claude did it.

In many case it is the sheer accidental complexity. I tried to get into Linux codebase and gosh it's so much harder than FreeBSD. And Chromium, LLVM... I don't believe it has to be that way. I use Common Lisp software (besides Emacs) written by human for anything I can and these have always been a joy to use or work with.

It seems the way industry is heading towards wrt LLM will make this even much, much worse.

For me at least I have to be able to believe I can understand any part of the stack if I want in reasonable effort. I would happily dive into semiconductor physics if I happen to want to (I'm a former physicist so the atom level I pretty much already learnt at school).

Could it be that the model capability is not that far off, and the main difference is that OpenAI/Anthropic has unlimited tokens?

I've asked question about my field (term rewriting) half a year ago and just recently (with GPT Astra, Claude Fable 5.1 and Opus 5.5), and the models are about equally clueless as half a year ago. But I can imagine a million of individually clueless agents exhausting every possibilities might be at a completely different level of capability.

Thanks! Kudos for the great work!

On second thought, some skepticism on performance comparison:

1. do both systems access everything from memory?

2. do both systems have the same kind of indices?

3. do either system tradeoff scan performance for faster/acceptably fast updates?

Cool language! I thought dplyr and datalog are both local optima (forget about the three-letter abomination) but I now declare this language the global optimum of query language.

> In contrast, Prela can be implemented extremely close to the metal. The Rust implementation inlines operators and compiles them into tight fused loops over raw arrays, running several times faster than DuckDB even without a query optimizer.

This will be true in Common Lisp as well. Now someone just have to implement it.

Or maybe I should steal the syntax and compile to SQL first, just so people can use existing DBMS.

So does the community of every other dialect (Common Lisp, at least). Write a function if you don't have to write a macro, and maybe declaim the function to be inlined.

The "Lisp Curse" is a ridiculous and tired myth that can only be invented by people who have looked at the language for 5 seconds and went straight to finding an excuse to not learn it.

VSCode: https://github.com/kchanqvq/olive

PSA: VSCode users deserve to use the OLIVE plugin (https://github.com/kchanqvq/olive).

Honestly I think the author misunderstood and misused P != NP. They should have said something like "collusion is NP-hard". P = NP doesn't imply NP-hard problem is efficiently solvable in practice, but the author assumes so.

I was expecting some tight convergence analysis that rely exactly on some superpolynomial behavior. No, yet another fallacy about P = NP vs NP can be solved in practice. We have too many of these.

These mean nothing. The C/C++ implementations use SIMD intrinsic while Lisp doesn't (it should have used sb-simd).

That's what the author means. She know what she's talking about.

> A small but illustrative example: given a live running clisp program, I can click on a UI element to inspect both the live object and the underlying code in the IDE. I can even copy and paste UI elements!

I agree GUI is awkward in Emacs/SLIME. I think the reason is there isn't a standardized GUI framework across the Lisp world. Otherwise people can make SLIME support it.

> If I wanted to use slime-fancy to inspect a class, what I get is a dead list of raw text that I have to awkwardly interact with.

This part I do not agree. Nowadays "text" in Emacs/SLIME is far from "raw text", there's button that respond to hover, with right click context menu, and can be copy and pasted. I recall some small quirks (like objects in inspector are not presentations) but the only reason they aren't fixed (yet) is nobody get bothered enough. There's rarely any fundamental limitation. After all, it wouldn't be fare to call LispWorks UI "dead pixels".

BTW I once wrote yet another over ambitious project < https://github.com/neomacs-project/neomacs > but it doesn't go anywhere either. People do not care enough, Emacs is good enough.

Can you tell a bit more about what is missing from Emacs SLIME when compared to LispWorks?

I don't see any comments on Kernel in the post. I didn't waste my time reading the book, but the post criticizes unhygiene F-expr, which is known to be awful and is exactly what Kernel aims to solve and supersede (via hygiene F-expr).

Not directly. Every "extensions" listed above cannot be implemented as user libraries, that's why these back and forth process between implementation extensions and portability user libraries need to happen to reach a de-facto standard. Otherwise the user libraries become de-facto standard themselves, like ASDF the build system, Trivia the pattern matcher...

But I think the power dynamics is crucial. In the Lisp ecosystem the users have great power, (and there are dozens of implementations,) so it's not like one or two implementation decides what everyone is gonna use and everyone just lives with it.

I think the Common Lisp ecosystem sets a good example of how a dozen of implementations move ahead together. Implementations experiment with extensions, the really useful ones get implemented multiple times, and some portability library emerges as de-facto standard if it's good enough. You can watch the result in https://portability.cl/, the language is evolving like never before even if the standard committee has dissolved nearly 40 years ago!

  (defparameter *a* '(1 2 3))
  (setf (car *a*) 3)

And this is undefined behavior because it mutates literal constant. I stopped reading further. The CL column is so bad.

"Lisp Curse" is really a myth, or at least, it completely fails to apply to the Common Lisp community. https://applied-langua.ge/posts/lisp-curse-redemption-arc.ht...

Why? Many Lisp systems and Common Lisp in particular have great hot reloading capability, from redefining functions to UPDATE-INSTANCE-FOR-REDEFINED-CLASS to update the states.

Very nice.

p.s. (I hate to point this out), there seems to be a name collision with https://lisperator.net/slip/

> As to the actual difference between JIT vs. AOT... it may just come down to accounting. That is, on whether you can always exclude the compilation time/cost from the overall program execution time/cost or not. If so, you're compiling ahead of (execution) time. If not, you're compiling during execution time.

Well, this includes what I refer to as "on-the-fly" AOT, like SBCL, CCL, Chez Scheme... Even ECL can be configured to work this way. As I mentioned in another comment, people in those circles do not refer to these as "JIT" at all, instead saying "I wish my implementation was JIT instead of on-the-fly AOT"!

They generate native machine code.

In that sense almost every compiled Lisp/Scheme implementation, GHC, etc. or any other interactive programming system, count as JIT. But virtually nobody in those circles refer to such implementations as JIT. Instead, people says "I wish our implementation was JIT to benefit from all those optimizations it enables"!

It seems that JIT is overloaded with at least 2 meaning.

The canonical definition of JIT is "compilation during execution of a program". Usually, a program is being interpreted first, then switches to compiled code in the middle of execution. This is not what this article does.

What this article does is sometimes called on-the-fly AOT, or just on-the-fly compilation. I'd prefer not overloading the term "JIT".

I guess this case is workable similar to struct redefintion. There can be a condition and a CONTINUE restart, which makes instances of the removed constructor obsolete.