"Michael Hart's email messages and blog posts had equal line length paragraphs in monospaced font: he chose the wording in such a way that each line had the same number of characters."
Disclaimer: I work at an AI lab [edit: but speak for myself :-)]
The value proposition is an average of 270 commits a day, for $4000/month, and the dramatic improvements to the game Yegge described. Even supposing 2/3 of them are burned on the scaffolding, 90 commits/day (assuming they’re of mostly good quality) would cost multiple engineers, one of which would cost much more than $48k/year.
As another comment said, the ultimate proof will be in the pudding. But I don’t think the value proposition claimed is complicated.
I wouldn't say complicated, and I agree with you that the proof is in the pudding. I looked at the gameplay and if it was something akin to.. let's say "minecraft before minecraft existed", I'd be amazed and see the value right away.
Looking at the game, it doesn't seem like a game that would require as much money to build as he's claiming he uses in credits (although via a loophole that allows him cheaper access). It doesn't look BAD, it just doesn't seem to warrant that much spend.
> would cost multiple engineers, one of which would cost much more than $48k/year.
Have you played the game?
There's no way all this wasted money is comparable to the work of multiple engineers. This is using AI for entertainment, the result isn't an engaging game.
> I am of course using sanctioned cheating: I get all those tokens because I'm an individual, with the Claude Max discount. So it "only" costs me about $5k/month out of pocket, for a 50-agent cluster running on a 512GB M3 Ultra Mac Studio I bought off eBay for $25k.
> So it's not $120k/month of real money, but it's still crazy spend.
re: the control points having areas where the curve is unresponsive. IIUC, whereas the control points of a Bezier have direct meaning, this is an attempt at a sensible/usable mapping of synthetic control points to the curve? Which presumably means it could be made much better with some work/exploration? Or did I misunderstand that part?
The one that comes to mind is how big your hash maps have to get before all the clever algorithms beat linear scan, and it's surprisingly large on modern computers: linear memory access is _very_ predictable.
The Roc and Zig folks probably have actual numbers.
What are these surprisingly large numbers you've seen? I thought that linear scan optimizations are typically reserved for pretty small maps, like dozens or maybe hundreds of elements.
Maybe more than that if you have a sub-optimal hash map implementations. There are a bunch of those floating around - for example, Java's build-in HashMap has traditionally been kneecapped by lack of value types, and if you are not careful you can incur 2x cache misses per lookup...
When I learned (Common) Lisp at Georgia Tech in the summer of 1995, we were encouraged to make as many functions as possible purely functional, and if mutation was needed, to try to hide it within the bounds of a function.
So while Lisp may not be purely functional, the culture hewed that way.
That's interesting, because I had the opposite experience. I started getting into Lisp around 2004, but bounced off of the community because the culture I was experiencing hewed heavily toward imperative code and global variables in the name of efficiency.
I specifically remember the breaking point being third-party library where none of the functions had any parameters. Instead, everything was controlled by using dynamic binding to adjust the variables within the functions. Various forum members kept praising its beauty and elegance, but I found it needlessly confusing.
I have a soft spot for the Lisp family of languages. I've been using Emacs for almost thirty years and have used both Scheme and Clojure in production. However, my experiences back in 2006 have left me with a permanent bias against Common Lisp.
It’s not too hard if you try, once you get in the groove :-)