Readit NewsIt's also possible to use a slower "arbitrary PRNG and bump" scheme that tests the VRAM for the desired values(e.g. if it were a sprite, by running the blit at that pixel address and testing) and walks forwards or backwards until an unset value is found. If the walk can be done fast enough, it'll execute at the same framerate as an LFSR cycle-length fade. It can be further supplemented with an estimation heuristic or a low-resolution map to generate unique patterns. It's just less speedy and mathematically interesting to do that.
I can't think of a reason. Having to index by enum seems like it could be error prone.
Also, in the init(), instead of looping over all indexes of the array and setting 0, couldn't a memset be used?
I haven't even checked to see if the final program uses it. It's the kind of thing, though, that you might go in thinking, "maybe I will need that", and it doesn't add too much overhead to your prototype.
* Write an initial mockup that exercises APIs and data paths in an imperative, mostly-straightline coding style
* Write a source code generator that reproduces part of the mockup by starting with the original code as a string and gradually reworking it into a smaller specification.
* Now maintain and extend the code generator, and write new mockup elements to develop features.
The mockup doesn't have to be 100% correct or clean, nor does the code generator have to be 100% clean itself, nor does 100% of the code have to be automated(as long as clear separation between hand-written modules and automatic ones exists), but the mockup is necessary as a skeleton to guide the initial development, and similar, comprehensible output one layer down is a design goal. Language-level macro systems are not typically sufficient for this task since they tend to obscure their resulting output, and thus become harder to debug. Languages that can deal well with strings and sum types, on the other hand, are golden as generator sources since they'll add another layer of checks.
I'm still only using this for personal code, but it's gradually becoming more "real" in my head as I pursue it: the thing that stopped me before was developing the right feedback loop, and I'm convinced that the way to go is with a pretty lean base implementation(Go is an example of how much language power I'd want to be using in the target output) and an assumption that you're building a bespoke generator for the application, that won't be used anywhere else.
Source code generation gets a bad rap because the immediate payoffs are rare, and it's easy to take an undisciplined approach that just emits unreadable boilerplate without gaining anything, but the potential benefits are huge and make me not really care about design patterns or frameworks or traditional "paradigms" anymore. Those don't achieve anywhere near the same amount of empowerment.
https://www.chess.com/blog/kurtgodden/the-longest-possible-c...
Chess AIs, perhaps needless to say, are very good at computing at the depth necessary to win drawn-out endgames.
No matter what we do, moving and storing every single transaction is insane. It's like my bank account needing to know what every person in the world's purchases are this morning. I shouldn't need to know what some guy on the other side of the world spent his lunch money on, just to buy my own.
What am I missing? Surely the uber com sci phd's have fully solved this?
1) most contracts worth implementing in Ethereum are fairly complex
2) even given great developers, bugs are inevitable in complex code
3) the budget of the contract-makers' security team MUST be smaller than that of the hackers
You quickly see that if the chance of a bug is nonzero, "smart contracts" don't make economic sense. If you have a $100k contract, and you spend $5k on security (which would absolutely destroy most companies' margins by the way) you'll be facing hackers that are EACH willing to spend up to $90k or so. Let's say all the experts in this example world are $200/hr. You spent 25 expert-hours on security. But you're being hacked by people who spent 450 expert-hours on hacking you.
With that in mind, would YOU want to use a smart contract? Spend 5% of the contract value instantly on security, and risk losing 105%? This isn't a normal loss by the way, where you can prosecute someone or sue somebody. No, this is the instant, digital theft of the entire value of the contract, to an anonymous digital address where it will be quickly blended in with hundreds of millions of dollars of similar thefts a month.
And that's been true right from the beginning with Bitcoin: scams, schemes, heists, data loss - the headlines scream blood all the time. We've never had that kind of "mean time to disaster" in technology before. The status quo was that something would fail, but the failure would never quite get back to the individual or company that produced it. They would spin it away, and no careers would be harmed. But the likes of Solidity produces a meat-grinder, a blind destroyer of any who dare enter calling themselves rockstar.
I think it's kind of awesome and beautiful, in that sense. It will induce a maturation throughout the economy to adapt to this new pressure. But like adolescence, it can be an ugly work in progress, and I don't expect Ethereum itself to be a survivor at this rate.