I love the concept of sharding counters to trade write performance for read performance! As so often happens, my understanding advances by looking at something I thought I knew the only possible answer to ("Of course a counter goes in a single variable!") and seeing that other alternatives are possible.

You are worrying about correctness of concurrency. Yes, this should always be worried about.

The parent poster is worrying about performance of concurrency. This doesn't need to be worried about unless you are one of about 5-10 tech companies whose name is recognisable to people on the street.

I didn't like this idea at first, since it struck me that if for some reason you had to create many records in quick succession (e.g. some kind of bulk upload) they would essentially be placed in random order. But thinking about it, the only scenarios where you would need to do this and want to preserve the order exactly would be if all the records were coming from the same source -- in which case you could just choose a single UUID for the batch and append increasing values of a local counter to this.

TL;DR: This would actually work really well I think!

Isn't this exactly what the article suggests doing? Time stamp + user id + comment count.

My take on that comment was that it was not a subtle attack at all -- it was merely an observation that it's not a logical necessity for the leaders of a large country to be extroverts.

Indeed, that was my reasoning. I'm simply curious. It didn't even come into me to think of it as an attack. Any anti-communism or anti-introvert bias he might have read in my message is completely his own. I'm an introvert myself and I don't regard either capitalism or communism as evil in itself.

I may have been overreading into your comment. I tried to make my comment seem like I wasn't just assuming the worst of you, but it looks like I failed at that. My initial read of your comment was that it was just curiosity, but for some reason a second reading made me realize the 'oh noes! communism!' angle too.

In fact they did. They measured total task time for internalized versus externalized conditions. Contra your prediction, there wasn't a significant difference. Keep in mind this is one limited experiment so it's obviously not the final say, but it's always good to actually look at the data.

Thanks, you're quite right. Having now skimmed the paper "Does an interface with less assistance provoke more thoughtful behavior?", I would say that the measures of how many moves were made or remade, and how long was taken before the first move, are basically irrelevant, as the only quantities of genuine interest are how long the solution takes, and how well the subjects did on the questions afterwards. As you say, there was no significant difference in average solution time -- even though the low-NFC group did on average 19s better on the externalised version. Nor was there a statistically significant difference in either of the question types (although one type was close to favouring the internalised approach at p = 0.06). Maybe the other papers are more persuasive.

Just to clarify: are we talking about "learning the interface" plus "accomplishing task" here, or just "accomplishing task"? I'm pretty sure that e.g. unzipping your first archive with WinZip can be done more quickly than untarring your first archive with tar...

Both people had to learn to use an interface for scheduling speakers on a calendar GUI. Roughly speaking, in the externalized condition, more problem constraints were identifiable through visual feedback, while these were absent and had to be inferred in the internalized condition.

So, (in this paper), we're talking about planning versus relying on more external visual cues. Your WinZip versus tar example is apt, but it also introduces the issue of GUI versus CLI, which isn't addressed by the paper.