In the same way, the best coders seem to absorb sections of code at one gulp.

I might comment more later, but I just wanted to thank you for that nugget. I find code hard to read when it is spread out too far. The oft-praised practice of putting your braces on lines by themselves, separating your blocks with blank lines, and putting multi-line comments all over the place yields code that I have a terrible time following. I have to stop and read it a line at a time, remembering more and more lines until I can collapse them into a concept.

I love a nice tight subroutine whose entire code fits on a 40x80 screen. I like end-of-line comments that don't break up the code and trip up my eye. Complex things should be explained outside the code of the subroutine.

These attitudes of mine are always interpretted as some rebel hacker sickness. My primary job for years was reading other people's code. The hardest to read code is poorly designed code. But the number two worst problem is code that is so broken apart that you don't have a complete, useful concept in one piece. Adding vertical white space is a good idea if you have a 300-line routine. A much better idea is to factor out the conceptual chunks into reasonably-sized routines.

Yes, if you go looking at the code I post on PerlMonks you will probably find much code that is too compact. That is the fun of Perl and PerlMonks. I avoid many forms of compactness in production code because I know the next guy might not be a great coder. But I hate the waste of vertical space that is so often demanded.

P.S. I think of "coder" as a term for a warm body that can produce functional code if you don't require any deep thought, design work, etc. from them -- just the opposite of your take on things. The use of "coder" as a compliment seems more a slang and usually requires an extra adjective. But that is probably just me being out of touch. :-}

Contrarily, I percieve a coder as one producing results in a given language: a programmer writes programs in several languages but is oft ignorant of a language's idiom. Either of these individuals may be prone to haste.

I disagree with some comments concerning code aesthetics although I whole-heatedly cheer the comments about concise subroutines and your comments about abstraction rather than monolithic code.

I gained a lot from Kernigan and Pike's book Practice of Programming that indicates that code beautification is irrelevant with tools like emacs to reformat to coders preference; but it is confusing when diffing versions of the same file indented differently.

I suppose in the final analysis being a programmer or coder, is based solely on the individual's perception.

--

Brother Frankus.

Given, my most recent experiences this is what I now believe, coders are what one book I've recently read defines as language bigots: people who don't ask how or why, don't use design methodologies and fear CASE Tools.

A programmer is someone who may know several languages, may prefer one, but uses whatever tools are to hand to make their job easier. Programmers may be less knowledgable about architectures or operating systems but have a good idea of what Software engineering is.

Obviously it can be seen I am biased to one, that's because I suffer the other.

--

Brother Frankus.

Adding vertical white space is a good idea if you have a 300-line routine. A much better idea is to factor out the conceptual chunks into reasonably-sized routines.

I try very consciously to add whitespace between "paragraphs" in my programs, and to order the code into reasonable "paragraphs" and "subsections", usually flagged with additional comments as to the purpose of the following section. You can see evidence of this in my columns.

I also tend to minimalize the comments to just those things that carry context. I try to let the Perl code speak for itself, and don't define anything that they can get from a perusal of the first half dozen entries in perldoc perl. But if I have an algorithm, or a dependency that wouldn't necessarily be obvious, that becomes the comment.

-- Randal L. Schwartz, Perl hacker

You will like to read this:

• How to Solve It: A New Aspect of Mathematical Method (Princeton Science Library). By Polya, George.

As for how to develop the skills you mention: just work through this book - it's challenging, but worth it.

• Structure and Interpretation of Computer Programs, Second Edition. By Abelson, Harold / Sussman, Gerald Jay / Sussman, Julie.

Conceptually, I think programming can be regarded as problem solving by means of symbol manipulation. And yes, I think the essence of programming (as Fred Brook characterizes it in his classic essay "No Silver Bullet" (see The Mythical Man-Month : Essays On Software Engineering. By Brooks, Frederick P. Jr.)) is reducing complexity into manageable chunks.

In fact, there is a very easy and common way to use this method when coding: Just write down your thoughts on how to solve the problem in English with some pseudo-code (while loops etc.) to improve clarity. Comment out what you have written. Hack it apart and elaborate on each part in code. You get a good high-level structure, and comments for free.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

Indeed, that sounds very much like Knuth's literate programming (see Google if you're supremely curious) technique.

Disciplined adherance to this approach guarantees that the documentation and code will always remain in synch. However, it often does require that a separate program separate (heh) the code from the comments before compilation.

POD has certain elements of this (but it's definitely not the same). Javadoc is a little closer.

The only person I've seen who really does this is Andrew Johnson, in Elements of Programming with Perl.

In my opinion, it's more valuable on big projects, but it's a good technique when you're stuck on a problem and need to break it down before you can write code.

I agree with you absolutely on breaking up the problem. Math is my baby, and what you say is key. Math is incredibly simple..and hard. The problem is that our brains are wired to understand certain complex tasks, not simple ones. We can understand speech, recognize voices and faces, complex tasks all - but cannot reliably add 1000 numbers together even though that is simple.

Being good at math is largely a process of understanding this, taking things in pieces, and breaking them into appropriate pieces if they are not that way already.

Compared to math, programming is a nightmare.

Programming involves dealing with a machine that needs the same sort of approach, however it also involves dealing with users who won't specify problems, and a real world where there are many ways to break problems apart. Choosing which one will work well in a given situation is key. It would be easier if technology stayed still for a while, but it does not.

Now you are right that around here we deal more with the mechanics of programming rather than the hows and whys. Unfortunately the hows and whys are going to age better than the mechanics. And I don't know how to communicate them. I can show the ones that I know, but someone who does not already understand it will miss the point. And it is certainly possible (in fact I can think of examples here) to master all of the mechanics without having a clue about what I would call "good taste"...

I recall Jackson Structured Programming, where diagrams are drawn of the input structure and output structure, slap 'em together and you've got the program structure.

Z Specification now that is Math: fundamently you create enough constraints that only the things you want to happen can happen.

Both these methodologies had their uses and their day. Technology marooned these powerful and practical design methodologies.

--

Brother Frankus.

There are some basic tools missing from people's mental toolboxes. In many cases these are the same tools that likely they failed to instill in Math classes.

Reduction, breaking a problem into components or stages, then further down to individual steps is the key one they missed. Learning how to attack a problem and what strategies let you chop it into perl-syntax sized chunks is a tricky thing...

Further, multi-focus, the ability to keep the goal, the main loop of the program, the sub sections, and the individual line you are on all in your head at once seems to be a talent the best have.

I would like to point out that "Math class" is not the only place to learn these things. Music is another arena in which the skills necessary for programming may be learned. (Note this interesting comment along these lines.)

Like many other things, Music is separable into many layers: reading the notation, playing an instrument, writing music, conducting, etc. Moreover, each layer at one level may also be composed of sub-layers.

For example, you have to know the mechanics of playing your chosen instrument, may need to know how to read what's written, and if reading written music, must definitely know how to interpret the notation, in order to play music. Then, if you're playing with a group of musicians, you may need stay together by following the leader or perhaps by simply listening to the others at the same time you're playing.

(As an aside, it would be interesting to ask the monks how music has affected their programming. I don't mean give me a list of what you like to listen to, but not this either, as it is a little too abstract (though I like it). What I would like to see is discussion about what skills learned via music tranfer to programming.)

I sure wish whoever posted this logged in, they deserve scads of ++ing for it. This is exactly on the money. Music and math are mixed all through history and a quick peek at the bios of the bright lights in Perl will show you a remarkble number are also musicians.

--
$you = new YOU;
honk() if $you->love(perl)