But sometimes you do just want the same answer each time. Not this human woo crap, where the answer depends on god knows what, but a deterministic function of some kind, reliably producing a given output for a given input according to a fixed set of rules.
Yes, but sometimes (quite often actually) you really don't care. The entire subfield of audiovisual compression is built around the principle that you don't care. The data is actively being lost and the image distorted, and you're fine with it. Wanting deterministic results out of MP3 is like wanting AC units to be loud. Sure, they are loud, just like MP3 is deterministic, but why exactly is being loud one of your requirements when choosing an AC unit? Isn't it enough to produce cool air, or in case of MP3 - sound good enough?
It would be like telling the computer to compress a music file containing Bach's Toccata and Fugue in D Minor, and getting back a file that contains Rick Astley's Never Gonna Give You Up. Maybe you don't care, but I do.
You are talking about AI outright failing to get anything remotely close to the correct result. That's a completely different argument and has nothing to do with non-determinism. Things can be deterministically wrong too.
Accuracy, precision and determinism are completely different things. Lossless compression reduces precision, and by that also accuracy, but it doesn't become undeterministic.
You've got terms confused. LossLESS compression does NOT reduce precision or accuracy. Unlike lossY compression, which does.
That said, my point is that determinism is incidental to how current generation of compression algorithms work, not an explicitly desired quality. And even that isn't strictly true, because e.g. x264 in certain multithreaded configurations already produces non-deterministic results that look as good as single-threaded encoding. For this use case - and thousands of others - losing determinism when switching to AI-based solutions really isn't a big deal.
But we already have a folder for docs? It's called "docs". If the docs are the source code, that's fine, but that doesn't mean we have to move them into the source code folder. We already have somewhere to put them! The end goal should be for the source code folder to be in the .gitignore, same as you would with object files... but if the docs are in there, now you're stuck.
No, this is not a source file to be used to generate code. It's a spec to be used to build the code to - same as any other document. Aside from the fact that docs can be in any format - not merely .md - they do not belong in `src/`. Why? Well for one, many of my projects have multiple `src/` directories because they involve multiple binaries. But the documentation used to generate that source is in the project, not the `src/` directory of one of its binaries. I'm building a video streaming site that uses one server for the SFU, one server for the web interface, one server for the websocket connections, as well as STUN and TURN servers. None of the project works unless all these separate binaries are working together and communicating. Which `src/` directory should I place these markdown files in? What about the `.sql` files I use to spec out the database schema before passing it off to the LLM? What about the mermaid files, code snippets, `.txt` files, and data files used as part of the documentation project? Should they all go in `sfu/src/md/`? No. The project is one whole with multiple `src/` directories and they all require their own documentation. Beyond that they need access to each other's documentation so that when the agent is working on one part of the system it can still be aware of how the other pieces operate. Documentation should absolutely be under version control, but placing it in the `src/` directory is plainly the wrong call. And there is more documentation than just markdown. This was a shower thought that wasn't completely fleshed-out (and the article admits it wasn't) and never should've made it to the front page of HN.
This is an experimental thought. If people are vibe coding apps without looking at code, the argument here is that maybe ad-hoc prompts is not the best way to capture that because you lose the instructions. So the proposal, why not have those instructions saved as markdown files at least we have a reference in English.
We don't look at binaries, we don't look at assembly, we work with high level languages. The specs were for developers to translate to programming primitives, but if the translation is largely automated, then the specs will become the code and we will need better ways to manage those, and I think the IDEs are gradually trending that way, look at all the most recent agentic dev tools, it surely follows that trend.
With respect to not having this piece on HN. If the author is seeing many organizations doing this practice, then why he would not share that empirical observation? is it only because it is against your pure world and abstractions? Just the recent leak for the Muse agent shows that most of the system behaviour is written in markdown.
Whether you like it or not, technology never care about purest and idealist, it evolve under pressure of deliveries and pragmatic choices, and if there is such a pressure, which the author claims to be, then HN is the medium to share it.
I like how you wrote "the argument here is that maybe ad-hoc prompts is not the best way to capture that because you lose the instructions" as if you didn't begin this thread by contradicting my statement "Docs in VCS, yes." and claiming I missed the entire point of the post. It seems you've now agreed with me and yet still somehow wish to argue. I think you've missed the point of my post. You should reflect on that.
Of course the src directory is in VCS - it's arguably the entire point of the VCS. The entire project - including documentation - should be in VCS. Documentation is not source and should not be treated like it. But it is crucial to generating the source and always has been treated as a second-class consideration. Now that we have AI agents that can handle all the fine details of keeping the documentation up to date, I believe. We seem to be in agreement that docs should be under revision control. So the only point we seem to disagree on is where they go. My original claim was that they don't belong under the src directory. I still maintain that position. You could say that the broader point of the article was to put them under VCS and I started out with that position so there is no disagreement there. I just think it's poorly thought-out to place them under the src directory and it's even more shortsighted to place the docs in a subdirectory called 'md'. To me, these seem like the thoughts of someone who is just discovering how to craft code with the assistance of AI: They're good initial instincts, and potentially just a handful of completed projects away from a better solution, which is what people have been doing since before AI: Keep the docs separate. Keep them under revision. Keep them up to date. But documentation is not source, and even if you specify the project in intricate detail you're not going to get the same deterministic result by piping them through the same AI. And that's always been the way documentation has worked: It specifies things in as much detail as we can, but in the end someone has to translate that into source code. And typically the person writing that source code has to make decisions or trade-offs that were never specified in the docs. Now with AI agents we're able to back-port every line of reasoning into the docs and create much better and more up-to-date documentation, and that's exactly how I build with AI. But we're not able to treat the documentation as if it's a deterministic system that will generate the same outputs each time. Therefore it is meaningfully different from source code and should be treated as such. (Although it should be kept very close to the source code in a structure that is intuitive and appropriate for the project.)
In any event: If we're talking past each other or simply not understanding one another then I thank you for a respectful conversation.
I don't think we are at a position to claim that documentation are the source, though to your point and the author's point as well, it serving more purpose now then what used to have.
I would say that this field is evolving really fast and we might consider and revise some practices. So I try to keep as much as open mind as possible.
I just got served a big chunk of JSON, not even pretty-printed, with the text in there... somewhere. Difficulty level: quite high, even in reader mode.
Right, but if you're referring to Return as Enter, then there's no reason to refer to Enter as Return. The reason for the change is that people don't distinguish the two. If we're going to eliminate this distinction, we should do it properly!
(I've had blank looks from a few colleagues after suggesting they press the Return key (that being the term I used to refer to the Return key) - which makes me wonder what percentage of people even know that Return is the name of a key. Perhaps we should retire the term entirely.)
How would that work for all the software that distinguishes between them? The standard (see e.g. Mathematica) is for `return` to create a new line in a multi-line text field, and `enter` (`fn+return` on a keyboard without a dedicated key) to execute/evaluate/commit the field.
But Return and Enter are still functionally different keys on macOS. Return inserts a new line, Enter (and cmd-Return) submits forms (which works for Reddit comments, but not here for some reason).
AFAIK those are not different keys, it's the literal keyboard combination Cmd+Return that is interpreted as submission in those contexts. Ctrl often works just as well on Windows for that purpose as well.
Numpad Enter is definitely a distinct key though, but I've never seen it treated differently than Return (except for randomly not working in some contexts that accept Return)
Except in many apps Return submits forms and Shift+Return inserts a new line, and in many other places Return and Enter do the same thing, showing to me that those labels are already pretty meaningless. It feels like a transition a good design team could figure out, keeping the distinction for those who want it, but simplifying for the rest. I believe Windows calls these Enter and Numpad Enter, or something like that? That feels better to me.
For parallelisable stuff that can occupy all cores for an extended period, the 2990WX typically takes about ~1.2x as long to do the same work/does ~0.83x the work per unit time, assuming code compiled with clang or gcc. Which isn't really coming across in the numbers here.
I haven't spent much time timing single core stuff, except - regarding clang, which looks like it contributes to the Geekbench 7 score, I did some measurements a few months ago suggesting that clang compiles for x64 more slowly than for ARM, all else being as equal as I could be bothered to try to make it: https://news.ycombinator.com/item?id=46938682 - and the single threaded test runs I did of my code suggest that the Geekbench 7 single core might be about right?
(Whether the clang timing discrepancy is actually relevant to Geekbench, I've no idea, but I thought it interesting anyway.)
If you need a benchmark that makes the PC look massively faster than the Mac, I'm sure those are available too.
Geekbench multi-core has been a single-task benchmark since version 6. The multi-core / single-core score ratio is supposed to tell how much you will benefit on the average when you use all available CPU cores. Some tasks parallelize better, while others have bottlenecks that prevent effective parallelization. For every CPU, the ratio is well below the nominal speedup you can get under ideal circumstances.
Note that Geekbench 7 no longer runs the same subtests in multi-core mode as in single-core mode, so any ratio calculated from the overall scores instead of from the individual subtests is misleading. There are a lot of subtests that it only runs in single-core mode and omits from the multi-core tests, seemingly to placate the critics that didn't like the inclusion of poorly-scaling tests in the multi-core mode. It's not as dumb as the Geekbench 5 strategy of just running N independent copies of the test, but it does seem like a dumb change to me.
Yeah, all of that would be great. Good ideas all round, and thank you for gathering all these sensible requests into one centralized list.
Slight problem, and it's not clear whether you've realised this: everybody else in the world knows that we can't have everything! Still, it's good to have goals, even if they can't be met, and it'd be monstrous to mock the ambition on display - which I do declare we should in fact salute. Good on you sir/madam, for not being a cynical jaded asshole like the rest of us.
Computers can do that!
reply