You are both wrong!

"Lets revisit this in 5 years..."

You must be English or Greek! Successful Germans don't make that type of distinction between present and future - apparently it's how they stay so successful!

AFAIK there is no completely watertight transaction protocol (?)

Couldn't it always be claimed that a technical error is responsible for resulting in two copies?

If the sender then finds the file still on their system, perhaps it could be argued they should remove rather than play the file. But could they not just as well assume that the transfer must have been unsuccessful (otherwise the file should be gone)? And so reasonably assuming they are in the in possession of the only copy, they should be able to play the file.

If they have sold the file to the receiver, perhaps they should then go on to return the money, and at that point it would be discovered, one might think, that both parties had the file. At this point the matter could be expected to be resolved, so that only one of them had access to the file (by the other deleting their copy). But what if the file was given away? The sender might not care to attempt to resend the file if it was of no high importance and would have no reason to believe that their file protocols had behaved such that they ended up with two copies.

What if someone decided they did not like some intellectual property they bought and wanted to give it away to first taker on the Internet, but some transaction protocol screwed up so that a thousand people were able to download it before it was removed from the server? Nobody realizes anything went wrong and the file now exists in thousands of copies. In the end, how can it be assumed anyone did not get their copy of any file by an anonymous stranger giving it away over the Internet because they did not want it themselves and could not be bothered to sell it?

Well, there are software licenses that work basically like that. Usually they involve some kind of shenanigans to make sure over the network that you don't use them simultaneously, but that only underlines that the principle of such sharing schemes as you suggest should be thinkable.

According to the Swedish newspaper Expressen, at least one of the founders (Mr Neij), currently living in Bangkok, does not intend to evade his sentence.

http://www.expressen.se/nyheter/1.2696506/hovrattens-pirate-bay-domar-star-fast

Google translate:

"Fredrik Neij now lives in Bangkok and he is disappointed with the HD's ruling. But he will not stay out of the sentence.
- But I'll probably try to get the punishment commuted, perhaps to electronic tagging or so, says Neij told TT."

It is bricked.

What if the accused claims the encrypted drive contains the proof of his innocence and he desires nothing higher than to provide the court with the password but regrets that the shock of his arrest and subsequent stress of the trial has rendered him unable to recall his password?

Careful what you wish for..."Congratulations! Your new sowing machine comes with no instructions whatsoever in accordance with the principles of 'self documenting design', which means that its designers understand how to use it."

But that implies that the arraysearch function would also contain the code to run when a match is found in the array, which breaks the rule of least surprise.

Perhaps simply:

if(arraysearch(array, value)){
//code to execute when item is found.
} else {
//code to execute when item is not found.
}

It can if you reapply the trick of staring hard enough at the experiment output until you see the desired result.

Well explained. I'dd only add something about where each of them fits. Roughly, to the best of my experience, Online Transactional Processing is for supporting business activity such as when customers place orders. The order is recorded first in the OLTP database for being processed by shipment systems etc. When the order is completed it is often deleted from the OLTP database that should be kept small and nimble to be able to keep up with incoming orders in a fast and responsive way. The OLTP database, as mentioned, is highly normalized (each item in the data is saved in only one place). This is to some extent to keep the database small but also to ensure consistency in the critical business data (when the same data is saved in two places it risks getting out of synch, perhaps leading to things like orders being shipped twice etc). For the same reason of consistency it is also important that all work is encapsulated in transactions. Transactions are a way to ask that several changes to the databases that go together logically for some business reason be done in an all-or-nothing fashion. For example, all the data changes to the database associated with, say, an order being placed can be saved to the database as a unit such that if all goes well all the data is saved but if any of the data changes for the order is met with an error none of the changes in the unit should be accepted into the database (thus the "Transactional" in OLTP).

A copy of the order is also saved to the Online Analytical Processing database, where is does typically not become deleted so soon and its data may be saved redundantly in multiple copies (denormalization) to speed up queries. The purpose of this database is not to support customers placing orders, but to support managers asking questions about "what is historically our most popular shoe color in December" and things like that (the "Analysis" in OLAP).

No, he would have spent three hours searching his house until he found his old DVD (at least that's what I would have done and I took it to be what GP meant) if the pirate bay option had not been there. There would never have been any more money going to the game company or anyone else, only a net productivity loss (three wasted hours) to the benefit of absolutely no-one.

if($sense == $it_is_a_little_bit_complicated){ // explain why here
};

If I started coding today I think I would go about it roughly thusly:

1) google "Game coding tutorial HTML5" or similar,
2) Find the code listings, run them, modify them a little to see what happens but eventually be annoyed that I don't really know what the magic incantations in javascript etc mean
3) Google "javascript introduction" and spend some time just writing "Hello world" apps and such, trying to learn basic javascript, until I got bored with that.
4) Return to the game code, be absolutely gratified by discovering I indeed understand a little more of the magic incantations, do a bit more targeted modifications of the code to see if I can actually predict the outcomes at all....until I got bored with what I could do with my current level of understanding and return to the course in basic javascript to learn more (repeat from 3, basically). At some point you may know so much general javascript that you can continue learning more about javascript itself by looking directly at the game code and realize how it must work.

As long as you find some little "loop" like that where you actually have fun all the time while learning, chances are good you will end up knowing quite a lot about how to program.

But what if it leads to few of the College trained developers you hire being able to code their way out of a wet paper bag precisely because before they enrolled they had already been coding as a hobby for years, an interest that was initially sparked by an online javascript course?