Maybe they should outlaw death as well.

Whether or not you want to trust a card given by the government is one thing.

But if the government actively encourages people to encrypt stuff then there is greater awareness of privacy and encryption. It means that more people understand the concept of private/public keys and are more likely to generate their own keys and use them. They're also no afraid of encryption as a concept (and a question such as "how do I ask for their public key without sounding like a geek" doesn't exist). I think that's a positive thing.

Other countries actively discourage privacy - yes, you can encrypt stuff, but if you don't give us the password then you'll end up in jail and we don't have to prove a thing. And why teach the masses to encrypt? It's so much easier listening to communication in the clear, and we can even perpetuate the notion that if you encrypt your files or communication then you're clearly hiding something and you're probably a dangerous criminal/terrorist/paedophile, because normal people don't use encryption.

I'm wondering about the mainframe comment: does it mean that bug-free software was only ever written for mainframes? Because I'm absolutely 100% convinced that not all the software that runs on mainframes is bug-free, having worked on mainframes. Even IBM COBOL compilers had (have?) bugs, and they must have been tested by thousands of businesses.

The reason is that for software to be perfect it has to be either proven or checked against every possible input.

The first may be possible in some cases, but is very time consuming for anything other than trivial exercises (and almost no one is willing to pay for that).
The second is simply impossible and some "representative subset" must be used for testing. This means that the once-in-a-lifetime case could be missed.

The car analogy doesn't work here.

So what happens now with last minute customer requirement changes? I'm really trying to understand this (and hopefully learn from this).
If you have to push them in anyway, then you're still working to crazy deadlines.
And if you don't have to push them in, couldn't you have said "no" before moving to Agile? How did moving to Agile change your relationship with the customer?

That's one possibility. Another is that whatever is supposed to be The One True Agile (tm) requires certain pre-conditions that aren't always met.

I could say "don't blame the single-pass waterfall process - if it failed for you, then you're doing it wrong". In some (rare) cases, single-pass waterfall is exactly right - a single programmer implementing a rigid specification (for example writing an H.264 decoder). But that's a pre-condition. It won't always fail and it won't always work, just like "Agile" or any other "methodology".

The truth is that there's no silver bullet. Every set of guidelines also includes a set of conditions (implicit or explicit). For example, most software development processes assume that the programmers involved are not all back-stabbing psychos. But even that's not always the case. Blaming reality for the failure of a process is the wrong way around.

The one consistent thing about Agile: "you're doing it wrong". I have never seen a different answer to any complaint about Agile.

I'm pretty sure you're right.

I hardly pay attention to most of what I read online, especially when I'm on LinkedIn (I'm trying not to look at adverts, so I miss the content as well).

I found myself once entering my LinkedIn password into some "password" input box, which, as I wasn't paying much attention, I thought was LinkedIn's "your session has expired". However, it rejected the password, which made me look again. I was entering my password into the "we've got your email address, now just give us the password" box. As I have different passwords for different things, no problem. But I'm sure that some people use the same password for everything, and suddenly LinkedIn sends an email to every contact on their gmail account.

Yes, I vaguely remember a time when "screensaver" wasn't an official synonym for "a zombie-making, disk encrypting, key logging trojan".

What does it even mean? NP is the class of problems that can be decided using a non-deterministic Turing machine in polynomial time.
"Polynomial time" refers to the class of algorithms that run in O(n^c) where c is a constant.
The "n" in O(n^c) refers to the size of the input. Big-O notation is only meaningful when talking about asymptotic behaviour (as n approaches infinity).

But chess is a given, specific problem, where n=8 (let's say), and there is no asymptotic behaviour anywhere. N is always the same - it's a specific problem, with a specific input size. So talking about NP in relation to chess is simply meaningless. It's only relevant to chess on an NxN board, but who plays THAT? (and more importantly, how many computer programs play NxN chess? What are the rules? How many bishops are there on the NxN board?)

It's easier to answer "why didn't you do <the right thing>?" than "why did you do <the wrong thing>?". In most cases, "we didn't have enough information at the time" is good enough for the former, whereas it takes a lot more effort to explain the latter.

An entrepreneur only has to answer "where's my money?" (if s/he's playing with someone else's money), but doesn't have to justify each and every decision.

That should be the discussion part of the interview.

In your code you calculate mod(i,3) twice for every number. You also calculate mod(i,5) twice in cases where mod(i,3) is zero (33 times).
In total, you have 2 * 100 + 1 * 100 + 1 * 33 modulo calculations (333 expensive operations).

The code you called "inelegant" calculates mod(i.15) for every number (100 in all). It then calculates mod(i,5) for those that failed the test (94 cases) and mod(i,3) for those that failed the second test (80 cases). In all, it performs 100 + 94 + 80 = 274 expensive operations. So his code will be about 17% faster than yours.

You also call "print" more times (instead of 100 times, you call it 200 times - once for the number/string and once for the end of line).

I won't argue whether it's more elegant or not (that's a bit subjective), but it's just as readable and definitely faster.

It was worth scrolling all this way to learn something new. Thanks!

You'd be amazed what APL can do in a single line.
I wouldn't like to read 50,000 lines of it, though.

But how can a company buy assets if it doesn't have any money? Oh, sorry, of course it does, because it has income which is generated from selling things to customers. So why shouldn't it pay income tax on its income? Ah, because it's an abstract entity that should not pay tax (as the post I replied to suggested).

Alternatively, if companies don't pay taxes, they shouldn't enjoy benefits such as protection of laws or electricity provided by infrastructure that is paid for by taxes. Why should the general public pay the salaries of lawmakers if they're going to pass laws in favour of companies that don't pay taxes?

The concept of a corporation was invented to allow a group of people to shift the risk of enterprise into an abstract entity. But just because it's an abstract entity doesn't mean that it's not part of the economy.