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.
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.
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
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!
Yes, unfortunately the threading primitives require libc. Ditto subprocesses. It's on my list.
But regarding: "Oops... apparently this is vibecoded. Welp, I just wasted ten minutes of my life reviewing slop that I'm not going to get back."
Do not talk to people like this. I don't care if you don't like the library, or if you found a flaw in it. I am a regular person who wrote this code for no other reason than I thought it would be good to exist. It's unbelievably rude to call it vibecoded slop, or a waste of your life, and it makes me sad that someone who would write an otherwise thoughtful comment would say something like that.
If your code depends on a bunch of initialization from libc, then you should continue to link to and use libc. sp.h can coexist with libc just fine; if you link to it, the library makes sure to conform where it needs to (e.g. not stomping on the register that holds the TLS base pointer).
What sp.h does not do is reimplement all of libc's initialization code. If you want to build a freestanding binary, there are a few utilities in there for defining a _start so the loader can actually jump to your code. But it's not, and isn't meant to be, a libc replacement in this sense.
It is not part of the core library. It is certainly not meant as a reference-level implementation of math functions. It's there so you can write an easing function for a game without pulling in libc. It seems like its existence has offended you. If that's the case...I'm sorry? At every possible point, I note as loudly as possible exactly what that library is. I found your tone extremely dismissive and disrespectful and I don't care to engage with that any more than I already have.
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.