Nadya,

For me, this is a matter of strong religious principle: always but always lots of little programs.

Amongst the many reasons in favor of it:

Structure!. It is a basic tenet of programming as old as the hills that every functional unit (in our case, a PRG or PROCEDURE) should do exactly one thing. It should, for that matter, receive anything it needs as parameters and return a single value.

Structure (part 2) Large tasks then become small programs that call other programs, such as

For k = 1 TO ALEN(MyArray)
xError = Step1CompletesOK(MyArray[k])
IF EMPTY(xError)
=Step2isNext(MyArray[k])
ELSE
=MyGeneralErrorMessage(xError)
ENDIF
ENDFOR

Design. Unless you're a programming god, and can truly anticipate every single consequence of every line of code, then you probably (like me) change the code around once or twice while writing it. Sometimes I discover that I've made a real boner and need to completely restructure a loop. Much easier to to do this when no single routine is more than 20 or 30 lines than if it's all packed into 500 lines or so.

Debugging. It is much easier to debug 10 lines of code than 100, or 10,000!

Maintainability. Similar to debugging, if a bug is discovered in the program after the users get it, it is much easier to surgically alter one or two small programs then to start the awful process of slugging through line after line of a large program trying to figure out why the 587th line sometimes crashes and sometimes doesn't. There are 586 lines above it that could be the problem!

Modifications. Large programs which depend on many variables and environmental conditions become nearly impossible to safely change almost the minute they are written (see debugging above). But small routines that accept parameters and return values can be quickly enhanced or changed. Notice that I'm basically making the same argument in several different forms here.

To put it simply, the human mind is much better at handling small tasks than large ones, so divide and conquer.

As far as John's crack about not using PRG's at all, I think he's begun his Devcon partying already. (gd&r from John) They are still very much wonderful. Custom visual classes are just not nearly as easy as writing out a little PRG such as "sysGetNextPkey." I'm a big fan of OOP, but I also believe in the right tool for the right job.

Also, FWIW, I just wrote about 450 lines of code today in a PRG, composed of one "master control program" at the top which called about 12 PROCEDURES in the PRG. There are not a lot of lines of code, but it was fatiguing and, of course, has to be 100% correct. I can't imagine how frustrating it would have been if I had one huge PRG.