Complete Software Engineering: Intent through code is lossy

Intent through code is lossy

September 14, 2004 at 07:33 AM
by rgrzywinski | 6 Comments

Expressing intent only though code is lossy.

If it is accepted that a reason to weed though someone else's code is to find and remove bugs, how can the argument "the code is self describing" stand? The original intent has clearly become partially lost due to a defect.

There are at least two cases that exist in the presence of a defect:

The original intent is described through the code.
The original intent was improperly transcribed into code.

Without comments or some other mechanism to state intent, the two cases are indistinguishable. The first case is a much larger concern (i.e. risk) than is the second since it has the implication that other decisions were based on a flawed intent.

When a "code is self commenting" programmer is also a "crafty" programmer, you have the recipe for disaster. A crafty programmer is one that attempts to use small tricks such as over using a variable (e.g. a null value implies some other value does not exist) to achieve a goal. The problem with the resulting code is that the intent is obfucated. Anyone else reading the code typically has to scratch their head and wonder "is this intentional or a bug?". Information about the intent is clearly lost in the translation to code.

Comments

Comment by Anand at September 21, 2004 10:52 PM

No arguments with your opinion - just to add - isnt it also a function of the language ? a language that is simple (my prejudiced brain shouts Smalltalk) makes for intent even with comments lossy

Comment by rgrzywinski at September 22, 2004 05:35 AM

I'm with you about 90%. But to drive it home, I don't suppose that you have a particular case or aspect of a "simpler" language than makes for better (for lack of a better word -- "more clear" may be more suitable?) intent.

And the only reason that I put quotes around "simpler" (and that I'm only at 90%) is that I'm working on a presentation for a bunch of physicist that are dead set in the belief that Fortan is as simple as you can get, yet functional enough to serve all of their needs. Whenever I look at Fortran (especially through the muck colored glasses of an enterprise application developer) I see a big fat hairy uncontrollable mess. In other words, simplicity in this case is a) in the eye of the beholder and b) based on scope and complexity. You can discount (b) in this argument since the assumption has to be made that the language is sutiable for the task being performed.

Thank you for your comment. It's giving me something to think about.

Comment by Anand at September 27, 2004 07:53 AM

A quote from Paul Graham would be in context here.
"It means that a programming language should, above all, be malleable. A programming language is for thinking of programs, not for expressing programs you've already thought of. It should be a pencil, not a pen. Static typing would be a fine idea if people actually did write programs the way they taught me to in college. But that's not how any of the hackers I know write programs. We need a language that lets us scribble and smudge and smear, not a language where you have to sit with a teacup of types balanced on your knee and make polite conversation with a strict old aunt of a compiler.
"
and another one that goes somethng like this - "Code is written to be read; that it executes is just a side effect"
A language with not toomany keywords, that encourages simple constructs would be one that would blur the gap between intent and "code" ?

i dont have a particular bias for or against Paul - once in a while, he does say things that make me think though.

Comment by rgrzywinski at September 27, 2004 08:35 AM

You have certainly provided me with some things to think about today.

The first quote identifies a core dichotomy: balancing the need for innovation while coding and the requirement that the produced code is direct enough to be maintained by others. I'm typing off the cuff at this point so I don't expect my thoughts to be completely clear.

The second quote makes me think of a MDA-like model. I should be able to write code in a way that is conducive to the way one develops concepts and ideas then hit a button and turn that malleable code into a solid form. Intentional Programming had some notions of this ("views" if you will).

This is definitely something that I need to think about more. Thank you for the food for thought.

Comment by Anand at September 28, 2004 05:03 AM

Hi,
Here are some links you may find interesting
http://www.paulgraham.com/hp.html
His hackers and Painters book has an essay on languages which is interesting

And a small correction - this is the correct quote attributed to the correct people
"Programs must be written for people to read, and only incidentally for machines to execute."

- Abelson & Sussman, SICP, preface to the first edition
Regards
Anand

Comment by rgrzywinski at September 28, 2004 07:40 AM

I was taking a look at that "Hackers and Painters" book yesterday after you mentioned the quotes. I'm going to have to plop down on the floor at the local Borders and take a quick read.

Thanks for all of the great info!