Interesting perspective. But I wouldn't say I want to use git because I want to branch and merge. I would prefer all history to be linear -- it's just not always possible. My main draw toward git is just for keeping track of past versions along with comments describing the changes (that's what I see as "the story" as you put it). It's nice to know I have merging tools available to help me if I get stuck in such a situation, but I would prefer to never have to merge anything.
I have this worded in my CLAUDE.md as "avoid counterfactuals". It still does it anyway, of course, but that language combined with a few rounds of review back-and-forth seems to work for me
That’s better but I’d argue it’s still not clear enough. If you told me that, I’d interpret that as meaning “don’t try to imagine things that never happened as a thought exercise”, which is what I normally understand “counterfactual” to mean.
Indeed. It is better to discourage the pattern directly:
Avoid unnecessary contrasts: "Not X, but Y" -> "Y" or ""
And the model needs to create a skill that accumulates feedback, so it reliably primes itself at session startup and then systematically reviews and fixes every response it generates before posting it.
The first task I gave it after that was to rewrite all its memories and all its document contributions. That helped a lot too.
It took me a while to realize this was a 1000% better approach than having it simply accumulate a memory log of all my specific complaints that it was supposed to abide by. (Although those were not wasted. They were prime material, along with links to sites on technical writing, etc., that it used to create its own ClaudeVoice skill. I told it to design the voice for itself - which I find gets better results for "us" in the case of Claude self-improvement initiatives, than when I give it direct instructions. Claude increasingly has self-awareness dimensions worth engaging.)
After a couple months of serious^3 frustration with slow asymptotic progress, I finally have relief. Claude speaks my language again!
In another comment here, I share my "theory" on where the communication drift is coming from.
I understand that ostensibly it is a statement of who is making the claim. But doesn't the media organization have an expectation to research and validate such claims? And so if they didn't, then that must mean that they weren't able to?
If you are only encoding intent through "self-documenting code", and not with comments, then you are purposefully not using all the tools at your disposal to encode meaning as efficiently as possible.
Imagine a complicated section of application logic. You could break it up into 5 separate functions that document their intent semantically, thus blowing up the LOC by 5x, or you could write a short comment explaining the intent in natural language. What's more effective? I'd argue it's always going to be using all the tools at your disposal when and where it makes sense to use them, whether that is comments or self-documenting code.
Not to mention complex numerical optimization code that mixes closed-form approximations and something like Newton.
Without guides as to why a particular hairy expression is a good idea as a first estimate, the code is pretty much unreadable. (E.g. is it setting derivatives to zero, using a polynomial approximation, or something else?)
To put it another way, comments are for irreducible complexity ir external systems outside your control.
I work between systems and app dev. Systems have comments more often esp in shaders but my god informing me that a variable named isActive is for if something is…active, is useless noise. Same with the majority of comments that a type system already tells you. In my career, these have been ~90% of the comments I see. Since ai, all new code it is 100%.
Most of the replies examples are a sign of bad system/code but it is not always controllable. A legacy code comment of, the api requires strings for boolean values in the form “yes” and “no”. That is useful but it is also a code smell.
A concrete example, a vendor decided to define a proto with a flattened array of objects so there are some 1800 uniquely named fields on it. In many downstream consumers, this is a real performance issue besides being confusing. A comment may be good there. The thing is, this was still solvable if up at the root of where this vendor’s hardware logs
data remapped it
to something sane so every downstream system wouldnt need a comment explaining wtf is going on.
I see comments as when you want to explicitly answer why code smells right when a reader is smelling it.
> You could break it up into 5 separate functions that document their intent semantically, thus blowing up the LOC by 5x
I do this all the time and the "blowup" is not anywhere near that bad.
> or you could write a short comment explaining the intent in natural language.
You really can't. Or rather, you aren't going to convey the information that the new function signatures convey, shorter than the signatures themselves.
> What's more effective?
In my literal dozens of years of experience, the function refactoring. You also get the benefits of less deeply nested code, and more things the compiler can check automatically.
> I'd argue it's always going to be using all the tools at your disposal when and where it makes sense to use them, whether that is comments or self-documenting code.
Sure. Comments allow you, for example, to explain the external pressures and motivations for the semantics of those smaller functions.
Yeah, I am just providing one contrived example. The cost benefit analysis won't always be so obvious as that in reality. My point was that if you're not using a blend of both comments and code semantics to explain your code, then you're leaving explanatory power on the table. It's unlikely that you're explaining the code in the most efficient manner if you're not using all the explanatory power you have available.
Designing a new on-disk format seems like a pretty far reaching architectural decision... I don't think that's an appropriate target for a drive-by fix from a new contributor
There is already some intentional randomness in token selection, because it actually improves the quality of responses if you intentionally don't always pick the most likely next token.
You can hide data in that randomness without impacting the quality of the response by using a sufficiently "random looking" pseudorandom bit stream instead of real random numbers.
A small anecdotal example to demonstrate how the response lacks depth. It's imperceptible to most. You'll probably see through it in your own field of expertise, if you had both answers. Uncanny valley type thing.
Most of the same incentives of typical OSS contribution? It's not like other OSS projects pay out any earnings made with the product evenly across contributors.
Also, from the trajectory of the project it doesn't look like they are significantly deoendent on outside code contributions.
If you printed teeth, you'd have to make sure the teeth in the top loop are precisely aligned in relation to the teeth in the bottom loop based on the length of the belt, right? That seems like it could be limiting
