But this case is black and white, so cheerleading is appropriate.

How about instead of blanket statements we look at individual cases and cheer or scold based on merit?

This is all free speech. Some speech is bad (violent and obscene comments to a teenage girl) and some is good (her dad publicly shaming the perpetrators). Don't get all hand-wringy about dad's good speech, just because "oooo things could also be bad." This is the same inability to make obvious value judgments that gets us TSA agents taking away little old ladies' nail clippers because terrorists might do bad things, despite the fact grandma is clearly not a terrorist.

Double selection bias. People who are good at walking will tend to continue to do it for fun into older age. Meanwhile, while you're hiking, you tend to meet people who hike. Walking is of course great exercise, however. I have asthma and I'm a bit heavy but I'm a good walker, I can walk all day as long as the way isn't too steep.

Newton looked at the spectrum and saw that it contained six distinct colours to the human eye: red, orange, yellow, green, blue, purple. But his alchemist beliefs considered 7 to be a magic number and so wanted the spectrum to have seven colours. He decided that purple should be split into indigo and violet to reflect this, but didn't split any of the others (even where the difference is at least as pronounced) because it contradicted his mystical thinking.

If even Newton 'One of the smartest men to ever live' couldn't manage to keep his science separate from his mysticism, what hope do you think other religious people have?

No, sorry. A compiler is, in theoretical terms, a partial application of an interpreter to a program. In practical terms, a compiler transforms the input into some other form, which is then executed, whereas an interpreter executes the input directly. JIT compilation is still compilation. A just-in-time compiler is the term given to compilers that produce their output just before it is executed, as opposed to ahead-of-time (AoT) compilers, which produce it all up front, even if some paths are never executed.

There's some complication, because most environments that do JIT compilation also include interpreters that gather profiling information to incorporate into the JIT compiled code and to improve startup times. JavaScript implementations, in particular, often spend a reasonable amount of time in the interpreter because most web pages contain a load of JavaScript that's only run one or two times and the time taken to compile it is more than the time saved to execute it. Some have multiple compilers - JavaScriptCore from the WebKit project has an interpreter and three different JIT compilers that have different points in the space between compilation time and execution time - they'll recompile hot paths multiple times as they're executed more, with more optimisation each time. The key difference between the interpreter and compilers here is that the compilers are each invoked once on a segment of code and it's then executed without involving the compiler. The interpreter is involved every time the bytecode is run. It reads a bytecode and then jumps to the segment of interpreter code that executes it and then returns. The compiler takes a sequence of bytecodes, generates a fragment of native code to execute them, and then this fragment is combined with other fragments to produce a running program.

The shader compilers in drivers, however, are not JIT compilers. They are AoT compilers that are invoked at load time - often at install time. They don't compile the code just before it's run, they typically compile it once and cache the result for multiple invocations of the program. Some drivers (Windows and Android come to mind) have a mechanism that allows you to do the compilation at install time. Unlike most JIT environments, graphics drivers don't tend to use run-time profiling for optimisation, the bytecode exists solely for the purpose of providing an ISA-neutral distribution format.

Ugh, trust MS to fuck up a reasonable UI choice. On OS X, by default, it only happens for programs and requires you to close the dialog and then bring up the context menu for the program while holding a modifier key. You don't know how to do it unless you've actually read all of the way to the end of the dialog, so it generally protects people.

There are some interesting corner cases though, such as shell scripts. The file manager doesn't know if the thing that you tell it to open a shell script with is a text editor or a script interpreter, so may warn spuriously.

Is the key spacing the same as a standard piano keyboard? If not, how does it deviate?

Can it, in combination with some particular, commonly-available, MIDI software package(s), be programmed to have the same touch characteristics and sound as a piano, harpsichord, etc.? If so, are the configurtation parameters to produce equivalent performance already available?

Hmmm. While your explanation is unquestionably true, I don't think you quite understood what the poster was asking. His question is, I think, about the sharp shadows behind ridges on the surface, not the shadow of the vehicle itself.

I think his problem is an implicit assumption that if you drew a line from the center of the sun through the spacecraft, it would intersect the surface at a right angle. In that case you wouldn't expect cracks on the surface to display in such relief. However I believe that assumption is faulty, and that the rays of the sun intersect the surface at a considerable angle.

This is not unlike seeing the shadow of a plane you are riding in on the surface of the Earth. Unless you are in the tropics, that shadow won't be directly beneath you. It will be off to one side. It will also be distorted as it is spread out across the non-perpendicular surface, but you won't necessarily notice that because of foreshortening.

I once took over 30,000 lines of code that had been written by a subcontractor and trimmed it to around 4000 LOC. And you better believe it ran faster! Not because refactoring is magic, but because once all the mind-numbing almost-repetition was mucked out you could actually see what the code was doing and notice that a lot of it wasn't really necessary. Ever since then I have always maintained that coders should never ever copy and paste code. I've had people disagree, saying that a little bit of copying and pasting won't hurt, but I say if it's really such a little bit then you shouldn't mind re-typing it. Of course if you do that very soon you start putting more effort into devising ways to stop repeating yourself, which is exactly the point. Repeating yourself should be painful.

