Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

What are the most basic, generic aspects of programming?

by theAcolyte (Pilgrim)
on Aug 02, 2004 at 01:46 UTC ( #379168=perlmeditation: print w/replies, xml ) Need Help??

Whilst this is not strictly perl, its related because I'm teaching perl to a small group of people at one of the companies I do work for. None of them have ever done programming of any sort, so I'm working with a clean slate -- no prejudices -- which is nice.

I'd like to start off with a basic introduction to what programming is. In fact, that's the name of my first slide. I've never stopped to examine it in this way before, so I had to ponder for a little while.

I'm posting here because I'd like some feedback -- does this seem like an accurate representation? Did I miss something major? Or am I giving people the wrong idea? Remember, this isn't meant to be all inclusive, just the generic idea. The first slide text is below:


Programming: The process of creating steps for a computer to perform a desired task.

In a nutshell, that's it. Take any given problem, and break it down into small tasks you (as the programmer) can tell the computer to perform.

There are 5 key components to programming -- at least in the begining. They are

  • Input/Output
  • Variables
  • Flow Control
  • Decision Making
  • Reusing Code (Subroutines)

Once you've learned these five basics, you can write complete programs on your own! Sounds simple, doesn't it? Lets talk about each of the five in a bit more (shallow) depth.


Thanks for any, and all input. Unless, of course, its just purely insulting with no redeeming quality. And even then, thanks, cause it will likely be good for a laugh.

- Erik
  • Comment on What are the most basic, generic aspects of programming?

Replies are listed 'Best First'.
Re: What are the most basic, generic aspects of programming?
by TVSET (Chaplain) on Aug 02, 2004 at 01:54 UTC
      Wow! What a great link. The introduction is VERY well written -- comparing us being taught as children to 'being programmed'. I'll be sure to incorporate a bit of that into my lecture :-)

      - Erik

      How does this text differ from the Structure & Interpretation of Computer Programs (SIPC) book? They both look like they could cover a lot of the same ground, but I'm curious about their actual use in a classroom. The copyright on SIPC is 1996 vs 2001 for HTDP - is one a successor to the other?
        These books are by different authers. That means, most probably, that at least explanations and examples are different. :)
