I have done 10 to 15 hours straight on a project, and been wiped after that, but the most interesting time I was working with two other guys to redesign/redo a program in Smalltalk. We were essentially doing triples programming and we found that 6 hours was just about all we could handle. 3 hours in the morning, lunch, 3 hours in the afternoon and then we were basically wiped. After that we could do email or other unrelated things, but not programming.

The level of concentration in that effort was as high as I've achieved -- we were in the unusual position of basically knowing everything we needed to know, so we didn't need to spend time investigating this API or that library or what the requirements were -- we could focus on exploring the design space, implementing and testing.

It was exhilarating but exhausting.

NOT! -- or rather, SO WHAT?

Let's, for the moment, assume you have a combined hardware and software system that have both been mathematically proved correct. Presume the proof was completed at Noon on 1 Jan, 2010. The particular hardware and software so proved is then installed in a vehicle and driven for 50,000 km throughout the USA -- through rain, snow, desert heat, etc -- and is involved in several minor impacts (backed into a tree, jumped a curb)...
In that process salted water is splashed throughout the engine compartment, one dog got carsick, a kid dropped a coke and it splashed under the seat, Dad dropped a cup of coffee under the same seat, the windows were accidentally left open during a rainstorm, a total of 10,000 km was driven with a smoker in the car, and the car was taken to the "detailer" 5 times, where they sprayed various cleansers on the vinyl surfaces (and into the air), etc.

A lot of those events can have impacted the hardware that was proved correct before Noon on 1 Jan, 2010. Corrosives in the air, moisture, dust, yukky liquids, etc.

Is that proof relevant to the system at the end of that period?

Fact is, the real world may be modeled by a mathematical system, but it is, itself, not a mathematical system. The mathematical system may be incapable of failure, but the physical system still may fail.

To me it seems bizarre that in 2010 we are using electronic document preparation software -- MS Word, for instance -- to prepare a document. We then [print it,] fax it, [scan it,] and feed it to optical character recognition software in order to get it back into some semblance of the original, probably with a few extra errors caused by the low fidelity of faxes.

Is it really not possible to use email for document transmission?

I agree -- thinking about it, I realized it's probably a problem with almost any control system. Essentially tweaking the speed button is generating an error signal which the system tries to zero, but there's a delay involved (takes time to accelerate). If you keep increasing the error signal, it will keep trying to match. If the error signal gets large enough, the system will downshift and try to accelerate faster. At that point, it's almost certain to overshoot what you requested (and that's probably much more than what you intended) before the system can recover.

It would probably make sense to modify such systems to set a high speed limit -- and also to sense the brakes -- if the brakes come on, shut the throttle.

No signal is significant if it cannot be distinguished from the background noise. What signal do you suppose Macdonald's sees in the fact that I didn't buy a BigMac yesterday?

There's a basic problem in trying to interpret the lack of something as a strong signal. Last week noone, anywhere in the world, bought an iPad. You can't get a much stronger signal than that, if not buying an iPad is a signal. Of course, I could be wrong, perhaps that's why Apple announced one yesterday?

Do you suppose "They" don't like something we're doing, because, even though SETI has been looking for years, no alien has contacted them? How strong a signal is that?

Unfortunately, that's probably right. Except in unusual circumstances, the organization / person looking for a professional volunteer doesn't understand the problem they're trying to solve, and it will take you more than a week to figure that out yourself.

If you stay long enough to figure it out it may well turn out not to be in your area of expertise.

You laugh.

My management once praised my work because an idea of mine had led to a situation where each line a programmer wrote generated 8 lines of C, so I'd done a great thing for productivity...

I, on the other hand, felt rather disheartened about my management...

would you argue that "about a million" is NOT "Over Nine Thousand"? If not, what is your argument?

I know -- why don't we all go to travelocity and check on flights to Pakistan, and then start encrypting all our email?

Or maybe someone could develop a web page that will set us up for encrypted email, and check for flights to Pakistan behind the scenes the first time, first...

Then we might have an interesting test of the security of encryption...

That's cool. I wouldn't want to work for a company that judged me by my email address.

Above all, don't think it has any connection to this story from last week.

I agree. Many of the questions and answers surrounding "which math course" seem to be thinking about the question wrong.

In 35 years of programming I probably never used Calculus directly in developing a program or wrote a program to solve a problem that required calculus. Would I argue against including Calculus in a Comp. Sci. curriculum then? Absolutely NOT.

When I look at what I do every day as a software designer / developer and I ask where did I learn to do that, the answer is often "in Calculus class". Why? "Limits"! -- not Limits themselves, but I think the concept of Limits as used in calc was the first real abstraction I had to grapple with.

If you ask me what High School class was most useful in preparing to be a programmer, I'd say "Geometry". Why? Proofs!

When did you ever need to know some factoid you picked up in a history class? Should you not take history?

The important aspect of most classes is NOT the facts or fomulae you might learn, but the ways of thinking you learn.

Geometry / Proofs in general teach you logical thinking and step by step progression. Constructing a proof and constructing a program are quite similar. That should make it clear that is important that you actually do the proofs, not just read someone else's proof -- you won't learn to program by reading about someone else writing a program.

I agree with the "take 'em both" school of thought -- not only are the thinking processes different, but the concepts in both subjects are also useful to you.

I'm a big fan of automata theory and formal languages, too. You'd be surprised how often you can set out to solve the Halting Problem without recognizing it -- and if you don't know what it is and why it's not worth trying to solve ... It's also useful to know the limitations of regular expressions and how to write problem oriented languages that are easy to parse...

But the most important aspect of both courses is how they stretch your mind if you can get your head around the proofs. You learn to spot weaknesses / holes in proofs and it's amazing what sorts of problems you can spot in requirements. And debugging proofs is good practice for debugging programs.

I don't know about the ETF, but I found that the $1.99/MB was charged when I turned on my new phone and pushed the button looking for the tool menu. I reprogrammed the buttons to avoid that, but it was clear that accidentally turning on the "standard" service was going to cost me $2 each time. It's obviously "$1.99 per (MB or fraction thereof)" and that includes the splash screen, without a data plan.