Recent submissions

Comment · 4 days ago
Do you understand what P and NP mean?
Comment · 17 days ago
I was so pissed when I wrote a cool data visualization tool then some people at work immediately assume Claude did it.
Comment · 20 days ago
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.

Comment · 21 days ago
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).
Comment · 23 days ago
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.

Comment · 2 months ago
Thanks! Kudos for the great work!
Comment · 2 months ago
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?

Comment · 2 months ago
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.

Comment · 3 months ago
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.

Comment · 3 months ago
Comment · 3 months ago
Comment · 3 months ago
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.

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

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton