Having them clear it is trivial. I have my harness refactor automatically on a steady cadence, something I could never afford to take the time to do manually.
In fact, we are incredibly bad at telling lies from the body language of people we don't know well. Pretty much all the "well known" tells are sheer and utter bullshit that at best tells you if a person is stressed. That may or may not mean they are lying, but unless you know that person well enough to know if they have specific tells that correlates with lying for them, your odds are poor.
I'd like to think that if I'd come up with something like this, I'd have quickly gone "oh shit" and realised it'd be hard to access the earliest coins without raising unwanted attention, and started mining with multiple different keys, and actively moved those coins around. If Satoshi is still around, I'd expect he has more than enough money without the need to risk the upheaval touching those earliest keys would cause.
Yeah, based on the list of interests, I guess I've been Satoshi all this time and didn't know it. A shame my memory must have been wiped as I'd quite like all of those bitcoins.
You need someone who read Back's obscure 1997-1999 cypherpunks posts about combining Hashcash and b-money, implemented exactly that system a decade later, independently came up with the same non-technical analogies and trivia, wrote with the same hyphenation errors, and then happened to be active during the exact window Back went silent. The more you flesh out the "someone who read Back" profile, the more it just sounds like Back.
Someone who has read his material would be likely to repeat the same analogies and trivia.
As for the hyphen errors, they are common for people for whom English is their second language. I commit hyphen errors similar to what is described all the time because English hyphenation makes absolutely no sense. In fact, reading the list of examples, the mistakes listed makes more sense to me than the correct way of writing those.
I also switch back and forth on a lot of the phrases the article mentions.
I also switch back and forth between US and UK spelling, because I learned UK spelling at school, but was far more exposed to US spelling in practice.
At some point "Satoshi was a devoted reader of obscure 1997 Adam Back mailing list posts who shares his hyphenation errors, his Napster vs Gnutella analogy, his celebrity email filtering idea, his FDR gold ban interest, his 'burning the money' metaphor, his 'Achilles heel' description of DigiCash, his 'better with code than words' self-assessment, his energy-vs-banking defense, his British spellings mixed with American ones, his double-spacing habit, his it's/its confusion, his sentence-final 'also' tic, his 'proof-of-work' hyphenation, his WebMoney references, and who went active the exact week Back went silent" is just a longer way of saying it's Adam Back.
I'm not sure I agree with that, but it's what I came up with after challenging myself to read the article in toto again.
It's clear it's beyond a couple tics everyone has, and when you combine that with the starting set being ~500 instead of "all 8 billion people on earth", well, it's worth mentioning.
> That’s like saying enjoying composing music, but not enjoying playing music
Do you think that is impossible? There are plenty of people who enjoy composing music on things like trackers, with no intent of ever playing said music on an instrument.
I love coding, but I also like making things, and the two are in conflict: When I write code for the sake of writing code, I am meticulous and look for perfection. When I make things, I want to move as fast as possible, because it is the end-product that matters.
There is also a hidden presumption in what you've written that 1) the code will be badly written. Sometimes it is, but that is the case for people to, but often it is better than what I would produce (say, when needing to produce something in a language I'm not familiar enough with), 2) and that the collaboration will be with people manually working on the code. That is increasingly often not true.
I struggle to understand that comparison. Code is notation, you can’t write code for the sake of writing code. You have a problem and you instruct the computer how to do it. And for the sake of your collaborator and your futher self, you take care of how you write that. There’s no real distinction IMO.
> There is also a hidden presumption in what you've written that 1) the code will be badly written
The computers does not really care about what programming language you’re using and the name of your variables and other indentifiers. People do. You can have correct code (decompiled assembly or minified JavaScript) and no one will wants to collaborate on that.
Code is often the most precise explanation of some process. By being formal, it’s a truthful representation of the process. Specs and documentations can describe truth, but they do not embody it.
You can always collaborate with markdown files. But eventually someone will have to look at the code and understand what it does, because that’s the truth that matters. Anything else is prayers and hope. And if you’ve never cared about maintainability and quality of the code, it will probably be an arduous process.
> Code is notation, you can’t write code for the sake of writing code.
Of course you can.
> You have a problem and you instruct the computer how to do it.
And sometimes that problem is not the point. Just like sometimes I write for the joy of writing, not because I particularly care about a reader or the meaning of the output.
> The computers does not really care about what programming language you’re using and the name of your variables and other indentifiers. People do. You can have correct code (decompiled assembly or minified JavaScript) and no one will wants to collaborate on that.
This has no relation whatsoever to the sentence you quoted.
> This has no relation whatsoever to the sentence you quoted.
Maybe I wasn’t clear. What I wanted to convey is that the use of programming languages, paradigms, patterns, and other software engineering principles is related to the human side of programming.
You can solve a problem correctly, but with the resulting code being hard to parse. Or you can write readable code but with bugs. And almost everyone prefers the latter.
So badly written means incomprehensible code, mostly due to the size of it in the case of Agents. It’s all right if no one cares about the code. But if you expect someone to review it, changeset that even the author don’t understand is slop.
So again, this presumes that the result must be incomprehensible. That is not at all my experience. It may become incomprehensible if you let it, just as is the case with human developers. It won't be if you enforce reviews, and your harness demands cleanups and sets clear standards.
It's reflecting the value we get from it, relative to the cost of continuing if we switch to the API pricing. It is genuinely upsetting to hit the limits when you face a substantial drop in productivity.
Imagine being an Uber driver and suddenly have to switch to a rickshaw for several hours.
As others have said, the C64 does have bitmap modes, though it's understandable not being aware of it as they weren't that commonly used for games since it was often easier to use user defined character sets as tilesets if you had repetition.
reply