|Welcome to the Monastery|
Re: What are the most basic, generic aspects of programming?by graff (Chancellor)
|on Aug 02, 2004 at 03:14 UTC||Need Help??|
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.