by graff (Chancellor) on Aug 02, 2004 at 03:14 UTC
    I think you should consider changing the second component to "Types of Data and Variables", or words to that effect -- it might not be too soon to introduce the differences between strings and numbers, and between scalars, arrays and hashes. (Actually, the latter distinctions will be more important.)

    Also, you might need an extra component between "data/variables" and "flow control": Basic Operations -- i.e. to introduce arithmetic operators, string concatentation, and assignments. (But then, if you decide to include "=~" here, it could become a very long and confusing component; if you really intend to teach them Perl, such that they would actually start to use it, you'd need to add regexes as yet another separate component.) Then again, maybe the basic operators are so simple that they don't need their own component...

    I'd be inclined to put "decision making" above "flow control". I assume you're talking about "if" statements, etc, as the "decision making" part? Flow control depends on this, so should come later.

    If these people really are completely new to programming, some of the features of perl syntax may be difficult explain, to the extent that these have been included (and documented) for the benefit of people who have had prior experience with other languages. The fact that there are many ways to do the same thing in Perl could cause a paralysis of indecision: "should I do it this way or that way? How do I know which way is better?"

    Then again, introducing them to Perl first might allow you to convey the notion of TIMTOWTDI more easily... But then some folks will get tripped up when they fail to understand or recognize the difference between a good design and a bad one.

    Which reminds me: I hope you'll be able to demonstrate a design process, where you lay out the steps that need to be done for a problem, render these as sensible (human-readable) pseudo-code, and then translate into perl. I think when people see how little difference there can be between a reasonably clear statement of specs and a runnable perl script that implements those specs, they will be impressed and encouraged.

    Well, good luck.

by tilly (Archbishop) on Aug 02, 2004 at 04:26 UTC
    If you're teaching to beginners, I'd strongly suggest picking up a copy of merlyn's Learning Perl. That book is based on experience teaching Perl to beginners, and you may get some good presentation ideas.

    I'd also strongly recommend not just saying, "Here's a variable, here are our datatypes", but rather lifting what Programming Perl has to say about the linguistic analogs of variable names. In particular hash lookups should be pronounced "of". So for instance $age{'Peter'} should be read "the age of Peter". Not only does this help cement what hashes are for, it also tells you what to name them!

    Another recommend. Somewhere along the line give them an overview of the steps between a CGI program and the browser. And be sure to start them off with programs that do not involve a webserver, just to simplify things. Remember, people's brains are not built to pile facts on facts in a big tower. We all have limits which, when we run into them, we just balk and stop working. Try not to hit those limits too quickly, and try to recognize it when you have. One piece at a time.

by dragonchild (Archbishop) on Aug 02, 2004 at 12:50 UTC
    When you learn something, you are most effective if you are able to "latch on" to something you already know and build from there. So, your task as a teacher is to figure out what they already know, compare that to where you want to get them, then build the bridge.

    Part of the problem is that they already have prejudices about programming - that it's hard, arcane, and confusing. Of course, we all know that programming is nice and easy, but you have to convince them in their innermost heart of hearts that this is true. And, the neat thing is that it's really easy to go about it.

    Everyone knows how to give directions from point A to point B. Well, that's all programming is - giving directions to a moron that will remember everything you tell them and do it as often as you want. So, start them out with exercises on giving directions. Get them to give even more and more detail, because you have to assume the person has less knowledge of the world. I'd progress something like this:

    1. Directions to you
    2. Directions to someone from Europe
    3. Directions to someone from China
    4. Directions to someone who's never seen a car
    5. Directions to someone who has no clue about modern society

    As they get more and more complex, go from a list to a flowchart. Then, show them how the flowchart of their directions (with all the added stuff) gets converted into pseudo-code. Presto! They've just written their first computer program. This should take about 2 hours.

    At this point, it would be good to break for 10 minutes, let it soak in, then split into small groups in order for them to do another, similar problem. Leave the first one on the whiteboard for reference. After an hour, let them present their solutions.

    After lunch, now that they have connected the act of programming to something they already understand, they will have the necessary scaffolding to hook all the stuff you want to teach them. Your syllabus is just fine.

    We are the carpenters and bricklayers of the Information Age.



by Wassercrats on Aug 02, 2004 at 02:00 UTC
    How many hours of instruction will you be giving? Are the student's needs specialized? Maybe you shouldn't teach them what you would teach a typical Perl student.

    It's not accurate to say "Once you've learned these five basics, you can write complete programs on your own!" You don't need to know all that to write a complete program, but you do need to know several functions, which you don't mention.

      Good questions!

      How many hours is up for grabs. Its an open ended contract paying me per class. Kinda gotta like that :)

      I suppose its geared towards perl in a CGI environment as its a client I did a quite extensive CMS for about 5 years ago. They want to be able to do minor mods in house or change things without having to go to me. While I don't like slicing my own throat if I don't teach them someone else will.

      To me, those 5 basics are needed to write any useful CGI type program. I'm really asking if I'm missing anything. And yes the ! statement at the end is a little overboard but I'm going to try to calm the fears that this stuff might be too hard for them.

      I've always thought teaching is a little bit like programming ... break it down into small enough bits and you can do it without a problem - Erik

        I suppose its geared towards perl in a CGI environment

        I would suggest that you include the issue of security on that first slide. While it is not strictly a programming topic in the manner that the other topics you have are, hopefully it will give you the opportunity right from the start to emphasize that security is a serious matter. As I'm sure you well know, too many sites/web businesses have been torpedoed because security was an afterthought.


        None of them have ever done programming of any sort...They want to be able to do minor mods in house or change things without having to go to me.

        I hope you're sure you were really asked to teach them Perl, and I hope whoever's hiring you for this knows what he's doing, and that after a week's worth of lessons, the boss doesn't come to you and say something like "Did you teach them how to change the font color yet? That's mainly what I wanted."

        I agree with wassercrats, you need to be careful that you understand everyone's expectations. It takes quite a while to learn to program, and even making a minor change to a script assumes you can read it and know what's minor.

        If you really want to teach them to program, everyone should get a standard text - merlyn's Learning Perl - and all go through it together.


