|
|
|
| go ahead... be a heretic | |
| PerlMonks |
Is a Perl glossary necessary?by Dragonfly (Priest) |
| on Oct 09, 2002 at 04:16 UTC ( [id://203826]=perlmeditation: print w/replies, xml ) | Need Help?? |
|
After working with Perl for the last several years (I think I began seriously studying it in 1999) it is my conclusion, for a number of reasons, that it is probably not the best language for beginning programmers. Most of the Perl documentation assumes some experience with programming languages, and since the Perl culture was gestated a fairly long time ago, many of the people who are around today who use Perl have forgotten what it's like not to know the very basics of computer programming, and therefore much of the documentation (even superb books such as Randal Schwartz's Learning Perl) is needlessly complex for many people. (merlyn, I say this having read the second edition; the third edition seems to be much more user friendly from a brief skim at the bookstore.)
I think that for many people, the biggest issue with learning a language such as Perl is that while the authors may typically reveal very concise and straightforward examples of how to do things in Perl, they often overlook the need to explain why someone would even want to do that sort of thing in the first place. In my experience, that was often a failing of the math classes I took in high school and college; it was never a problem to try and find new topics to learn (just check the syllabus); it was the application of those topics (like what the heck is a matrix, and why do I care, again?) that was never explained. Perhaps it's a chicken-and-egg thing, where without the requisite background in the "how", you will never understand the "why", but for me, it was a serious deterrent from pursuing anything that seemed to involve rote learning. For instance, asking a beginner to memorize the operator precedence order or what the characters in regular expressions mean, without explaining why they'd ever need to know these archaic and cryptic things, can be very counterproductive in attracting the average beginning programmer to a new language, and can make the language seem much more complicated that it actually is.
However, if you can shut off the part of your mind that asks the big "why" question, and simply accept that the lessons you are learning as you pursue mastery of Perl will gain application as time passes, then perhaps you will find that Perl is easy to understand, and that I am somewhat exaggerating the difficulties of learning Perl. But I think for many people, this is one of the areas where Perl doesn't necessarily succeed, and if we can improve on the situation somewhat it would probably serve to attract more people to a language that seems to be slowly falling out of favor in many areas.
The other difficulty I see in most Perl tutorials is that there is often a case of either-or involved, where either a small example will analyze the usage of one element of the Perl language (such as hashes, for instance), or else a very large program is deconstructed piece by piece, over the course of many pages. This can lead to some confusion, as there is the typical struggle of the student trying to "see the forest for the trees." I realize that most complex, creative fields such as drawing or writing involve many hours of learning the disparate elements that compose these fields, and that it is only with knowledge of each area that some mastery will be proven, but at the same time there needs to be a balance between the very complex and the overly simplified, or otherwise people can start to be either myopic or else too scattered in their studies. I'd like to see more complete programs shown as examples, but within a reachable grasp. I will never forget the experience of typing in short BASIC programs line-by-line from an Apple II magazine, saving the file, and running it to see what it did (or more frequently, to see where either I or the author had made a typo...). There were some pretty incredible things that were possible on those machines, despite their limitations, and that experience really showed me what a computer could and could not do. There are some excellent resources around that really show a thoughtful balance, with the examples being being both powerful yet easy to follow, but much of the time these resources are the exception, not the rule. These kinds of programs are really helpful, because much of the time they have very practical applications in real life, and usually they combine a few of the smaller items into one program so a beginner can get a grasp on how to combine the small parts into a larger whole. In any case, one specific item that I'd like to touch on briefly here is the frequent use of the word "sigil" to describe some of Perl's special characters. Whereas the word is frequently tossed around by Larry Wall and others in the context of comparing Perl with other languages, I don't believe that I have ever come across anything that explained that the word is in fact part of the English language, has been a part of the English language for nearly 500 years, and according to Merriam-Webster online, means "a sign, word, or device held to have occult power in astrology or magic." Now, given that many words used to describe programming languages or found within those languages are particular to our field, a beginning programmer might find the usage of the word confusing, or may have to glean understanding of the word through osmosis (contextual usage) rather than thinking to check a dictionary (as they may think it is a term unique to programming, or Perl). This is wrong; the meaning of uncommon words should be explained the first time they are used; it would help increase people's vocabularies and their understanding at once.
How can we resolve this problem?I hereby propose a perlgloss section be added to the man pages, to serve as a handy reminder that not everyone is going to be as literate as Larry Wall, and that some terms, while perhaps being fun and concise concise ways to convey exactly what a trained programmer means, are not always completely unambiguous when it comes to trying to decipher their meaning. I realize there is already a Perl Glossary, but it is not very extensive yet, and I'd like to encourage people to contribute entries to the glossary if at all possible. Currently, the glossary contains mostly a list of acronyms used within Perl, which are helpful, but not as many explanations of terms such as "array of hashes" (and why we'd want to use one) or what certain words mean when used within the context of discussing Perl. Furthermore (I'm sure some of you out there are thinking, "Isn't he done yet?"), I think that each entry in perlgloss should have at least two entries; the meaning of the word in the Perl context, and a simplified explanation of why someone would use the word or device within the Perl context. For instance, "persistence" could be defined as "a way to ensure that data is committed to disk, to protect against a computer malfunction, or to save the state of a program in case the data is needed the next time the program is run." and it could be further explained by denoting which modules in Perl specifically are used to accomplish this (i.e. DBI, Data::Dumper, etc). It wouldn't necessarily have to give a code example, even, rather it could be a goal of perlgloss to try and make each individual entry be easily readable and understandable by someone at, say, the 12th-grade reading level. It is my opinion that this would help enormously for the beginners out there who are intimidated by the complexity and richness of Perl's culture, and would be a very useful thing to include within Perl6. Now that I have invested so much of my time into learning Perl, I have a vested interest in making sure it remains a viable, popular language well into the 21st century, and so I'm trying to think of ways I can help further this goal. I'd like to help attract more users to this truly excellent language, because it is like an oasis of useful knowledge in a desert of bloated .NET's and WebSphere craplication servers. I know I'm not alone, and basically these thoughts are just an accumulation of things I wanted to say before (while I was learning Perl) but felt that I didn't know enough about Perl to really comment on. I know this port is really long, and I'm sure I've made some mistakes in this post, so if you have any thoughts or comments I would really appreciate them. Thanks for reading!
Back to
Meditations
|
|
||||||||||||||||||||||||||||||||||||||||