erichocean

If you are skilled in the field already, yes.

Though it's not just "ask" in the one-shot prompt sense, but more in the "over the course of a few days" sense.

Another interesting LMDB fork: https://github.com/datalevin/dlmdb

My depraved mind wants to see Jank [0] running on Fil-C, using Fil-C's garbage collector.

[0] https://jank-lang.org/

If you like this kind of thing, Bifurcan [0] is a Java library with implementations of RBB-trees and related (fast) immutable data structures.

[0] https://github.com/lacuna/bifurcan

> The only time I ever really found that GA was actually a benefit to me was performing rotations.

Maybe that's why I've found it so useful when doing rigging for animation—that's the entire job!

Personally, I've got a line of mileage out of using GA to express animation rigs.

I don't know about the rest of the article—I'm not a mathematician—but I certainly enjoying using GA a lot more compared to linear algebra, I find it way more intuitive and being able to visualize intermediate products on my rig is like a super power.

If it was that easy, I wouldn't have commented.

It's not, which is why it would be nice if they did the actual work (on your hardware).

I would 100% pay $16/hr to run a self-hosted instance, but I won't spend thousands of dollars to (maybe) get it working (my time + the hardware).

> Half the code was written in a language you didn't understand. The other half was written using libraries you never heard of.

The author already describes himself as "not a rockstar developer", but if this is the definition of "rockstar" I need to recalibrate.

Being able to learn new languages and libraries, to me, is completely normal.

(Also: how funny is it to suggest rewriting code you self-admit you can't even read.)

I wish you guys could partner with Modular to get Mojo inference working on your hardware, e.g. https://www.modular.com/models/deepseek-v4-pro

There are deep reasons for the variations, especially around (reader) macros.

I suspect the author created his own IR after being offered that suggestion earlier, he's definitely aware it exists.

People also liked Arcane.

I wish they offered a Dvorak keyboard. Of all laptops, this is the most obvious one to do it.

Humans have, obviously. Just interbreeding with ancient species was enough to do it, even without separate evolution.

Autochrome [0] make reviewing Clojure diffs from AI really easy.

[0] https://github.com/ladderlife/autochrome

I also interact a ton with C and C++, but it's easy today to have Claude write a Project Panama wrapper and then put a nice Clojure veneer on top of the Java.

> it just couldnt write the changes to file 9/10 times when using it with opencode

You might want to give this a try, it dramatically improves Edit tool accuracy without changing the model: https://blog.can.ac/2026/02/12/the-harness-problem/

Another limitation: only five active user accounts (with UIs) per machine.

> Is that what you mean?

I think the confusion is that, when I write "model", you read "LLM."

LLMs aren't the only kind of AI model, and they have the limitations Aphyr mentions, for the obvious reasons you're thinking of.

His mistake is thinking that's the only model that exhibits intelligence today, but it's not.

> Models do not (broadly speaking) learn over time. They can be tuned by their operators, or periodically rebuilt with new inputs or feedback from users and experts. Models also do not remember things intrinsically: when a chatbot references something you said an hour ago, it is because the entire chat history is fed to the model at every turn. Longer-term “memory” is achieved by asking the chatbot to summarize a conversation, and dumping that shorter summary into the input of every run.

This is the part of the article that will age the fastest, it's already out-of-date in labs.

AI is exactly the right term: the machines can do "intelligence", and they do so artificially.

Just like we have machines that can do "math", and they do so artificially.

Or "logic", and they do so artificially.

I assume we'll drop the "artificial" part in my lifetime, since there's nothing truly artificial about it (just like math and logic), since it's really just mechanical.

No one cares that transistors can do math or logic, and it shouldn't bother people that transistors can predict next tokens either.

As I remember it, they were basically the same—but IOKit is C++ (with restrictions) because 3rd party developers didn't want to learn Objective-C.

But that's a hazy, 20 year old memory.

> Isn't it more-or-less the same as the Python REPL?

Not even close.

Also discussed in detail in Crafting Interpreters.[0]

[0] https://craftinginterpreters.com/

> Bridging that mismatch at the macro level seems like the harder problem than the basic REPL integration.

You can (and people do, core.async in Clojure works this way) put entire compilers in macros, macros are just functions that take and return code.

How about this?

    (filter ds (> year 2008))

That's a trivial Clojure macro to make work if it's what you find "intuitive."

> is just so much more readable

I thought that too before I learned Clojure, now I find them equally readable.

What I'd like to see is Omarchy implemented via the Nix package manager. (Seems like a good project for AI, actually.)

> If you know of any other snippet of code that can master all that complexity as beautifully, I'd love to see it.

Electric Clojure: https://electric.hyperfiddle.net/fiddle/electric-tutorial.tw...

They don't read the things you send them, not even for "safety checks" or sys-admins accessing the system. Totally opaque (as it should be).

Keeping chat content around for 30 days might as well mean "forever." Anyone at the company can steal your customers chats.

My agreements with customers would prevent me from using any service that did that.