I like the idea, but I noticed that there seems to be some kind of issue with it registering clicks. I don't know if I'm just sometimes clicking slightly outside of the hitboxes or what, but I find myself "dragging" stuff by accident when the game doesn't register that I "dropped" whatever object I had selected.
> Unfortunately, due to a problem also present in the first public version of Bitcoin, Satoshi could never spend the money from that transaction.
What evidence suggests that this was unintentional? It offers a sense of fairness and objectivity from the originator, without generalizing the concept of a transactionless block or requiring any special logic to enforce it.
Great question. I can't say this was intentional or not. To people interested, it was only one line of code missing: he ""forgot"" to include the first transaction to the mapTransactions.
TempleOS has a number of interesting Oracular things. The F7 button gives you a random Bible word, and Shift+F7 gives you a random Bible passage. The author claimed that God provided guidance through this functionality.
Lower down, TempleOS's "god" library was a 'random' number generator that was seeded/pre-populated with the entirety of the KJV. The "GodBits" function would get you "random" numbers from it.
I worked on a project once involving divination from texts and wrote Terry about this topic. Here's what he told me (2015):
"""The easiest way to pick a random passage is to read timer that is in the random 1-20Mhz.
If you have a faster timer, then divide by a number.
The Bible is 4Meg. You want a random number from 0 to 4 million.
The Bible is 100,000 lines of text.
If you have the Bible in memory being edited, broken down by line number, you can pick a random
line number from 0 to 100,000.
If you flip 17 coins, you get a random number from 0 to 120,000. I use that for picking a line number.
God can do pretty-much any technique. The simplest and best is probably just randomly opening the Bible by hand."""
Do you have any sense of why? It works best for me on small teams and startups, since that's where we need people to own and iteratively address full problems. "Understand and address why users of type X aren't returning" is not too confusing, especially if you have good communication processes during the actual work.
I'm not the downvoter, but perhaps they were annoyed with "Would Google of" rather than "Would Google have." That particular error really gets on people's nerves.
60% of my interactions are with ESL or ETL engineers. Would of, could of, should of, on accident, and the like, are hallmarks of a generation holding the less well read attitude that grammar doesn't matter. The ESLs I work with thank one for a correction, incorporate it, and move on. Bad grammar is a bug. We all make them, reading clean code reduces them, and peer review helps too.
"Would of", "could of", "should of" are certainly errors when conjugating , but "on accident"? Either preposition "by" or "on" seems correct to me and the correct choice seems arbitrary -- though I find myself preferring "on".
From what I could find doing some (brief) research, this is a case in which the difference breaks down nearly perfectly along generational lines. Those ages thirty-five and under overwhelmingly prefer "on" and those younger prefer "by"[1]. Prepositional choice has always seemed a bit arbitrary to me, and the fact that there are dialectical differences reenforces that belief[2].
To suggest that this contributes to a "generation holding the less weel read attitude that grammar doesn't matter" strikes me as a bit misguided.
I chose "on accident" precisely to inject the generational notion into my comment, being well aware of its notability as an indicator of usage patterns by age.
First, in your citation 1, you have the generational aspect of "on" and "by" reversed. The original and correct[1] usage is "by accident". Acceptance by the younger generation doesn't make "on accident" correct, it is just accepted for lack of knowing otherwise. (This will, granted, eventually result it in showing up in dictionaries as a usage.)
The new generation, whether less read or less likely to have read the writings of prior generations, is less influenced by existing usage, and mistakenly verbalizes "on accident" to over-regularize with "on purpose".
"Over-regularization" is the kind of mistake a toddler makes until they learn correct usage by hearing and reading correct usages from multiple example experiences.[1] As the new generation reads less old material, and socializes textually with peers more and earlier, incorrect usages imprint to the point they gain defenders from the "everyone's doing it so don't call it wrong" camp.
I'm not making an argument ad populum and even if I were, I don't see how it holds any more weight than your argument from antiquity.
Language and grammar evolves and as far as linguistic changes go, the use of one preposition over another is pretty benign. Prepositional choice is already essentially arbitrary and varies from region to region.
English is a moving target. The current generation forming its own vernacular doesn't make in any more or less correct than when the previous generation did it. It's not as if English has its own académie française, and the flexibility of English is one of its most charming properties.
Leaving aside the condescending quip about toddlers, I don't see how over-regularization of prepositions is a bad thing. They're already confusing enough as it is and I personally would prefer a language with more consistent rules than not.
EDIT: A quick addendum: I didn't actually know this was a mistake and I appreciate having learned it anyway.
I was referencing toddlers and how that age group learns. The word toddlers is not condescending, it's simply the most appropriate word for the age group in question.
> I don't see how it holds any more weight than your argument from antiquity
The dictionary is nothing but "argument from antiquity", as would be the conventional definition of "correct usage", in contrast to the "many people doing it wrong makes it right!" definition you disavowed, skipped a graph, then repeated.
Prepositions are not "essentially arbitrary" even when used with metaphysical concepts. Particular prepositions work with particular types of concepts, and curiously, end up quite similarly used among a variety of cultures and languages. In English, for example, is the concept something you can possess, or a process that happens to you? If you consider other things that couple with "on" or "by", you'll see what I mean.
Certainly English is charming, and rapidly evolving. You've likely read Bill Bryson's "The Mother Tongue", but if not, you might enjoy it.
Is this a common ESL problem? It's based on audible similarity but I would expect non-native speakers to be exposed to comparatively more text than audio.
When people say this, I usually hear "Would Google've". It looks horrible that way, but captures the intention. I might use it orally (or in fiction dialogue), but not in writing.
Their polymorphic factory isn't returning "different types." They're both returning A. The derived one is just returning a specific type of A. If the shared "makeOne" returned naked pointer types A* and B* rather than shared_ptr, then this would all work correctly, thanks to C++'s covariant return type support.
Covariant return types are a powerful feature in a language that doesn't support other forms of return type polymorphism. shared_ptrs function so similarly to pointers that it can be surprising when they don't support this behavior. Surprise and capability mismatch with pointers are strikes against shared_ptr. But not sufficient ones to stop me from using them.
No, they're not. One is returning a pointer to A, and the other is returning a pointer to B (which just happens to be a subclass of A). It matters, and just because you can do it with a naked pointer doesn't mean that you should. The problem you've described is a code smell.
If I hand you a pointer to B, you (client code) can do everything that is exposed by B. If I hand you a pointer to A, you can only do the set of things exposed by A. And that's a fundamentally different interface guarantee.
There are cases where covariant return types are abused, so it's fine that you treat it as a code smell. However, C++ does make them necessary for several valid patterns. This does include alexgartrell's example, but here's a popular one:
I have a polymorphic type that should be copyable. Because of the limitations of C++ copy constructors and operators, my only option is to expose a virtual method (call it "copy"). The non-smelly semantics we want are such that if you call "copy" on an object, you get an identical copy of the same type. So if you call "copy" on a pointer of type A, you get an A. Call it on a B, you get a B.
The contract itself is polymorphic. It doesn't commit to returning any particular flavor of A.
We can implement this method if we return naked pointers. But if we want to be safe and return a smart pointer, we have to introduce dynamic casting or other worse smells.
"I have a polymorphic type that should be copyable. Because of the limitations of C++ copy constructors and operators, my only option is to expose a virtual method (call it "copy"). The non-smelly semantics we want are such that if you call "copy" on an object, you get an identical copy of the same type."
Well, yeah...because those semantics are just as smelly as the one you described before. What you describe isn't a copy constructor at all, and trying to make a copy constructor do what you want is a dangerous thing. A "constructor" that takes any subclass of class A and returns an instance of that subclass is inherently brittle: add a new subclass of A, and you've got to update the "constructor" to know about the new type. On top of that, your "constructor" has to introspect into the type to determine what to initialize when, and that's slow.
There are easy ways to get the behavior your want (e.g. make a template function that calls the appropriate class' copy constructor, or -- closest to what you want -- make a template copy constructor function on the class itself), but complaining that you can't make a bog-standard copy constructor do polymorphic construction kind of misses the point.
Here's a better discussion of the problem than I have the space to go into here:
We're going too deep into this, for alexgartrell's relatively simple claim that covariant return types have a reason for being in the language, and that smart pointers omit that capability.
But just to clarify: no base class implementation is aware of derived classes in the copying case, so your smell doesn't exist. See Scott Meyers' "virtual copy constructor" snippet half way down the page:
http://books.google.com/books?id=azvE8V0c-mYC&lpg=PT159&...
You can't do it that neatly without covariant return types. Ergo, you can't do that while returning safe, smart pointers.
