jgardn at alumni.washington.edu
Mon Jan 20 11:39:38 CST 2003
Again, I am going to start with a disclaimer. I love perl. I think perl is
great. When Tim demonstrated how to turn perl into awk and sed, that
literally changed my life and the way I use perl.
I also love Python. I can do things with Python that are unimaginable in perl.
But it would take a lot of work to make Python do things that perl does so
Unfortunately, too many people think of "Python vs. perl" and from there, the
communities actually part company. This is incredibly unfortunate because we
have so much to learn from each other. The two languages actually complement
each other in many ways. Python happens to do well the parts that perl
doesn't; and Python can barely do the things that perl does very well.
I know this post isn't specifically about perl, but I hope it will encourage
everyone to think more critically about software design and the issues that
come up as you implement the design. I hope it will encourage you to plan
ahead and think of how you will use perl to avoid it's weaknesses and
capitalize on its strengths. Or it may even convince you to give Python a
On Monday 20 January 2003 01:50, Michael R. Wolf wrote:
> Jonathan Gardner <jgardn at alumni.washington.edu> writes:
> > - Unlike perl, documentation is so easy to incorporate it is foolish not
> > to.
> Could you illustrate this with a code/documentation fragment?
def add_el(self, el):
"""Adds an element to the list of elements."""
<from the command line>
>>> import mymodule
>>> dir (mymodule)
( lists all the functions, variables, classes, and modules in mymodule )
( lists all the methods and attributes of widget )
"Adds an element to the list of elements."
In perl, you could achieve something similar using perldoc, but you can't
attach documentation in a general way to *everything*. In Python, this is
built in, as you can see above.
Python even comes with a command to load a module and assemble all the doc
strings from all the objects into something neat -- much like C++ and
doxygen. Compare this with having to assemble the documentation from scratch
with perldoc. This saves a lot of typing if you want to go in later and add
or clean up the documentation. You won't have to write out the parameters to
the function, the base classes of your class, or anything like that.
The biggest thing going against POD is that it is actually not as easy to use
as we all believe. If it were actually easy to use, people would be using it
a lot more than they do. It is all too common to find experienced perl
hackers who have little or no knowledge about POD. If you are one of those
perl hackers who can really use perl, and your don't know how to use POD,
then you really really need to rethink your purpose in life. Or learn POD.
And the simply beatiful part about Python's documentation system: what can be
simpler than plain old text for plain old documentation?
> > 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.
> Again, this seems like a comment on SW development in general, not
> specific to Perl or Python. What does Python do to make this easier?
Correct. You want to really see why people say "the first 90% of the project
takes 90% of the time, and the last 10% takes the other 90% of the time"?
Write poor documentation, or no documentation at all.
However, by making it possible to connect documentation with the objects you
use, you are saving a lot of time and effort. I don't have to pull up a man
page or the source code to find the documentation. I can just load the module
and check the object's __doc__ string. This is much easier when using a
debugger, because the object is already loaded.
> > - 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.
> Do you have a finger on why refactoring seems easier in Python? It
> seems to me that flexibility (that stuff that Perl gives you too much
> of) would be a benefit here, and that a having only two ways to access
> something may get you into a bind.
Refactoring, in case some people are not too familiar with the term, is the
act of renaming objects, attributes, modules, or functions. This is often
something you will do halfway through a project after you have realized that
renaming some things would make a lot of sense. The behavior of parts of your
program have changed enough that keeping the old name would confuse everyone,
Of course, with solid documentation and unchanging requirements no one would
ever need to refactor... but can you name the last project that you worked on
that had solid documentation and unchanging requirements? And if you can,
please provide me with the phone number of the recruiter at that company.
The difficult part of refactoring is that you have to go through ALL the code
in the project, and change the way a lot of things are done. Luckily, we have
tools like grep and sed who can help us do refactoring without spending too
much time. You see, we really are better than our Visual Studio "brethren",
and our jobs really are much easier. ;-)
Having only two ways to access the objects and attributes of objects makes it
much easier to refactor because it is possible to find all the accesses to
the attributes and the objects. In fact, it is so easy, there are some tools
you can find to help you do it. When you see tools appear for a certain task,
that means that task is easy enough to do, even a computer can do it. We all
know how stupid computers are because it is our job to try to trick people
into believing that they aren't.
In perl, there are so many ways to do it that you can't predict the ways
others have done it or even remember the ways you have done it. There are OO
paradigms that some people use that make refactoring easier. However, it
seems there are as many OO paradigms as there are perl hackers. You can
imagine how much work it would be to write a regular expression that could
find all the accesses to a certain attribute of an object. In the end, you'll
end up reading all the code anyway to make sure you got it right.
> Although I started out by playing (notice that's my way of learning --
> I'm a mammal), I do know that constraints are often enable a solution.
> Compare a my skills with that of a slug!!! Please!!! Seriously, a
> backbone, in fact any bone, might seem awefully constaining to a slug,
> but it also enables me to do things that a slug couldn't dream of.
> Reflexively, a slug's flexibility has its advantages.
Yes, I completely agree. I'm not arguing that Python is better than perl, or
perl better than Python. They are both tools, and I like to use the right
tool for the right job.
jgardn at alumni.washington.edu
Python Qt perl apache and linux
More information about the spug-list