by maetrics (Sexton) on Aug 02, 2004 at 10:19 UTC

    Two things I would include is a Scope (which is likely incuded in you chapter on variables, but I've seen it overlooked in so many other times), and Style (the idea that you code for other humans and not just the computer).

    my 2 cents

by hardburn (Abbot) on Aug 02, 2004 at 14:13 UTC

    The first thing said in a training course is something like this: "The most important aspect of programming is abstraction". I've yet to see a training course do that, but I think it'd be a really good idea if instructors started doing this.

    Too often, I see second-rate programmers almost afraid of abstraction. I hear often hear a job-security argument when I confront them on this. They are afraid that if a program can do their job, then their position will become irrelevent.

    Example: say I'm an administrator for a very busy site--4 GB of logs generated per day. Logs are useless all by themselves--you need some way of anaylizing them, either by hand or by a human looking over each entry. The second-rate programmers mentioned above would seem to want to hire people who have the sole job of looking through 4 GB of logs getting intresting bits out. Needless to say, this would be very expensive to the company, but it keeps people employed.

    But it's keeping those people employed in the wrong position. To be useful as log-anaylizers, they'd need to be fairly highly trained in order to know how to pick out interesting bits from the noise. OTOH, a program or series of programs could anaylize the data and generate a daily report. Those highly-trained people are now useful for something else. Their jobs are still secure--they're just moving up a layer of abstraction.

    This, I think, is the most important lesson for a new programmer. Don't stop where you are. Keep moving up a new layer of abstraction. Tedious jobs you did before become irrelevent, freeing you for more interesting problems.

    send money to your kernel via the boot loader.. This and more wisdom available from Markov Hardburn.

      I once knew a programmer who had moved so far up the abstraction tree that all we could hear of him was a faint, high pitched, whining.

      We called him 'skeeter.


by EdwardG (Vicar) on Aug 02, 2004 at 17:30 UTC

    Q: What are the most basic, generic aspects of programming?

    A: There are two aspects:




    Master those, and the rest is easy.


by geekgrrl (Pilgrim) on Aug 04, 2004 at 19:39 UTC
    How about the basic algorithm metaphor - the recipe.
by Anonymous Monk on Aug 03, 2004 at 12:21 UTC
    I thought that traditionally it was:
    - Sequencing (A -> B -> C)
    - Alternation ( if A -> B else C)
    - Iteration ( while A -> B )
by Velaki (Chaplain) on Aug 04, 2004 at 13:11 UTC

    From a design perspective, I prefer to adhere to the following:

    1. Identification of Desired Goals
    2. Notation of Behavioral Interfaces
    3. Description of Modular Functions
    4. Instantiation of Components & Methods
    5. Creation of Functionally Decomposed Methods

    The first item covers working with business analysts, but the remainder are programming activities, which encompass both the OO realm and the FD style of programming. It's very Top-Down, but once you're defined a well-behaed interface, you code back tot he blackboxes from there.

    For new programmers, I like to start at the bottom, and teach functional decomposition, so they can wrap their heads around the basic syntax of the language they are trying to learn.

    "Perl. There is no substitute."

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://379168]
Approved by Moriarty
Front-paged by rob_au
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (9)
As of 2016-10-28 09:46 GMT
Find Nodes?
    Voting Booth?

    Results (379 votes). Check out past polls.