So they would follow the Prime Directive and avoid letting us know about them, except when a randy captain decides to come and have sex with our women.

Damned unions.

Yes, an overarching narrative is very important. If you're using something like Javadoc or Doxygen, the documentation comments are a fair place for it, but what's often even better is to put it in a design doc, which should be linked from or stored with the code. Design documents also get outdated and become wrong if not maintained, but they should be at a sufficiently high level that this happens very slowly.

AFAICT, that's all about telcos. None of it implicates the companies involved in this effort. The closest is that Snowden reports the NSA compensated some companies for money they spent supporting changes to the PRISM system, but that was just a one-time offsetting of expenses, not providing a profitable revenue stream.

I still don't see any support for your claim. Is there something specific you can reference which provides a more solid basis for it?

We have clear evidence that the NSA lied, but AFAICT none that any of the corporations involved in this effort have lied. In fact, it appears that not even the telcos -- who have admitted to handing over huge quantities of data without any legal obligation to do so -- have lied. The telcos did keep quiet until they were outed, but then immediately admitted it once the knowledge was public.

So, to what lies are you referring?

Cite?

Pick one. Start with Google, if you like.

That's a very bad habit, and one that you should break. Comments are evil. They are occasionally -- very occasionally -- a necessary evil, but still evil. I'll explain below.

Absolutely, you want your code to be extremely easy to understand. In fact, that's the #1 goal, even ahead of doing the correct thing, because bugs are more likely to get fixed than unreadability, and in the long run they cost less. Comments are one way of achieving readability, but they're a crutch. Worse, they're a crutch with a built-in time bomb.

The problem with comments is that they're wrong, and they mislead the next poor programmer.

They're usually approximately correct (though rarely exactly correct) when written, but they tend inevitably towards inaccuracy as time goes on, because the code will eventually get changed, while the comments may or may not get updated to stay current. If maintainers assiduously update the relevant comments every time they change the code, then the comments stay (approximately) correct, but at the expense of requiring that additional effort by the maintainers. If someone doesn't bother to update the comments, it gets bad.

On the other hand, code that is readable without comments doesn't increase the maintenance burden and has the fantastically valuable characteristic of always being correct. Comments can be wrong about what the code does, but the code is never wrong. It may not do what is desired, but what it says is what it does (barring compiler and hardware bugs, but that's a separate problem).

I should clarify here that I'm talking about comments intended for maintainers. I have no issue with Doxygen/Javadoc/etc. comments that are used to generate documentation. They're just as error-prone, but they provide enough additional value -- in the form of the generated documentation -- that they're worth the risk and the cost. They're written, not for future readers of the code, but for future programmers who may be able to avoid reading the code.

Comments that are written for future readers of the code, however, are a code smell. They're not absolutely bad, but any time I see a comment embedded in code, it's an indicator that there's a good chance the author should have put some more time in, finding ways to make the code readable without the comment. Actually, I tend to write lots and lots of comments in my code while I'm building it, outlining the functionality I'm going to write before I write it, explaining why it's there and what it's goal is. But as I implement it, I read each section of code to decide if it's sufficiently clear that I can remove the comment. If not, I refactor until it is. In very rare cases I find that there is simply no way to make it clear without a comment, generally because there are very subtle constraints on the code which cannot be expressed in the code. Those cases are rare.

Often it's just a matter of taking a block of code with an explanatory comment at the top and factoring it out into a subroutine, with a well-chosen name that expresses what the comment used to say. If you find there's no such name that isn't a dozen words long, you need to go farther and restructure. In many cases you can eliminate comments just by adding some variables in which to place intermediate results of a calculation -- variables with well-chosen names that express what the business meaning of that intermediate result is, generally including its units, except where they're obvious (which is less often than you might think). Function/method names, variable names, class names, etc. are how you can make the meaning and purpose of your code clear without requiring comments.

I strongly encourage you to give this a try. Begin looking at the comments in your code as a bad thing, and look for ways to refactor the code so that it's just as clear (or clearer!) without the comments as it was with them. It made my code better (I used to be a heavy commenter), and I guarantee it'll improve yours as well.

Hmm. I always thought assembly language was the input and the assembler was the tool. However, I turned to Wikipedia for support and found that usage is inconsistent.

Ah, but a Real FORTRAN programmer can write FORTRAN in any language. You ain't see nothing until you've seen a payroll system written in FORTRAN... using COBOL.

Irony so thick you can cut it with a knife.

+1

I didn't know a soul at my current employer when I got the job. Nor at the last employer. Come to think of it, I haven't known anyone at any of my employers until after I started working there.

Did you not notice my reference to a "road right into massive surveillance hell"?

See, still putting the cart before the horse.

Also, your characterization of illegal immigrants as criminals is factually incorrect in most cases. It isn't a crime to enter the United States without permission (there is one illegal immigration-related criminal statute, but it doesn't apply to the vast majority of illegal immigrants).