JMostert

Which is why no other browser does anything with it, which is why it works so nicely.

The only drawback is that it doesn't validate. You can either wrap it in a conditional comment or incur the wrath of the standardistas and leave it be.

"If anything, cancer resistance (which would probably mean less cell mutation ability) would be disadvantageous from an evolution standpoint because you would have less variation and consequently may have trouble adapting."

Evolution doesn't work that way. It doesn't favor mutation because mutation is "good" for evolution. You have to look at it from individual genes, and there the story is just the opposite.

Evolution happens in spite of, not because of genetic predisposition to mutation, because it's vastly more likely for a mutation to be pointless or harmful than beneficial. If you have a gene that makes mutation in the genepool overall less likely, that gene will be more successful at spreading itself, because the mutants have, on the whole, far less chance of success than the originals (which have already proven their worth in a long chain of ancestor individuals carrying them). Of course every so often a mutant gets lucky and is more successful (or at least not less successful) than the original -- this is what selection is all about -- but statistics are against them.

To elaborate your scenario: suppose the environment changed very rapidly, and adaptation in some direction were necessary to survive it. If by some stroke of luck a gene that increased the mutation rate happened to be there at that moment, defying the odds, it would find a favorable environment, but only for as long as the rapid change is required. Generalizing this: a successful genepool is one where the mutation rate is "just right" for adapting to the environment. Too much mutation and the genepool isn't stable and will eliminate itself, too little mutation and the genepool will be eliminated by the environment. In this balance, the odds are stacked in favor of avoiding mutation.

And all this is orthogonal to the discussion of how cancer (the uncontrolled reproduction of cells) is related to the capacity for mutations (infidelity in the copying process). Cancer resistance and mutation resistance are related, but by no means the same thing. To borrow a computer image: your computer has copy processes with very high fidelity (only the occasional alpha particle to spoil the fun) but this doesn't protect it against worms, which copy themselves unwantedly but with the same high fidelity. This analogy is badly flawed in obvious ways (regular programs are not designed to copy themselves, cells are), but I hope it gets the point across.

The stark irony of this is, of course, that very few games on the Commodore 64 used or required BASIC, and certainly none of the popular ones. BASIC games where the first generation, before people mastered assembly. Some games may make proficient use of internal BASIC routines, but most will bank the BASIC ROM out of sight and never look back. Without BASIC, you won't get that READY. prompt and you can't enter LOAD "* ", 8, 1, but that hardly seems an obstacle.

