dboon

Yeah, I agree. The first time something felt magical about the results themselves. That's it!

I've been building Cargo-for-C (https://github.com/tspader/spn), and the difference between Fable and Opus was already astounding. Fable was the first time that I could point a model at a piece of code I'd written and expect it to make it meaningfully better rather than a hard pattern match to whatever mistakes it had.

5.1 so far seems like another leap, which is really surprising. I threw it at a few bigger features I've been designing for a while, and it came back with some extremely thoughtful wrinkles in the design that I'd legitimately not considered. Which, OK, package managers and build executors and compiling C/C++ is pretty well trodden ground, but my thing is very different from everything that exists, and I was very surprised it was able to understand all that context so deeply and intuitively

Thanks for the reply, I'm sure you're also just a regular person writing about the stuff you like and regardless of whether you end up agreeing with me or deciding that, no, that was exactly the tone you wanted, I appreciate the thought.

I promise I'm not normally uptight like this, but there's a difference between having a laugh and whatever this is. Like I said, this feels (a) legitimately angry and (b) in a spit flecked enraged way that has become popular. I guess if you're cool with people calling whatever you work on clown-car turboslop then more power to you.

This prose feels extremely angry and ungenerous; abstractly, I agree with a lot of the points, but when I read this:

> My conclusion is that OpenCode is clown-car turboslop with a security posture of “let me bend over for you daddy”. Everyone using it should stop using it.

I do not want to keep reading. There are regular people who wrote this software. When did it become normal to talk about open source like this? How would you feel if someone wrote this about some software that you wrote? Reading this article made me feel extremely gross

I remain deeply unconvinced. I respect your writing and opinion enough to have actually put chunks of the essay into Pangram, including the part you label "blatantly Claude", and...they come out as 100% human. The 2023 and 2024 samples do, in fact, sound like OP, doubly so given that people change.

In 2020, I wrote a kitschy story where the characters talked with a cowboy affectation (https://spader.zone/the-fastest-gun/) which frankly borders on embarrassing for me now. I don't think my writing sounds much like it did then.

I think it's fucking embarrassing when people use LLMs to write prose for them. It's fundamentally different than software, for me. But I think your sensors are a bit miscalibrated. Regardless, thanks for all the good stuff over the years and thanks for the response.

What? This is one of the most clearly human written articles I could imagine. Can you explain what you mean?

Yeah, recreating Conan minus the foundational idea stated at the beginning of the post. Yup.

I am making Cargo for C. I have 3/4 of a working demo; the tool can build itself, including some non-trivial dependencies which I've ported to build natively with the tool (instead of wrapping their Make or CMake or whatever). The pitch: It's insane that we have to pull in Python or Lua to build C code. CMake is an abomination against god that has become usable in spite of itself. Zig cc is proof that this entire ecosystem is an embarrassment. My tool gives C projects a TOML manifest, and builds scripts written in C and JIT compiled by the tool. Now, you can write build scripts in the language itself, pull in dependencies you wanted to use anyway. It also provides a stable ABI. There's an HTTP-backed index and a Git-backed index. And it generally does the same thing for C that, say, Bun did for JS/TS. You'll be able to run C files from source and have the entire ecosystem available. You'll be able to trivially generate single file static binaries, or dynamically link to an older glibc without arcane tricks. It will fix C.

I'm also still working on my "what if we wrote a real standard library for C"; I added some feedback I got from the release.

Also, some side projects: I'm making something that's a mixture of chezmoi, Omarchy, and Unraid, for Arch. It has a nice web UI installer. You store everything about your machine as a Git repo, and it brings it up. I wanted to make a system where you could install things manually as you're learning, and once you know what you want have the configuration system naturally absorb it back in. Unraid was great, but once I had real infrastructure running on it the ad-hoc nature made it a huge pain to do it right.

I am also experimenting with a new UI framework that is like HTMX but can also target native apps. UI trees are JSON, not HTML. The runtime is a small core of WASM which takes in JSON patches and applies them. Each backend just translates the UI tree to native calls (e.g. DOM calls, or GTK calls, or...). It's kind of like React Native, but the point is that RN is insane because it synthesizes complex widgets and pretends that the abstraction is clean, and when it isn't it causes problems. There's...a lot more nuance to where this sits among all the UI frameworks, but the best way to describe it is "I wanted something that renders UI server-side for simple apps, and I wanted to be able to run it on the web or natively without bundling a browser". It's very much a sketch to see if this is even possible, and very much missing critical features still, but I have two nice examples that show a plain C backend and a TypeScript backend.

C standard library: https://github.com/tspader/sp

A route from the UI framework: https://github.com/tspader/spry/blob/main/examples/form/nati...

A UI tree from the UI framework: https://github.com/tspader/spry/blob/main/examples/form/ui/t...

A TSX version of the same app: https://github.com/tspader/spry/blob/main/examples/form/web/...

The library provides a few basic allocators.

A comment from a legend. Thanks for reading and thanks for the response! I agree; the dynamic array is typed as a T* for ergonomics sake but is similarly a pointer and a length (and an allocator).

Could I pick your brain a little more on the design? I'm spader at spader.zone; if you have time, drop me an email. I promise not to take too much of your time and I'd love to hear from you.

I have no philosophical complaints with supporting odd architectures in general. I agree that most obscure targets are probably not that much code, since the library is factored with this in mind (e.g. basic WASM support took an afternoon).

It's stated as a non-goal simply because it's not the most valuable thing I can do with my time. My fundamental stance is that writing new Windows or Linux or macOS or WASM programs in C is a good idea, and those are the programs that I write, so that's where my focus is. But if someone would like to come along and write the ~30 syscalls needed to port the library to a new platform, or even register any interest in such, I'd be happy to look into it at that point.

People are very silly and very entitled. I'd bend over backward to help anyone contribute to or use the library in any way. In response, all I ask is for some common courtesy and friendliness. Spending more than exactly zero seconds on people who won't give you that is a waste of time.

In other words, you hit the nail on the head. Anyone who acts this way can get fucked! We'll be having a good time and making friends without them

Haha jk…but really? Lol just kidding…unless?

Yeah, AI has done a number to this place

No problem and thanks for the apology. Happens to the best of us. Regardless, thanks for the comment — I definitely didn’t mean to slip by the pthread stuff on a “well technically this isn’t libc.so”. It’s just code that’s pretty hard to get right and I haven’t had a chance to rewrite it!

Thanks! I didn’t know this.

Thanks for reading and thanks for the link. I'll read anything DJB wrote.

It...is not a libc implementation. That's an impressive level of misunderstanding!