Computers are A Devolutionary Scam

[glennmac]

I am profoundly psychologically disturbed (no pause) by this huggy-smoochy agreement-to-agree between Buck and Harv. They seem to have smugly stipulated that there is a socially acceptable difference between (1) a programmer who produces efficient code and (2) an efficient programmer.........Let me translate this devolutionary horror for those of you who know even less than I do about their geektalk........Assume you have a brain surgeon in 1970, Dr. Capillary, who does all his surgery with a small scalpel. He takes pride in his ability to precisely cut out the tumor without damaging the surrounding tissue. He spends hours practicing how to avoid the unnecessary cutting of adjacent capillaries so as to mininimize later headaches for his patient. It takes him 3 hours to do an average brain surgery.......Flash forward to Dr. Niagara in 2002. He uses a Walmart chainsaw to do brain surgery. It takes him 30 minutes to do an average brain surgery. His patients have lots of headaches, or worse..... According to Generally Accepted Programmer Theology, as evidenced by the Buck-Harv Concordat, Dr. Niagara is recognized and promoted as the more efficient and productive brain surgeon (programmer)........There you have it, ladies and gentlemen of the juryrig, the smoking gun of devolution......QED

 

[Harv]

<font color=blue>There you have it, ladies and gentlemen of the juryrig, the smoking gun of devolution</font color=blue>

Careful, Glenn. I'm getting that huggy-smoochy feeling all over again. /w3tcompact/icons/laugh.gif

 

[brewerbob]

Which brings a joke to mind. How many programmers does it take to install a light bulb??? Answer: None, it's a hardware problem.
Bob

 

[GlueGuy]

<font color=blue>Our compilers typically had the option of converting the code to assembly</font color=blue>

Terry,

They still do, only now they're on steroids (or at least the compilers that we use are). We have so many knobs and dials to use when we compile things it's almost ridiculous. It's true that "sometimes" you can optimize yourself into a black hole, but "most" of the time, you get very good results.

We usually have optimization set to compromise between size and speed. This works better than 99.9% of the time. If things seem slow, we will take the performance-sensitive bits and dial them down, or analyze the assembler to see what we can do to step it up.

Heck, when I started in the biz, I used to do a bunch of stuff one step down from assembler; machine code. I could fat-finger in a routine through the console faster than most people could type.

The more things change, the more they stay the same....

 

[SimS]

BB:

Your joke reminded me of another programmer joke.

How many Microsoft programmers does it take to change a light bulb?

None. They just change the standard to darkness!

Sim

 

[TerryinMD]

Glueguy,

I'm far removed from the actual coding now. /w3tcompact/icons/smile.gif/w3tcompact/icons/smile.gif/w3tcompact/icons/smile.gif

What platform are you programming on? I never hear of our guys tweaking their code with any compiler switches. Like I previously said, all they ask for is bigger, better, faster.... /w3tcompact/icons/crazy.gif The only ones I see trying to improve upon performance are the database guys. Not so much in code optimization, but in table sizes and DB tuning.

I understand about what your saying concerning fudging around with machine code. I looked over some code that did the same thing. I helped develop new display screens for the system console and had to understand how the console driver worked. We had 4096 bytes to work in. So, that meant that we had to use overlays to drive the console. One particular overlay had an byte left open (set to zero) preceded by a jump instruction. Sometimes, you would jump. However, sometimes the jump instruction was replaced by a different instruction in machine code to perform a completely different task. I called it self-abusive coding. The first time you hand checked the code, you couldn't believe your eyes (documentation - ha!!). You expected to jump to a previous address and guess what, the instruction was changed!! Oh, those devious assembly programmers.....

Terry

 

[MikePA]

Classic way to patch code. Replace an existing instruction with a branch. Branch to the code, do various things and branch back. Although I've never dealt with self-modifying code. Yuck.

 

[Harv]

<font color=blue>never dealt with self-modifying code</font color=blue>

Brings to mind an incident I had with a young "hot-shot" programmer I used to work with. I was project leader, all code had been submitted as "fully debugged and tested" (we know there's not such thing, but you get the idea) and was scheduled for the first production run on Monday. So there I was, spending my weekend trying to figure out why the prototype was intermittently crashing.

I eventually figured out that Mr. HotShot ("I can write smaller, faster code than anybody") had written several self-modifying subroutines just to make his code smaller than everybody else's. To be fair, his stuff was very small and ran pretty fast. Too bad he wasn't around to test it that weekend when I burned the whole thing into PROM. /w3tcompact/icons/laugh.gif /w3tcompact/icons/tongue.gif

 

[GlueGuy]

<font color=blue>What platform are you programming on?</font color=blue>

Terry,

We do this on several platforms: Compaq, HP, Sun; and in several languages, but mostly C, C++, and Java.

 

[GlueGuy]

All of the early Tandem systems had a CPU architecture that separated "code space" from "data space". So the stack and all data structures by definition went into the data space. Only the memory manager was allowed to write into code space, which was under kernel control.

It didn't eliminate bugs, but the self-modifying code variety were non-existent.