Not many people would argue that Perl is not one of the most flexible and useful scripting languages available today. Most, however, cannot look past that to see it as a programming language, and a powerful one at that. No one will argue that they could develop a prototype of a product in Java faster than they could in Perl, yet most would abandon Perl as soon as development "gets serious." After all, Perl is just a scripting language. No one in their right mind would attempt to use it for anything besides CGI and gluing other programs together.
The fact is, Perl should be taken more seriously as a programming language. The problem is that most of the Perl material in the world has been developed as either a fancy shell script or a stripped down prototype for C and Java projects. The very things that attract people to using Perl for these quick and dirty hacks also stagnate their progress in the language. Most instuctional Perl material only teaches enough to get an interested programmer informed enough to write shell or C programs in Perl.
Perl was developed by Larry Wall, a linguist and computer scientist. It started life as a simple scripting language, but under heavy influence of a linguist and a large community, grew in to its own language. Today, Perl brings all of the tools of any other language, plus much more, to the table. Most of these tools lie unnoticed by most beginners because they only know enough about Perl to be bored by its lack of support for typed variables and its maintainence nightmares. All of this is a very myopic view of Perl as a programming language. Through the eyes of a C programmer or shell scripter, Perl can look ugly and slow. However, if you're learning to think in Perl, not in C or shell script, Perl begins to become beautiful and fast.
Perl Style
Perl doesn't force you to program in any particular style. White space is neglible. Larry Wall and the community have come up with a set of style guidelines that serve to make Perl look consistant and thus more maintainable. The accepted style for programming looks like this:
my $var = 0;
$var = <STDIN>;
chomp($var);
if($var == 0) {
# do something
}
else {
# do something else
}
The key points in perl style are:
- Left brackets ( { ) begin on the same line as the if (or for, etc.).
- Right brackets ( } ) are usually found on a line by themselves.
- Else is not on the same line as the if's closing bracket.
These rules are not enforced by the interpretter, and are by no means "superior" to any other formatting style. They are agreed upon by the vast majority of the Perl community (including its founder) to be the definitive style of Perl Programming. That's good enough for most people. See 'perldoc perlstyle' for more.
Perl Pragmas
Pragmas are modules that change the behaviour of the interpretter. Included in the core distribution are several pragmas designed to make Perl more maintainable and a lot smarter. Regardless of how great of a typer or how smart a programmer is, there is one pragma that should ALWAYS be on. That pragma is "strict" and is activated with the following line of code:
use strict;
Most veteran Perl programmers shudder violently at the site of a 500-line Perl program without strict activated. No matter how great the original author of the program had been at checking for errors, the people who eventually modified the program probably did not spend as much time debugging. For the sake of maintainability, (and performance, to be demonstrated later) ALWAYS use strict. Under the "strict" pragma, all variables must be declared BEFORE they get used.
Taking things one step further, we could enable warnings in our Perl program to be more aware of deprecated syntax/functions in our program, as well as alert us to other potential problems. Another useful pragma is the diagnostics pragma that outputs detailed information about how the interpretter is reading the code it's presented. You may enable these pragmas with the following lines of code:
use warnings;
use diagnostics;
See the Perl documentation for more detailed information.
Perl Scope
Using the strict pragma, we need to declare all variables before they're used. There are two scopes in which variables may be declared, Package and Lexical. How does a programmer decide which scope to use for their variables?
Package Scope
Package Scope is the default variable scope in Perl. If we were to run this program:
#!/usr/bin/perl
$message = "Hello World!\n";
print $message;
The variable $message would be created in the containing package's scope, in this case "main". An entry is created in the symbol table for "$main::message", the "fully qualified package name" for $message. This example would not pass the strict pragma as we have used the variable $message without first creating it. By using Perl's our() function, we can create package variables in the current package:
#!/usr/bin/perl
use strict;
our $message = "Hello World!\n";
print $message;
Package variables are accessible to any package through the use of their fully qualified package name. This name consists of the sigil ($,@,%), a package name, followed by double colons, followed by the variable name. Package variables are also "global" in that they're accessibility and existance is the entire program from declaration on. This means that package variables never go out of scope, and thusly are not destroyed until program termination.
Lexical Scope
Lexical scope is more ideal for the majority of variables programmers use regularly. Lexical scope allows a variable to exist only within its containing closure. The widest scope available to a lexical variable is the entire file in which its declared. No entry is created in the symbol table for lexically scoped variables and these variables will be purged once they're out of scope. This use of Perl's garbage collection can save resources and prevent variable collisions. Lexical scope has to be declared by using Perl's my() function. The preceeding examples would be more correctly written as:
#!/usr/bin/perl
my $message = "Hello World!\n";
print $message;
my() or our()
Unless inside of a non-main package, always use Lexically scoped variables. For most practical applications, the benefits of garbage collection will be more rewarding than a globally accessible scope.
Silverlight 2 SDK for Visual Studio 2008
Article: What Does it Take to Build the Best RIA? 
Expression Blend 2.5 Preview
The Hottest Mobile Platform Meets the Hottest RIA Platform 
Article: Leveraging Your Flash Development with Silverlight 
IE 7
Firefox 2.0
