In the years that I have been messing about with various
languages, doing all kinds of different things in code I
have noticed that a disparity exists in the world of computers.
Most of the time, when we talk of "Programmers" we mean
someone who merely writes code. "Coder" seems to be the
word people in our industry use more to imply someone who
It has been my experience that many of the Programmers
are learning the language Perl but aren't learning how to
program. I recommend Learning Perl to people because it
does seem to teach how to program as much as it
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. More than once I've felt the urge to ask someone
what they were thinking when they approached a problem
the way they did. (On both ends of the spectrum, merlyn
and Anonymous Monk surprise me regularly =)
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. When coding, I often just
go ahead and call sub routines I'm going to write later.
I find I'm deciding what to break out into a callable
or useful in multiple places routine even as I write the
A final talent I've spotted in many real hackers is
"phrasing". In Linguistics and Typesetting, when learning
about reading behavior you find out that people read whole
words as a single symbol. Fast readers read entire phrases
that way. In the same way, the best coders seem to absorb
sections of code at one gulp. The have gotten so used to
the code that regular idioms have become simple symbols.
My worry is that we are failing to get how we
derive our solutions across sometimes. That we are turning
on the how to program light, but not the how to code one.
Any other "hacker" talent you've noticed? Could/should
we try to teach programming as a skill of parsing a problem
into language sized chunks, as well as how to code it in
our favorite variety-pack-o-chunks language?
*whew* that was long =)
$you = new YOU;
honk() if $you->love(perl)
Phrasing! (RE: Prgramming vs. Coding)
by tye (Sage) on Oct 06, 2000 at 09:00 UTC
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. :-}
(a heretic, as usual)
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.
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.
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
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
RE: Prgramming vs. Coding
by clemburg (Curate) on Oct 06, 2000 at 13:34 UTC
You will like to read this:
As for how to develop the skills you mention: just work through this book - it's challenging, but worth it.
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.
Brainbench MVP for Perl
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.
RE (tilly) 1: Prgramming vs. Coding
by tilly (Archbishop) on Oct 06, 2000 at 18:45 UTC
My usage matches tye's. When I say "coder" I mean someone who keeps their head down and pounds the keyboard. When I say "programmer" I mean someone who actually thinks about what they are doing.
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.
Re: Prgramming vs. Coding
by Anonymous Monk on Nov 24, 2000 at 23:24 UTC
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.)