The simple fact of the matter is that any emulator, or for that matter any programming environment that can be used to create one will allow users to run "illegal copies of games" (though with slowdown that could be crippling, admitted). They should ban emulators altogether, and anything that even smells like custom code execution (subject to Apple's discretion, of course). I propose "applications may not supply a Turing-complete environment to users", though regrettably this may mean spreadsheets and anything using macros may have to get the axe as well...

Interestingly, neither the original image nor the manipulated one can be called racist. The trouble only comes from realizing we're looking at a before and after.

Microsoft generally goes to great lengths to ensure people are not offended. It has to, because of the sheer size and diversity of its markets. Raymond Chen has blogged about one apparently innocuous issue [http://blogs.msdn.com/oldnewthing/archive/2003/08/22/54679.a...], and there must have been many, many more across Microsoft products.

Marketing works better if you reflect your audience's tastes. Doubtlessly someone calculated that the other image better suited Polish tastes, for which a racially diverse cast only serves as a vivid reminder that the image was marketed for an American audience. This doesn't make either the Poles or the marketing racist. The only thing "racist" was the mistake to clumsily manipulate an existing image instead of using a brand new one. Penny wise, pound foolish.

The perils of DRM were no different back then, except that the term hadn't been coined yet.

I remember disassembling and working around the tape loader for a game on my C64 just so I could copy it to disk. I had no intention of sharing it with anybody, I just wanted to get around the atrocious loading times.

Today I download cracks for the games I buy (no need to write them yourself anymore) so I can run them without needing to have the DVD inserted. The more things change, the more they stay the same.

> Yes, I did. Does it hurt to offer a different perspective?

No, I was questioning whether you had considered his arguments at all, given the "why do we start counting at 0" question which he tried to answer.

> I didn't make a case that 0 was odd, I asked how I should look at it: as element 0, or as the first element.

You can look at it either way, as both are correct.

> If you look at it as element 0, the first element of the vector is an even element. If, on the other hand, you look at it as the first element, you will think it is an odd element.

Ah, I see your point now. To me this wouldn't be a question because everyone knows programmers start counting at 0 -- a machine instruction would operate on indexes, not ordinals. "The first element" is the element with index 0. It is not "element number one", or if you do want to see it that way, "number one" is the ordinal you use when you start counting on your fingers, which is something we deliberately ignore.

Did you read Dijkstra's article? He's making the case for 0, though he's doing it a little abstractly. Simply put, if you start numbering at 1, you are setting yourself up for more boundary problems and off-by-one errors than if you start at 0 (and by extension, inclusive lower bounds and exclusive upper bounds). That's not to say that some algorithms are not in fact easier expressed by numbering things from 1, just that they're not the majority.

Oh, and obviously 0 is even. Why? Because 0 mod 2 = 0, 0 is evenly divided by 2, and that's what "even" means. If you need more intuition, though: 1 is indisputably odd, and even and odd numbers alternate, so 0 is even. The rest is philosophy -- you can probably find definitions for "odd" and "even" where 0 is a problem. That's fine, but those don't help. Ignore them. Mathematically there's no problem whatsoever.

The trickiness only comes if you insist in thinking in terms of "the first element", rather than "element number 0". Some people use "zeroth", but this seems to invite more confusion because it induces two meanings for all the other ordinal forms -- if there's a zeroth element, does that mean the "first" element is in fact the second element? Best to avoid ordinals altogether -- you usually don't need any more than "first" and "last" anyway.

I feel like some qualification is in order. I can't make any excuses for SOAP (maybe someone else wants to take that up), but COM, at its core, is indeed a simple and dare I even say elegant technology. COM is alive and well on Windows, because it still serves a basic need (cross-language binary interop) and it does so well.

The problem is that COM just couldn't stay simple -- the basic idea of querying an object for reference-counted interfaces was quickly buried under incomprehensible layers of pUnkOuter and IMoniker and apartment states and OLE activation sites and god knows what other stuff that you have to know about but doesn't help you getting work done.

I've seen people who can get carried away adding layers of stuff to something simple and beautiful without ever realizing that it stopped being simple and beautiful quite a while ago, because they still understand everything. Boiling frog design, if you will. I don't know Don Box well enough to tell if he's one of those people, but COM and related technologies seem to have seen a lot of that crowd.

Good advice from the irrepressible Dijkstra on this matter: "Before embarking on an ambitious project, try to kill it." (http://www.cs.utexas.edu/users/EWD/ewd10xx/EWD1055A.PDF)

If you try honestly and still fail to kill it completely, whatever's left that you can't kill because it seems doable right now is one way to go.

Funny that he has this under "Signs that you shouldn't be a programmer": "you think the presence of code in a program will affect its runtime behavior, even if it is never invoked".

Anyone who has written code in C can probably cite an anecdote where exactly this was the case, be it from a compiler bug or as fallout from a memory corruption bug.

Maybe we should add "does not understand the von Neumann architecture" to the list of signs that you're a mediocre programmer... On second thought, let's not -- the piece is bad enough to begin with. The "alternative careers" sections are just odious, and the whole thing breathes an air of inconstructiveness.

It's quite possible there is none, and they're independent "inventions". There aren't that many four-letter words composed of hex digits (by my reckoning, the only common ones are BABE, BEAD, BEEF, CAFE, DADA, DEAD, DEAF, DEED, FACE, FADE and FEED), and stringing two together to get a magic number must be a popular pastime. In fact, Wikipedia has a list of them at http://en.wikipedia.org/wiki/Magic_number_%28programming%29 under "magic debug values", which demonstrates that 1337 can get you some more.

It's what bensummers said above: it's not whether MySQL on Windows is a good idea at all, it's why MySQL management implies that it is by claiming to support it.

You're probably right that there's no technical reason to use MySQL on Windows, so the only reasons left are management reasons ("our code monkeys can install whatever they like as long as it's on our trusted Windows (tm) machines"). This explains why the technical support for MySQL on Windows sucks, while the management support is prominent...

Does that matter? Those users who do care should get the support they can expect if management claims to be committed to Windows, regardless of how many they are. It's a simple matter of putting your money where your mouth is: if you care, you make sure you have people who can support Windows and like to take responsibility to bring it up to par with the other platforms, otherwise you make it clear that Windows is a second-class citizen and you should be prepared to get a poorer-quality product with less support.

From a short-term management perspective it seems better to have just the promise of support than to have nothing at all, but in the long term you're sending a signal that MySQL on Windows isn't to be taken seriously, and that you don't want people who are committed to Windows as customers. That's as fine a business decision as any, but then it's cheaper to cut out Windows development altogether than to go about it halfheartedly.

There's one argument in there that's semi-sensible: in case of a power outage, it would seem important for the police to be able to continue processing data. Yes, aggregates help, but keeping everyone's desktop computer running isn't as effective as limiting it to critical systems (and extended power outages shouldn't be crippling either). The good old pen and paper will only take you so far, especially with the atrocious handwriting of people these days (accustomed as we are to mashing buttons of all shapes and sizes for communicating).

To use them in the day-to-day business seems foolish, because most of it could be far better handled electronically. But considering the massive amount of paper and toner bureaucracies waste printing out information because the business processes don't evolve along, switching to such a system isn't necessarily an improvement in the short term. And of course there's a very significant initial cost that will be harder to justify to management than just maintaining the old system. Many and unsubtle are the stories of IT systems that are built to replace an existing "analog" process which end up delayed, inefficient, feature-crippled and way over budget. This is the sort of inglorious government-budgeted project that's especially prone to attract overpaid, unmotivated bunglers (no offense to the underpaid, highly-motivated geniuses out there working on such systems :-)

Whether the $0.5-$1M budget is warranted is another matter. The argument that they have a $4B total budget will sooner make people question whether the $4B is entirely needed than reassure them that the typewriters only take up a minuscule fragment of said budget. This also doesn't factor in the very real but hidden cost in terms of time and frustration for the users -- imagine the police department using no computers or typewriters at all, but requiring that all information exchange go through hand-written forms. The ballpen budget might be very small, but personnel costs would balloon.

Now, let me tell you about this voice recognition software I've been working on...

You're kidding, right? Obsessing over (potential) micro-optimizations is a timeless programmer pastime. It will never go away.

Imagine something worse: suppose it had made a difference, in the current iteration of the compiler and the framework. Can you imagine the damage done by people who will now spread the word that "you must write the empty string this way and not that way", which would then continue to waste time forever, even after it's been rendered irrelevant?

This issue always arises when a language gives you two (or more) ways of accomplishing the same thing: naturally people will want to know which is the best way. Best in what aspect? Well, performance is the easiest one to objectively evaluate, so let's go with that. Cue an endless stream of benchmarks and criticism of said benchmarks, and very little reflection on how much it actually matters in terms of both programmer and user productivity.

I still crack up every time I see the "master programmer" part, which uses COM. The joke here is the ridiculous overhead that the COM boilerplate is putting in isn't even exaggerated -- most of this stuff would actually feature in a real-world program. (Of course, in a real-world program it would be a relatively smaller.)