Exploring Perl: A Journey Beyond the Basics

[meBigGuy]

I just feel like rambling on, so I will.

Perl gets a bad rap for being hard to read or maintain. But, in reality it is just as easy to read as C or any other language. What is difficult about perl are the regular expressions, which are notoriously cryptic. But, regular expressions are comment-able (embedded comments), but no one bothers.

I find the perl regular expressions to be MUCH more useful than the sed expressions, so I always use grep -P.

Of course, perl can be abused, just as any other language. The namespaces are pretty loose unless you enforce strict (use strict;). Also, people get freaked out about $_

I generally use it for post processing things. For example, write a script to reverse the title and author of a directory full of book titles. Or, use it to analyze histories from online poker playing. And I use the heck out of it at work (digital IC design/synthesis/simulation) for log filtering, file prep, etc. And Tk let's you have a GUI.

But I've done extremely complex things also, like some of my old hacking scripts.

The neat thing about perl is that you can solve your problem anyway you like. The language is flexible enough that nearly any structural approach will work. And the lists and hashes are amazing with easy access to all elements.

And, the things you can do with it on a command line, for example check the version of a tool invoked in a makefile ( I know, its really cryptic and proves everyone's point).

NOTE: DANG, code feature still formats so can't show my codeI use perl, tcl, python, C, C++ and a little java (well, verilog also). I hate tcl (An anal, confusing, language where spaces can be critical and things in comments can break the code (like unbalanced { } and some other tricky constructs).
Also, a 4 hour tcl process can break 3.5 hours in because of a syntax error (not interpreted until it gets there)

Anyway, just my opinion. Very few "real" programmers have need for Perl.

 

[jedishrfu]

Try using the quote tags if code doesn't work for you.

Or did you try '[ code=perl ]' to see if that works?

 

[jedishrfu]

Personally I've migrated through scripting languages often converting one scripts to the new language.

My timeline has been awk-.>perl->awk->python->awk->groovy->python

I looked at perl and used it for a bit but had problems with the RE which may have been implementation specific and so switched back to awk which seemed to be cross-platform capable always wishing though to have some of the finer RE features of perl.

I switched to groovy when I discovered it helped me work and test my java code. The weakness was installing the groovy jars on every machine I worked on whereas awk was always there. Groovy was also cool in that Grails a web app framework and Gradle an up and coming build tool use it as the base language.

Most recently I've switched to Python because again its on every machine I use and works consistently across MacOSX and Linux. The code is easier on the eyes and I don't have to resort to awk tricks of running shell commands and capturing the output to get what awk doesn't provide natively. I've even considered switching our project run scripts to use python over the standard shell scripting for flexibility and consistency as we use bash, tcsh, rsh... scripts from years of legacy development.

 

[meBigGuy]

I never could get the hang of awk. Perl was around when I started on scripting, and was "similar" to C, so I learned it first.
We use python to control lab instruments for verification and emulation.

I couldn't find a setting that could deal with the $ $ needed to imbed perl variables in a Makefile, so I edited out the second $ (was $ $_ with no space)

  # check the tool version
   @which ${CMD} | perl -ne 'chomp $_;if ($_ =~ /${VERSION}/) {print "\nRunning with $_ ";exit 0;} else {print "$_ IS WRONG VERSION!\n";exit 1;}'

 

[jedishrfu]

I forgot a couple of other scripting langs I used before the advent of awk:

tex - a Honeywell specific lang with a lot of cool features (see wikipedia article:

http://en.wikipedia.org/wiki/Text_Executive_Programming_Language

I used it for quite awhile and was disappointed to find it only worked on Honeywell systems.

The other scripting language I used was Rexx on IBM mainframes. It was very cool too.

http://en.wikipedia.org/wiki/Rexx

Awk I discovered by accident when I ordered the Thompson Unix shell toolkit for PC-DOS and it came with AWK and an AWK book. It allowed me to write awk scripts that could be converted to PC DOS exe files as well as run on the IBM Risc/6000 with some caveats. I like cross-platform programming a lot.

 

[FactChecker]

I did extensive sed/awk programming back when ADA was the specified language and other code had to be converted to ADA. The conversion required many alternating sed and awk steps. Perl was much more powerful for that type of text parsing and code auto-generation. I like that Perl is directed toward scripting. It is a tool that I use every day and probably average one Perl script a day.

PS. Real programmers DO need Perl

 

[D H]

Most recently I've switched to Python because again its on every machine I use and works consistently across MacOSX and Linux. The code is easier on the eyes ...

Easier on the eyes than what?

I like python for testing numerical ideas. If the script is going to involve regular expressions, plumbing, forking & execing, perl remains my preferred weapon of choice.

One nice thing about python is their list and dict comprehensions. Perl doesn't have them. On the other hand, perl don't need no stinkin' list comprehensions! It has better, more compact tools.

One thing I don't like about python is the inability to declare variables. Not variable type; that would go against the grain of python. But saying that a variable exists? I don't understand how that goes against the grain of python. Perl let's me get away with variables popping in out of nowhere if I want, or it let's me tell perl to not let me get away with that. If I'm writing a perl script and see that I'm on line 10 I'll shortly be on line 13 because I'll jump to the top and add three lines:

use strict;
use warnings;

(The last line is blank.) I don't even have to think while typing those three lines. Those three lines of code are muscle memory in my fingers.

 

[Silicon Waffle]

I agree Perl scripting is cool, I used to work with some for client-server request testing purposes.

 

[jedishrfu]

Python as a scripting language was easier on the eyes as compared to awk, bash, csh and sh.

The syntax of the these scripting languages can be very difficult to read and understand. Python is easier in that there's less { } and ; markers and no `...` expressions.

However, this is my subjective view on programming and others may see it differently.

 

[ShayanJ]

I started programming when I was in high school. The first language I learned was C++. I only wrote small programs. Then I learned PHP and after sometime, I was able to build a website with the ability to signup people and they could sign in and sing out too. It was really cool for me, as a high school student. But then I couldn't solve some weird problems and so just put it aside. Then I learned python. I really like it. The best program I can remember I wrote with python, was a program that could calculate the nth power of a polynomial. But actually I had to change the code for different powers and polynomials! But I managed to make it output the result with the standard math style. It wasn't easy! After python I went back to C++ and learned more about it. I really liked OOP, so I tried to master it. I was OK I think. The biggest and best C++ program I wrote was a program that could convert numbers between different bases. Not just the famous bases but any base theoretically. But practically, because of the finite number of english letters, it could only work with bases smaller than 64. It was a big class with all the operators overloaded. You could do the four elementary operations with operands being in different bases and get the answer in the base you wanted.
I really liked programming. But its years I didn't write a program for the sake of programming itself.

 

[Carno Raar]

I use perl, tcl, python, C, C++ and a little java (well, verilog also). I hate tcl (An anal, confusing, language where spaces can be critical and things in comments can break the code (like unbalanced { } and some other tricky constructs). Also, a 4 hour tcl process can break 3.5 hours in because of a syntax error (not interpreted until it gets there)

Why just TCL? Python also has this problem: http://imgur.com/p4fizq0

One thing I don't like about python is the inability to declare variables. Not variable type; that would go against the grain of python. But saying that a variable exists? I don't understand how that goes against the grain of python.

use strict;
use warnings;

I've seen quite a few people asking for python --strict. I personally feel it's more trouble than it's worth but I grew up on dynamic languages so it might be an issue of paradigm.

A good linter and IDE go a long way towards fixing this. I believe you can setup Emacs to do it if you work in a character based environment. I personally use Pycharm which will pick up undeclared identifiers, inner scope shadowing and typos in variable names (the last of which is slightly annoying since it will flag anything not in a dictionary such as 'otext'). It isn't perfect but I've not had that kind of error much since switching to it. In any case, this kind of bug is usually easily and obviously caught by your tests.

I agree that it's not perfect, but Python isn't Java.

 

[meBigGuy]

Yeah, python does the same thing as tcl with regard to being real time interpreted and not finding simple syntax errors early on. I'm guilty of not doing long runs with python, so it hasn't burned me enough times to think about it when I posted.

 

[Carno Raar]

If you have a lot of trouble with this, you should probably be looking at your test suite.

There are some great libraries like coverage (http://coverage.readthedocs.org/en/coverage-4.0a5/) that run your tests and check for unexecuted code. Thus you can see which code paths are not being run by tests. Fixing this should help to cover you against runtime surprises.