Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Prgramming vs. Coding

by extremely (Priest)
on Oct 06, 2000 at 07:54 UTC ( [id://35539]=perlmeditation: print w/replies, xml ) Need Help??

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 programs.

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 teachs Perl.

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 main body.

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)

Replies are listed 'Best First'.
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. :-}

            - tye (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.

      --
      
      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

RE: Prgramming vs. Coding
by clemburg (Curate) on Oct 06, 2000 at 13:34 UTC
      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.

      --
      
      Brother Frankus.
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.)

      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)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://35539]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others cooling their heels in the Monastery: (2)
As of 2024-04-21 09:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found