Some doors can be designed with a large push handle to unlatch from the inside while still being closed from the outside. Allowing people on the inside to escape out but not the other way around.
An artifact is the output of an automated process that take some input and outputs artifacts. Its a generic term that can mean all kinds of things depending on the process and type of output. For example if you have a program that take an Open Office document in and produce a pdf and an epub file out then "pdf" and "ebup" would be the artifacts.
You'll get pretty far if you start off with Obsidian + Markdown + a makefile with Pandoc. You can even combine Markdown and Latex files together with Pandoc. This gives you an easy workflow with all the power you need using Latex as an escape hatch. And Obsidian have enough plugins to do whatever you want (or swap it for any other Markdown or code editor of your choice).
This is where I'm at right now and it works rather well. I have a glue script that automates some shorthand in the Markdown into LaTeX for PDF and pre-set styles for DOCX and HTML exports. It works rather well, and being able to tweak my own LaTeX shell for the content is quite nice as well.
It's ePub that gets the weak treatment right now. Which just has me wondering if I can have my tool output the input files this standardebook toolkit wants (probably) and get a reasonable output from it.
AI (and humans) know why something was done if it was for technical reasons as it would be necessary to have those technical reasons described in the test suite/type system.
It wouldn't be able to reverse engineer why something was done when the "why" is some arbitrary decision that was made based on the engineer not having had his morning coffee yet, but those "whys" aren't an important property of the system, so who cares? Even in the unlikely event that someone documented that they zigged instead of zagged because it was just the vibes they were feeling in that moment, nobody is going to ever bother to read it anyway.
If something could be important and a decision about it was arbitrary, it's valuable to capture that. "There are three viable algorithms here and I don't know which will perform best with our live data so I picked the one that's mathematically beautiful for now" tells whoever is optimizing that system a couple years later that they should try the other two.
Wouldn't the intent of that be captured in your benchmark tests? And especially now that code generation is essentially free, wouldn't you include all three with the benchmark tests showing why a particular choice was chosen? This reads like an important property of the system, so tests are necessary.
You're assuming a perfect system in which all relevant properties are tested for. That doesn't match probably 99.9% of real world systems.
The issue with AIs reverse engineering code is that context is very important - in fact knowledge and understanding of the context is one of the few things humans can still bring to the table.
Unless every relevant fact about that context has been encoded in a recoverable way the system and tests, AIs can only do so much. And there are essentially no non-trivial systems where that's the case.
You would test all important properties. That matches all real world systems you are responsible for. There is no reason to accept a lower standard for yourself.
Absolutely you have no control over what others have written, but you also have no way to access their lost context, so you are no further ahead than an LLM in that situation. The available information is the same for you as any other system.
> wouldn't you include all three with the benchmark tests
Maybe. If I know that the performance of this particular code path is going to be critical to the project's future success, sure. It's more common for something like that to be premature optimization though and the extra code is dead weight. I am not convinced by the idea that LLMs make that kind of dead weight much less undesirable.
If a choice comes down to simply guessing about the future then it isn't an important property of the system and therefore it makes no difference which algorithm was chosen or why. You are right about that being a premature optimization, but that equally applies to trying to decipher "why". When the future comes and an important property emerges, the historical "why" won't even matter as it wasn't rooted in anything relevant.
The load-bearing word in my original comment is could.
An experienced developer will often have a good intuition about what might deserve attention in the future but isn't worth the effort now.
It's also useful for social reasons. Maybe the CTO wrote the original code and a junior developer working on the optimization thinks they know a better way but isn't sure about questioning the CTO's choice of algorithm. A comment saying it was arbitrary gives them permission.
> Maybe the CTO wrote the original code and a junior developer working on the optimization thinks they know a better way but isn't sure about questioning the CTO's choice of algorithm.
If changing the algorithm is going to negatively affect the program then the CTO would have written tests to ensure that the important property is preserved. There is really no reason for the junior to be concerned as if he introduces an algorithm that is too slow, for example, then the tests aren't going to pass.
Yes, it is most definitely possible the CTO was a hack who didn't know how to build software and the junior was brought in to clean up his mess. However, in that case the information is simply lost. An LLM will not be able to recover it, but neither will a human.
You can't use CRDTs for version control, having conflicts is the whole point of version control. Sometimes two developers will make changes that fundamentally tries to change the code in two different ways, a merge conflict then leaves it up to the developer who is merging/rebasing to make a choice about the semantics of the program they want to keep. A CRDT would just produce garbage code, its fundamentally the wrong solution. If you want better developer UX for merge conflicts then there are both a bunch of tooling on top of Git, as well as other version control systems, that try to present it in a better way; but that has very little to do with the underlaying datastructure. The very fact that cherry-picking and reverting becomes difficult with this approach should show you that its the wrong approach! Those are really easy operations to do in Git.
Using CRDTs to calculate the results of a merge does not require being allowed to commit the results of that calculation, and doesn't even require that you be able to physically realize the results in the files in your working copy.
.
Consider for example if you want to track and merge scalar values. Maybe file names if you track renames, maybe file properties if you're not just using a text listing (ie .gitattributes) for that, maybe file content hash to decide whether to actually bother running a line-based merge.
One approach is to use what Wikipedia says is called an OR-set[1], with the restriction that a commit can only have a single unique value; if it was previously in the set then it keeps all the same tags, if it wasn't then it gets a new tag.
That restriction is where the necessity of conflict resolution comes in. It doesn't have to be part of the underlying algorithms, just the interface with the outside world.
> the result is always the same no matter what order branches are merged in — including many branches mashed together by multiple people working independently.
If it is doing what I think CRDT does, and tracking where the user clicked and what they typed, it sort of carries a bit more syntax info. It has a chance to get it right. And often since it does something it turns a figure this shit out with review this.
Much better is AST merging (which itself is also more amenable to crdts). But doing this at the text level is doing to be a failed experiment - the value isn’t there.
It also makes cherrypicking and rebasing wayyyy easier. You can actually add or remove any set of patches, at any time, on any peer. It's a dramatic model shift -- and is awesome.
But merging already auto-merges what it can best effort. Conflicts are syntax conflicts not semantic ones.
Therefore you could have automerges that conflict in a way that breaks the code.
Example would be define a global constant in file X. One commit removes it. Another commit on another branch makes use of it in file Y.
OTOH where I get merge conflicts in Git it is usually purely syntax issue that could be solved by a slightly cleverer merge algo. CRDT or semantic merge.
I would like to point out that Bram Cohen seems to be obsessed with “better merges” and had a verbal spat with Linus on Git when it was just taking off (2007).
It’s pretty weird that he has gone back to the same idea without understanding why Git’s approach is better. I would say VCS is largely a solved problem. You can simplify a few things here and there, maybe improve support for binaries and few other things, but that’s almost on the top of existing systems. The foundation is rock solid, so it doesn’t sound very sensible to attempt something from ground up.
> A language’s type system doesn’t need to model every possible type of guarantee
Actually this is the exact point of a type system. Why would you want to write unit tests for stuff the compiler can guarantee for you at the type system level?
reply