Tips for beginning programmers: try top-down

[gregw]

When trying to solve a problem that is totally intimidating, I try breaking it down into smaller parts. This has the benefits of A) making the problems smaller (yay!), and B) increasing the likelihood that I can solve one of the problems. Try it!

(One of the small problems in your request for help is 'how do I compute an average?' Can you manage that one at least? What are the other problems?)

Once you've solved one or several small problems, you A) gain confidence that helps fuel further progress, and B) end up with a better intuitive sense of the shape and size of problems you haven't yet solved, and C) you've given your brain time to mull over some of the other parts, something that often comes in quite handy.

"divide and conquer!"

[gregw]

Sometimes though, the problem with splitting a problem into many smaller parts is that A) you've created a lot more problems, and B) this is not a good feeling if you can't seem to solve any of them.

Thankfully there is a way out.

Then I try starting with the very first task I have to achieve in order to make any further progress. (In your case, this would be reading in the .dat file and sticking it into some variable(s).) This helps A) make the problem more manageable, since the task you have to solve is much smaller than the problem as a whole, B) greatly simplifies the process of chosing what to work on, and C) provides a foundation for future work to build on top of. Try it!

Once you've solved the very first sliver of the problem, you can test that you've gotten that right, and when you have, hey, you've accomplished something! Progress! Now just tackle the next small piece. This is called the "iterate and test" approach to software development.

"A journey of a thousand miles begins with a single step!"

[arhuman]

That's a good way indeed...
Rather that's a good point to start with,
but take care, this will only give you a way to go on further.
It won't assure you to reach what you want...

Breaking a problem into the right smaller parts isn't so obvious,
there are often several ways and few good ones...
Often the difficulty is more to make the good choices
than just breaking into several simpler tasks.

Let's take a dumb example (I'll let smart people find smart example ;-) :

You have to write a small program to make two host communicate (in batch) via several means; what will you do ?

• Write a client and a server ?
• Write a single client/server prog ?
Depending of the constaint the first one may not be so stupid
(even if the second one is more likely...)

Then as the prog has to be configurable,
writing the prameters handling part you wonder : how will it take its parameter ?

• Via the command line ?
• Via a conf file ?
And those of you who just think
'If the amount of argunents is important just use a file
otherwise the command line is the best'
could just miss several possible aspect (security, file constraint...)

Now that you have your data, you'll write the com routines;
of course you know what protocol to use :

• TCP ?
• UDP ?

...

Of course this example is dumb, the (few) questions are over-simplified
but the idea is although apparent :
Breaking into smaller parts is usually easy
but making the right choices doing so isn't so obvious
Decomposing a client/server prog into several parts is easy but depending on how you do it,
it will be more or less easy to maintain, easy to upgrade, easy to understand...

The choice of your structure, data, algorithm (among a lot of other things) is important too, in my humble opinion.

"Only Bad Coders Badly Code In Perl" (OBC2IP)