If you have a nuclear reaction that is going out of control, then you have to get it in control. Shutting the plant down would mean you don't have the ability to use things like the control rods to do this.

No, the control rods are constantly forced into the core by passive systems (hydraulic pressure, gravity, springs), and only stay withdrawn because of active systems. If the active systems lose power, a few seconds later the control rods will be fully inserted. Many reactors also have pre-pressurized tanks of neutron absorbing fluid connected to the core, a sort of liquid control rod. Provided one of the redundant valves can be opened, that will also quench the nuclear chain reaction. (And I wouldn't be surprised to learn that the valves have a ratchet that makes them stick open until some poor bastard visits them in person with a special tool.)

It's also worth pointing out that many safety systems have no self-protection features like circuit breakers, or even off switches where a well-meaning idiot might turn them off just because fire is shooting out. If a back-up cooling pump develops a short circuit or a bad bearing, it will continue to run until it destroys itself. The idea is that the protection equipment will cheerfully use itself up to protect the main plant.

The problem here is the forensic technicians. Every single one of them needs to be fired.

Indeed. With few exceptions, every scientific instrument that uses fluids is wildly inaccurate. (Precise as hell, but inaccurate.) That means pH meters, gas chromatographs, mass spectrometers, biomolecule sequencers, you name it. To get reliable measurements, you have to run an end-to-end calibration at least every few test runs. For ultra-trace detection, like DNA and high-potency drugs, often every single sample needs to be calibrated.

Failure to do this on such an epic level draws all results of all the labs into question. Even in an academic lab, getting caught at this would be a career limiting move.

This case is more like, if I ask you a question, you provide an answer, and then later I ask you the same question. You can't claim the 5th this time around, because you've already provided the answer.

Yes, you can. The 5th Amendment does not protect privacy or secrecy, it controls the actions that the government is allowed to take. The government can never compel incriminating testimony. Period. You can carve a murder admission onto a bailiff with an icepick one day, and then the next day refuse to repeat the statements and the government cannot compel you to.

If this were not the case, then any statement that merely suggested guilt would justify torture to extract all guilts. This is not melodrama. The Puritan exiles to America made this rule to prevent the system they were fleeing, a system where a minor infraction would be noted, and the defendant would be dragged before a court and asked to take an oath of total innocence. If they took the oath, the infraction was brought out and they, being guilty, were tortured to extract proof of all other guilts. Thanks to them, incriminating yourself does not grant the government one iota of power to extract further incrimination.

"No person ... shall be compelled in any criminal case to be a witness against himself ..."

The I-35 bridge collapsed because of a design flaw. (Mostly. The inspection engineers had a case of tunnel vision.)

You mean besides the Emergency Alert System, which is required by law to be supported by a wide variety of radio transmitters.

One of the more mind blowing things I read in 2008 was the discovery of a third type of visual receptor besides rods and cones. Essentially there's a third type of receptor that only detects sort of gross levels of light, and feeds directly into the system which regulates your circadian rhythm and is used for some other purposes.

Those are the photosensitive retinal ganglion cells. In addition to driving the circadian rhythm generators, they also control pupil size in response to light. IIRC, research in cats found that they do connect to the visual cortex, although how the signals are perceived is not yet known.

Let me try again less carelessly. Ideally you want the browser to automatically draw the sidebar just wide enough to fit its widest contents. But with divs alone, you have to specify a defined, hard-coded (I said "fixed" before, wrongly implying units of pixels--sorry) position for the content column. Therefore the left sidebar width has to be hard-coded too, which makes it hard to plug arbitrary widgets into it, especially images. The values may be hard-coded using friendly units like ems, but they are still hard coded.

Widths can also be defined as a percentage of the parent element. That tends to blow up sidebars when the window is narrow, and make ridiculous sidebars on super-widescreen monitors.

I want a LOLcoder picture of a CSS geek sitting at a computer using a pocket calculator with the caption "COMPUTING -- UR DOIN IT WRONG". Or maybe "SOMEWHERE A KNUTH IS CRYING".

I just don't get the relevance of "semantic correctness". Everything from the template to the user output terminal is pure presentation, a collection of practical tools to create output documents. If the implementation is comprehensible and maintainable, which it will be with judicious use of the technique I recommended above, then it is Plenty Good. Not a single piece of software anywhere in the chain cares one iota about the meaning or interpretation of table contents: it's just another rendering instruction.

I mean, really. Postscript is an entire Turing-complete language. People can and have written application software in it. (Maybe they shouldn't have, but they did!) Yet we all blithely crank out whatever garbage Postscript it takes to render our documents without a microscopic thought for the internal semantics. When's the last time you upbraided the secretary for not generating semantic Postscript? LaTeX lets you define your own semantics on the fly, but nobody gets too grumpy when you use unorthodox markup to make an interesting layout. So why the sudden semantic HTML religion? As far as I can tell, it's just a bad case of Silver Bullet Syndrome.

CSS is terrible at sharing horizontal space. Consider a two column page: a sidebar on the left aligned to the left of the page, an elastic-width content column on the right, and a fixed-width margin separating them.

With a table, the code looks like this:

<table class="bare-layout-table"><tr>
<td><div class="sidebar"><% sidebar %></div></td>
<td><div class="content"><% content %></div></td>
</tr></table>

Is that really so bad? All of what you normally consider style is set by CSS. The table is just there to position the content horizontally at sidebar right edge + margin, regardless of how wide the sidebar is at the moment.

If you use raw divs for this, then you have to lock the sidebar to a fixed width, and manually give the content a horizontal position. Every time the sidebar is resized, you have to pull out a pocket calculator and recalculate, looking up the desired margin from whatever non-machine-readable place you stashed it. This is not good engineering, it is guru full employment. It is X Windows modelines brought to the web.

float: left is not a solution either. Oh, it will seem to work for a few toy tests. But think what happens if the content ever gets so much as a single pixel wider than you hoped: it gets reflowed vertically below the sidebar to give it that extra pixel. The poor user is left staring at a blank space where the content should be. In the modern context of resizing fonts and single-pixel fixups in Javascript, this effect is almost to be triggered eventually, probably by a junior employee who cannot even recognize what they have done. Quite a number of major websites blow up in this fashion. One feels an urge to pat the designers on the head and take away their crayons.

That's what the grandparent comment means by "ugly" and "brittle". Good engineering is about making the computer automatically do the hard work, not following the "semantic markup" demagogues off a cliff. Even if it is a damn stylish cliff and all the cool kids are doing it.

CSS is pretty great for controlling typography**. Unfortunately, it provides no way to make block elements simply share horizontal space.

**But try indenting/outdenting your headings a certain number of ems when they use non-100% fonts. It's pocket calculator time. If you change the indent/outdent/percentages, you have to manually fix-up everything. Dammit, CSS! Learn some arithmetic!

Those are good points. I wonder what amount of template "power" would be optimal? Preventing changes outside the template's own variables would eliminate most mischief. Arithmetic is nice, and a major shortcoming of Django templates. Defining new classes is probably excessive.

Must stop designing ... new ... language ...

Many object systems let you assign a custom allocator for high-turnover classes. It is also common practice to keep a pool (or even a pool for each core) of pre-constructed objects (reusing freed objects in MRU order), rather than constantly be tearing down objects and building them back up from scratch. It's more an issue of folks not having experience with high-throughput design, rather than a problem with OOP.

Which is just a default, not a policy. Django templates are cleanly isolated from the rest of the framework, so any sensible Python template renderer can simply be plugged in. Here's an example of Cheetah templates being plugged into Django with a dozen lines of glue code. Mako looks like it would be trivial to plug in too.

What's wrong with jamming in some "lorem ipsums", fiddling until it renders prettily, then building the necessary view? You can dive in even before the models are built.

An even better property is that it forces the software engineer to separate the logic from the presentation, no laziness allowed. That makes it dead simple to reuse the logic for any number of presentation formats. For example, suppose you make a web page that shows a completed e-commerce purchase. With more templates and a few lines of glue code, the logic can be trivially reused to generate an e-mail copy of the order form, a .csv for the accounting system, a WAP version, shipping labels, a packing list, a PDF RMA label, and so forth.

This is critical for maintainability. With a typical PHP-like system, there is an almost irresistible temptation to copy-and-paste code to make multiple presentation documents, a recipe for unfixed bugs and version drift. This potential problem is why Django is very big on the DRY principle, Don't Repeat Yourself. And still it is not mandated, just a handy default that steps aside if you know better.