jgardn at alumni.washington.edu
Mon Jan 13 10:31:52 CST 2003
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
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
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.
jgardn at alumni.washington.edu
Python Qt perl apache and linux
More information about the spug-list