Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

Is a Perl glossary necessary?

by Dragonfly (Priest)
on Oct 09, 2002 at 04:16 UTC ( #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!

Replies are listed 'Best First'.
Re: Is a Perl glossary necessary?
by rozallin (Curate) on Oct 09, 2002 at 06:37 UTC
    As a beginner to the Perl language, albeit with experience in other high-level languages, I'd welcome such a resource, and if it's anything like what I'm envisioning, it would be great to use as a quick command reference for everyone.

    I've been gleaning my Perl knowledge from the third edition of the Llama, which prevented me from running away screaming and sitting in puzzlement as to where the Perl vectors are. ( thanks merlyn++ ), lurking around USENET and from PerlMonks (although admittedly the obsfucated section scared me away for a couple of months, until I realised that you were trying to be difficult, and Perl didn't have to look like that. :) )

    I would really like to see a Perl Glossary with information about all the commands, modules, and general commentary about the community surrounding the language, written by Perl users collectively. The sort of information we'd need (though this depends on what is trying to be explained) would involve:

    • Name
    • Syntax
    • Description of what this does
    • Any attributes this has
    • An example of how and what this could be used for, with explanation
    • Any advice, warnings, tricks, etc.

    Of course, it's not supposed to replace all the existing resources we have (and we can leave some of the more subtle jokes of the community undocumented to surprise new initiates), but it would be a good thing to keep around, and I know that I would like to research modules etc. in order to learn more about them (and I'm sure that people who contribute to the glossary might learn new things about their chosen entries from other monks too.)

    Any thoughts?

    -- rozallin
    The Webmistress who doesn't hesitate to use strict;

Re: Is a Perl glossary necessary?
by Zaxo (Archbishop) on Oct 09, 2002 at 04:47 UTC

    For some words, like 'list', Perl has several traditional uses. Perhaps a dictionary format, with several definitions, would be better. I had experience with other languages, but there was a significant period of confusion in my learning Perl.

    I don't think Perl should dumb down because of that. The glossary idea strikes me as the right thing to do.

    A few other words for the glossary:

    • void, scalar, and list context - how tightly can context be described?
    • hash - compare to dictionary and association in other languages, describe a hash table to justify the term
    • map - describe as a transformation of a list
    • grep - compare to map, describe similarities and differences with grep utility to justify the name
    • regex - simple description as a pattern specialized for string matching, enough history to justify the name, comparison to other versions.
    • reference - compare to addressing in the common sense, speak of ability to follow dynamically changing data.

    Is that the level you think is needed?

    After Compline,

Re: Is a Perl glossary necessary?
by PodMaster (Abbot) on Oct 09, 2002 at 09:10 UTC
    I don't know what to tell you. I learned perl completely from the documentation (reading perlmonks every day didn't hurt either), but I was not new to programming. The perl documentation is intended to be an introduction to programming, but i'm not against a perlglossary page. I'd rather call it perldict, and have `perldoc -d word' look like `perldoc -f func', even if they overlap.

    Like always, this is user contributed documentation.

    I think someone ought to set up a neat little CGI::Application/DB_File program to facilitate the creation of perlglossary, so that it comes to existence real fast.

    There exists Perl Developer's Dictionary by clintp.

    Obligatory link: How to RTFM ;D

    ** The Third rule of perl club is a statement of fact: pod is sexy.

Re: Is a Perl glossary necessary?
by chromatic (Archbishop) on Oct 09, 2002 at 06:00 UTC
    I don't believe that I have ever come across anything that explained...

    You just linked to it. A general purpose dictionary should answer many questions.

    [T]he meaning of uncommon words should be explained the first time they are used

    That is a good goal, and all tutorial writers should follow it appropriately. I don't think it's the right goal for reference pages, though. How do you define "first"? How do you choose exactly which examples to highlight?

    I'm not convinced that there are a lot of people learning a computer language without some practical goal in mind. Perhaps a better question is, "How can we teach Perl in the appropriate context of solving problems?"

    Don't let me stand in the way of doing something useful, though. :)

      The closest thing I ever found to a Perl dictonary was The Coriolis Group's Perl Black Book, which has served me well and saved my butt a few times. It's similar to O'Reilly's Perl cookbook, but a bit more for the beginner.

      Unfortunately Coriolis is apparently out of business, so the only way to find these now is used.

      All in all, the whole concept is an excellent idea to pursue, although I think you're right in that teaching in some particular context is perhaps a better slant than just another available reference.

      There is no emoticon for what I'm feeling now.

        As far as I can tell, Coriolis is certainly not out of business - at least, they're still publishing books. has the Perl Black Book new at 41.99 here.

        As far as a Perl glossary/dictionary goes, I think it's a fantastic idea. I'm relatively new to Perl myself, and although I have a lot of experience with other languages, some of the concepts could certainly have been explained much better.

        I think the idea is certainly worthy of follow-up, and I'm pretty sure that there's plenty of people out there that'd be willing to help set something like that up.


Re: Is a Perl glossary necessary?
by kryberg (Pilgrim) on Oct 10, 2002 at 03:36 UTC
    I don't think the lack of explanation as to why someone would want to perform a particular perl application is a problem unique to perl. It happens in all programming languages. I've taken a couple of C++ classes and I've never seen a good example of why I'd want to create a binary tree or a doubly link list template.

    It sounds like you must have taken a formal perl course if you had to memorize operator precedence. The best way to learn perl is not by taking a course, but by programming. Through trial and error you'll learn operator precedence and that kind of stuff, not by memorizing it for some test.

    I totally agree with you about seeing more complete programs shown as examples. That is something I did not like about the Llama and Camel books. For that, I really like Perl How to Program by H. M. Deitel, et al - I don't think this book gets enough credit in the perl world.

    I think this perl glossary sounds like a good project for you to develop and hone your perl programming skills!

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://203826]
Approved by Zaxo
Front-paged by jarich
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (4)
As of 2022-01-17 17:24 GMT
Find Nodes?
    Voting Booth?
    In 2022, my preferred method to securely store passwords is:

    Results (51 votes). Check out past polls.