I think all first year computer science / programming / engineering students should be introduced to this and learn how to write programs for this environment first before moving on to modern systems. True power is being able to write useful stuff with only 64kb of ram and 1mhz of processor, and have it run in an acceptable time frame, and taking those skills and scaling up today's multi-core/ multi-gigahertz/multi-gigabyte address spaces.
While I agree, I wonder if this is actually true. To what extend does knowledge about efficient coding on an 8 bit machine with limited memory teach us anything about programming these heftier CPUs? Maybe the only people that should really have chewed the bits are the writers of compilers. For all others it might not matter so much how the compiler and the OS handle memory allocations and the like, and it may be more useful to focus on the program structure instead of the implementation on the CPU.
Could sophisticated military tanks and anti-aircraft missiles given or sold to countries like Iraq be equipped with a way to disable them if they're compromised, without opening them up to hacking by an enemy?
A tank with a kill switch?
On topic: who would buy such a device that can be disabled by others? And even if it is made for the "domestic" market: why be at risk that someone else hacks into your own stuff and disables it? The solution to this problem wasn't technical, but political.
Even if I were to never even look at a single line of the source, the fact that it's availble to others adds value for me. I can go download a patch someone else wrote that fixes a bug MS hasn't bothered to fix. [...]
I am also in favour of Open source myself and get your point. However, after the OpenSSL bug, my belief in this "someone else" has significantly lowered. If too many people rely on "someone else" fixing a problem in his/her spare time you are worse off than when people are paid to fix closed source software. If the problem is important ($$$) enough, it wil be fixed.
No discussion on one point, though: the slide keyboard made it more vulnerable and eventually it broke down on me, after intensive use. On the other hand: its 512 MB internal memory was also becoming a hurdle, so one year later I would have needed to replace it anyway.
They can understand how a toilet is cleaned, how a sale is made, how a 1099 is filled out, how a fire drill works, how a sandwich is put together, how oil is changed, etc... but Coding might as well be a dark art.
Disclaimer: I am in hardware myself and may completely miss the point here. However, our software/firmware folks do agile programming involving dividing programming problems into pieces which are assigned to programmers, followed-up on large whiteboards and being daily discussed in "scrum meetings" etc. (I may be confusing some concepts here but that is of less importance). The point being that your statement, that programming is some sort of unique dark-art-which-cannot-be-measured-by-managers, appears untrue to me and, honestly, rather pedantic. What these guys are doing is quite measurable. Maybe not by a silly measure like "lines of code", but by the measure of number of problems being solved, having a complexity that apparently everyone of them agrees on.
Indeed, the CEO doesn't know the exact details of how this works, but neither does he personally count the number of cleaned toilets.
That has nothing to do with sloppyness. If you know how to teach writing, publish a book and harvest a noble price. (Strictly speaking, that should be spelled Nobel, as that was his name).
Then why don't you write Nobel prize in the first place? Your comment, on how bad writing should not be contributed to sloppiness is the first time I ever encounter this "noble prize". Also, "Strictly speaking" is completely out of place here. "Strictly speaking" we should also refer to "Murphy's law" and "Newton's law" instead of "muphries law" and "netwon's law", which no-one ever does anyway.