I'm Pappy. I'm not dead, but my kids have been hearing me bitch about Microsoft as long as they can remember. At this point, they probably think of it like a fixture of the landscape: the old man doesn't like Microsoft.

So my oldest finally graduates college, and gets his first real job. He's an engineer; industrial controls. The vendors only write drivers for Windows, so everyone uses Windows, and no one cares. He's provisioning servers in plants, and doing Windows installs, and running VMs, and trying to automate things. And it's all done in Windows Power Shell.

After a few months, I start getting calls from him. He's astonished: "This thing really sucks!" he tells me. It kind of a broken, crippled, over-engineered, badly implemented shell. It's always in his way. Everything is a needless problem. He talks about what a relief it is to go home on weekends, and work on his own systems, in Linux, running bash, and being able to work on the actual problem, instead of spending all his time fighting with the system and the tools. And every time he calls, it's the same refrain with more exclamation points: "This thing really sucks!!!"

So, yeah, he learned it from me, but then he learned it for himself.

I've seen this assertion in two comments now.
How do local variables cause stack overflow?

If you aren't using recursion, then total stack space requirements can be computed from static code analysis.
If you are using recursion, then you can overflow the stack with return addresses alone.

BTW, I did read most of the expert testimony, and some of the expert report.
The suspect software is catastrophically bad.

http://world.std.com/~swmcd/st...

I threw a monkey wrench into the engine of my car, and it ran slower. Maybe if throw something different into it, it will run faster

They wouldn't let him board a flight from Boston to Washington, so he was stuck in Boston for a few days until someone removed his name. Then he flew to Washington.

I was very disappointed by this. I was hoping that he would stay camped out at Logan airport, and pledge not to fly until the government created a procedure for people who aren't United States senators to get their names off of the list.

If you are a contractor, and "there's plenty of jobs you can take", then you really don't have a problem here. Let's take it by cases.

1. You just don't want to deal with this app/code base/company/assignment
Then leave for one of those other jobs. That's part of what being a contractor is all about: being able to drop clients that you don't want to deal with.

You don't have to be rude or snarky about it. Give notice, complete whatever term or notice period is specified in your contract, and move on. If they ask why, tell them simply and honestly. Providing such information (if asked) is part of your service to them.

2. You are willing and able to do the work
Great! You've got a good gig, and from the sound of it, it could keep you in peanut butter and iPhones for a long time.

If the code base is a horrid mess--that's their problem, not yours.
If everything takes 2, or 5, or 10 times a long as it "should"--that's their problem, not yours.
If every time you fix a bug, the app breaks in two other places--that's their problem, not yours.

If they ask for schedules, give them your best estimates, based on what you know about the code base.
If they demand to know why everything takes so long, give them your best (diplomatic) explanation of the problems with the app. Speak only in terms of the code as it stands. The history of who wrote it and how it got that way is irrelevant.
If they decide you are incompetent and dismiss you, then you are back to case 1, above.
If they decide to cancel the whole project and terminate your contract, then you are back to case 1, above.

Part of what a company gets when they hire contractors is the ability to dump scut work on them (so that the "well respected" people don't have to do it), and the ability to dismiss them when circumstances change (w/o paying unemployment, etc.) If you're OK with that deal--the work, the scut, being low man on the totem pole, no job security--then give them the best 8 hours of your working day, cash their checks, and sleep soundly. The day you're not OK with it--the day you wake up thinking, "I *just* *can't* do this any more"--that's the day you give notice and move on.

Along about 3rd grade, most schools offer musical instruction for a semester or a year.
The kids come home one day carrying a flute or a trumpet or a drum kit,
and they go to band practice once or twice a week and learn to make some noise\b\b\b\b\bmusic.

Some have no interest and no aptitude and drop it pretty quickly.
Some have some interest and aptitude and stay with it until they find other interests.
Some go on to become musicians.

I'd offer programming instruction on the same basis.
But I'd put it off until age 12 to 14 (when the capacity for abstract thought develops).

Most of the code that I see exhibits what I can only describe as a kind of aggressive indifference.
It's not just that they don't care.
They *totally* don't care.
And they're going to make sure you know it.
And suffer for it.

After a while, dealing with this stuff is just depressing.
Especially if you do care.

Or maybe they both stood their ground.
Or something.

And this is what we want, right?
Half the country in the morgue, and the other half in prison, because, because...stand your ground!
Or something...

some kind of 6502 assembly code in the Terminator's red overlay

I knew a guy (Hi, Tom!) who identified the code as coming from the Apple ][ ROMs (which were 6502)
He said he recognized some of the code comments.

You already have your algorithm running in electronic hardware, right?
Your current gate count is the sum of
  * the gate count of your CPU
  * the gate count of your RAM
  * the gate count of your program ROM

So that's an upper bound on the gate count.
If that number is too big for your manufacturing partner,
then you have an optimization problem.

Optimization is a hard problem...

Props to Rudy Rucker...

At this point, I think we'd be better off if the NSA's efficacy were reduced to zero (infinitely weaker: 1/x -> 0). Then we could rebuild it from the ground up with proper political, legal, and operational controls.

In fact, I suspect that the NSA retains most--if not all--of its operational capabilities.

The NSA doesn't face any significant legal restrictions. The law allows them to do most of what they want, and they just do the rest anyway, secure in the knowledge that the courts won't(?) can't(?) shut them down.

The NSA does have a political problem right now. It's not much of a political problem: most of the political establishment wants them to keep doing what they are doing. They wouldn't have any political problem at all if their P.R. weren't so inept. Hayden yammering about "defectors" and "treason" and "infinite weakness" is just more P.R.

This tunnel was locally controversial, with opponents arguing that
- it was expensive
- it wouldn't help with Seattle's traffic problems, AND
- these monster boring machines have a track record of getting stuck underground, and then what are you going to do? Call Roto-Rooter?

Sounds like it's starting to come true...

Counting is an algorithm, like long division or the use of logarithmic tables--in this case an algorithm for assessing the exact numerosity of a set of objects. It consists of reciting a memorized stretch of blank verse ("one, two, three, four, five, ...") while uniquely pairing each foot in the poem with an object in the spotlight of attention, without skipping an object or landing on one twice. Then, when no object remains unnoticed, you announce the last foot you arrived at in the poem as the numerosity of the set.

This is just one of many possible algorithms for ascertaining numerosity. In some societies, people pair up the objects with parts of their body, and I know several computer programmers who count like this: "Zero, one, two three, four. There are five."

--Steven Pinker, The Stuff of Thought, p. 141