It's a bit of both. Some of the facts of the matter were known, but it was assumed that this was just "the way it was". That is, no one considered it an open problem. For instance, we view the inability to divide by zero just a fact of mathematics, not a flaw. Likewise, this was not known to be a flaw, it was just assumed that this was the way things worked.

If you need to point to a definitive flaw, it was in our understanding of how it was supposed to work - the relationship between our understanding and the notation. Once *that* flaw was discovered, the actual notation just spilled right out. That is, the flaw was that people were *not* treating dy/dx *sufficiently* as a fraction, due to 19th century preferences against infinitesimals. Once you realize that dy/dx really is a fraction, and has to be treated accordingly, everything automatically works.

It's almost humorous because there was no real advanced work to do. Literally everything needed is available in intro calculus. The problem was (a) the mathematics community had a habit of *not* treating dy/dx as a fraction, and (b) new students who didn't know better were simply taught *what* to do, not *why* to do it, and continued to repeat the mistake for over a century.

Thanks! I appreciate it. Given that this was my first peer-reviewed mathematics paper, I had no idea how long the process was. I submitted the paper over a *year* ago. The necessary changes were minor. But the actual time it took to go through the process was excruciating. I'm happy to finally be on the other side :)

Or it means "my sysadmins got bored and learned Python" or "sysadmins doesn't sound as cool as devops".

I actually noticed this trend about 8 years ago, and wrote a book to solve it. The book is called Programming from the Ground Up. It is a Linux-based assembly language book, but also teaches a lot about systems programming in general, but without being too technical.

For the other CS-oriented stuff that they don't teach, the two books you should get are how to design programs and Structure and Interpretation of Computer Programs. After that, I have written a series of articles to apply those ideas to "real" programming languages on IBM's developerWorks. You can find links to them here.

The problem with early detection is that many diseases are actually benign in their early stages, and, when detected, their detection can actually cause more harm for the patient. For instance, early cancer detection increases the likelihood that the patient will start chemo. Some cancers wind up being handled by the body, but *all* chemo treatments harm patients. So, early detection sometimes leads to more harm than benefit (plus an unfortunate issue with "success" rates - the cancer treatments get to include in their "success" count cancers that the body would have cleaned up anyway).

"Or are those contracts written so horribly that the company gets paid for a nonfunctional product?"

The problem is that a lot of these types of contracts are written with a clause such that launching them publicly is an implicit acceptance of the project as a finished product. So, since they at least tried to launch it, that means that the project is "finished", and everything else is billed hourly on top of it.

It has been over a decade since I last worked with Oracle, so things may have changed. But when I worked on an Oracle project, it cost a huge amount of money, took way too long, didn't work well, and required double the number of staff to manage the application. After Oracle left, a second company came along behind who specializes in fixing stuff that Oracle broke. This company, I don't remember its name, literally does its business as cleaning up Oracle's trash. They didn't even promise good results, only "I know how much pain you are in, we'll make it not hurt quite so much." Interestingly, this particular project wound up as a "success story" on Oracle's website.

Must be nice to be able to fail at a project such that they owed you $69 million, but you don't actually have to make it work.

Perhaps states should make a rule stating that large projects must be broken up into deliverables of $1 million increments.

I know everyone wants an electronic everything, but it sounds like in your situation paper records may actually be optimal. If you have to have a paper system in place anyway, why do the added expense of going digital as well? Sometimes, what is really needed is to optimize the paper system, rather than replace it with an electronic one.

iCloud is a useless service. It intended to compete with DropBox, I think, and failed miserably. I think iOS developers should all individually opt to develop for DropBox rather than iCloud.

AWS has actually been pretty good if you actually do a proper deployment. I can only think of one time when they had multiple availability zones down at the same time. If you don't deploy across multiple availability zones, then it is just like any other hosted service. I often use it that way, too, it just isn't the magic fix-it-all system if you don't use it like it is intended.

It will be interesting to see how effective this is. DNA is not the sole source of information for an organism's morphology. Nuclear transfer has shown some traits which are not dependent on DNA. It will be very interesting to compare the morphology of the final organism to the original, extinct species.

By "creating a LotR visualization tool", does that mean they have cloned Peter Jackson?