SPUG:Designing Programs

[Jonathan Gardner]

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 
naturally.

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 
look ;-)

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?
>

<in mymodule.py>
class widget:
	def add_el(self, el):
		"""Adds an element to the list of elements."""
		self.els.append[el]

<from the command line>
$ python
>>> import mymodule
>>> dir (mymodule)
( lists all the functions, variables, classes, and modules in mymodule )
>>> dir(widget)
( lists all the methods and attributes of widget )
>>> mymodule.widget.add_el.__doc__
"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, 
including yourself.

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.

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