That's I think a reliable litmus test for whether you should refactor a piece of software. If it's an area of code that's been receiving a lot of maintenance, and you think you can reduce the size significantly (say by 1/3 or more) without loss of features or generality you should do it. If it's an area of code that's not taking up any maintenance time, or if you're adding speculative features nobody is asked for and the code will get larger or remain the same size, then you should leave it alone. It's almost common sense.

I don't see why anyone would think that refactoring for its own sake would necessarily improve anything. If an automotive engineer on a lark decided to redesign a transmission you wouldn't expect it to get magically better just because he fiddled with it. But if he had a specific and reasonable objective in the redesign that's a different situation. If you have a specific and sensible objective for reorganizing a piece of code, then it's reasonable to consider doing it.

Or bypass the problem completely by using a USB microphone. These digitize the audio right next to the microphone proper, with everything floating at the same voltage so nothing substantial is picked up betwen the air pressure sensor and the A-D converter.

Bluetooth headsets work great for this, too. Most current generation laptops already have the bluetooth central-role radio onboard. Or get a cheap low-profile bluetooth dongle.

4. PC/laptop microphones suck. I don't know why no one bothers to test them to the same level as your average cheap dumbphone speakerphone. They pick up all kinds of system electrical noise, ...

The problem usually isn't the microphone. It's the way it's wired (per the standard) and the way the desktop/laptop is powered.

PC microphones are wired UNbalanced: They have a signal and a ground wire, rather than the + and - signal wires and everything-but-desired-signal cancelation of the balanced wiring setups typical of professional microphones.

Laptops typically use power supplies that are not grounded, so they don't require a three-prong outlet. This usually ends up with the stray capacatance to BOTH sides of the line wiring capacitively coupling equally to the laptop "ground". That means the "ground" of the laptop is at half the line voltage - about 60 volts of AC (a rotten approximation of a sine wave plus lots of other junk it picked up at an assortment of frequencies). The capacitance is substantial - not enough to shock you if you touch the laptop and ground, but enough to feel a buzz if you rub your hand lightly across a "grounded" metallic part of the device.

Plug in the unblanced microphone and hold it, put the headset on your head, or just leave it sitting on the table. The "ground" is at 60V and you are driving maybe a couple MA of it down the shield wire. The voltage drop of that current (along with any other pickup) adds straight onto your audio input. The best microphone in the world will perform horribly if hooked up this way.

Try this: Unplug the laptop and let it run on battery. Notice how almost all of the noise disappears. You can also get rid of most of the noise by tying a decent ground onto the laptop. (Unfortunately, many meetings last longer than the laptop batteries...)

Plug in a VGA monitor with a three-prog power plug, which grounds the case of the laptop via the shield and the two hold-in screwd. I've done that without actually hooking up the monitor (which would have disabled my laptop screen) by adding a couple of the nuts scavenged from another DB connector as conductive spacers so the actual signal pins are not quite into the plug. And done this on a docking station, so the laptop headset was quieted when the laptop was docked, even though I used none of the docking station features except the power input.

Make a second cable with a three-prong plug to bring a ground up to the laptop. Green wire from the third pin to a screw into or clip onto such a chassis ground point.

Or bypass the problem completely by using a USB microphone. These digitize the audio right next to the microphone proper, with everything floating at the same voltage so nothing substantial is picked up betwen the air pressure sensor and the A-D converter.

from my blog on this, just now:

Proponents of refactoring have never ever said otherwise (unless they themselves are confused on the matter). Code is only readable if it is either simple, or clearly follows design patterns, or is clearly commented and the comments are up to date with the current version of the code. Code is only easy to change when it is readable and when all external dependencies are well known. That last part is a key thing that metrics aren't necessarily able to capture.

A refactoring project, if not refactoring to the right design patterns to address what was wrong with the structure in the first place, is not going to improve it. One must know clearly why the current structure is making a bug-fix or a new feature difficult to implement.

And while some refactorings are 'good' in that they reduce a lot of copy-paste code, others are good because they add code, or add classes (an alternative increase in complexity). Different refactorings have different effects, and are used in different situations.

And as always, if you don't need to refactor, don't. A refactoring is to improve the design, not to rewrite for its own sake.

And there-in lies the great flaw of the whole idea of such a study: you can't measure the quality of a software design. Some things you just have to judge for yourself, based on experience and attention, and no arbitrary metrics number will ever differentiate between a good design and a rubbish heap.

Disclaimer: I hate software metrics.

No, and get a load of that poor fucker's middle name. If my parents gave me a name like that, I'd set shit on fire, too.

No, more like that.

We hate ACs because AC is mostly used for trolling.

All you need to get a slashdot account is a throwaway email address.

If you have an account, then you become accountable: we can tell whether what you say today matches what you said yesterday. Absent that, we have every reason to believe that you are just some malicious asshole.

...and it's lucky I didn't expect it from you, or I might be upset now.