SPUG:Designing Programs

[Jonathan Gardner]

On Friday 10 January 2003 19:20, Asim Jalis wrote:
> I have a question. How do people design large programs with Perl?
> Do you start typing code? Or do you spend some time designing it
> on paper?
>

I'm going to be the troll today. ;-)

When writing large programs, I often reconsider when I conclude perl is the 
best tool for the job. In my experience, perl is difficult to document, too 
flexible, and not a good solution when you may end up having several people 
working on the same thing.

Most big perl programs I see have all evolved that way. They started small, 
and gradually grew until they became the big program they were never intended 
to be. Some big perl programs are really several separate programs that run 
together. Otherwise, it is probably a website.

Now here comes the trollish part. I would rather use Python than perl for 
large projects. I think Python matches my style in more ways than one:

- Like perl, it has weak typing. Think of perl with everything as a scalar, 
and you'll get Python. You still have hashes and arrays, but they are really 
hashrefs and arrayrefs.

- Unlike perl, documentation is so easy to incorporate it is foolish not to. 
In fact, for a large project, you are shooting yourself in the foot when you 
supply poor or no documentation, because you will forget how you were 
supposed to use the objects you just wrote.

- Unlike perl, refactoring seems to be easier, and is a much better solution 
than devising a hack to get things to work. I find that because there are 
only two ways to access the attributes of an object, writing regular 
expressions to find all access to attributes is incredibly easy and mindless. 
This is not so true for perl.

Now, I don't want to sound as if I don't like perl. I love perl, almost as 
much as I love Python. In fact, I use perl as often as I can for things it is 
very good at doing - handling input and formatting output, and the occasional 
script, not to mention the glue to bind all you unix command line utilities 
together.

Right now, I am putting together a solution for an optometrist. I am using 
Python for the GUI interface. GUI interfaces always turn into huge projects, 
no matter how small the intention was, so Python always wins in my mind. I 
use perl for the backend data processing. It is powerful and allows me to get 
to the point much quicker. Between the two, I use a database to store the 
data.

As far as I how I do design work for perl, I said above that I like to use OO 
to do everything. However, OO and perl are really not comfortable with each 
other, so I try to use perl's strengths and avoid its weaknesses. I break 
things up into objects, and then spend the rest of the time deciding how to 
break up tasks among the objects. I look for tasks that are general enough 
that they can be reused, and start fleshing out the program in code. I leave 
stubs with comments or perldoc describing what the task is supposed to do and 
flesh it out when I really need it.

I usually end up programming for thirty minutes, then tinkering to get the 
code to work, and then testing the code I just wrote until I am satisfied I 
got it right. Then I go on to another task and work on that one for a while. 
I try to keep the test code around so I can run it again later.

This iterative approach doesn't fare well with a solid design. I have to be 
able to revise the design as I go, changing the tasks and moving things from 
one object to another on a whim, especially in the early stages. I find that 
rather than thinking really hard about what it is going to look like, and 
writing it out on paper, it is better to actually do it and then assess 
whether it is a viable solution or not.

-- 
Jonathan Gardner
jgardn at alumni.washington.edu
Python Qt perl apache and linux