Before we start looking into my experiences with Java, I learned three important things about learning Perl. That is, there are three different ways you can learn Perl. There's the good, the bad, and the ugly. Let me describe them.
The bad way is to learn from examples, especially examples from the so-called "Camel Book", because most of those examples are pretty much to show off as many features [in] as little amount of lines in the book as possible. Because of that they're pretty much unreadable. There's another book called "Learning Perl". It's much better but most people prefer copy-pasting features from sample code. So what ends up happening is that people with little to no previous experience with programming (or "serious" programming), they would just pick up that book and see how much copy-pasting they can do from the examples until their code does what they want it to do. It's really bad because Perl has a ton, and I mean, really, a ton of hidden features, functionality, weird ways of doing stuff that don't make sense. And if you're just copy-pasting code then you have no idea what it's actually doing except, well, input and output (what it does as a result), and WHY it's doing that you have no idea. And if you have limited programming experience then you'll end up producing code that even you yourself don't know why it's working in the first place. Not because of abstraction, just because you have NO CLUE how to properly write software and at the same time you're using a language that's so complex that beyond the examples you have no idea what it actually does.
So the ugly way of learning Perl is from code examples from people that learned it the bad way. That way it's really bad because you end up not knowing anything about Perl, like me, and taking other people's code, like me, and that code is buggy and your job is to fix it. First of, the programming behind it made an actual bug, and the second this is that the code they were using, they have no idea what it's doing in the first place. So even the original software developer would have no clue about why the bug's happening, and when you're reading the code you don't know if the code is [...], if there's any sense to it. Like, is that line of code there supposed to be doing what it's supposed to do in the programmer's head, or the programmer meant something else, or the code examples he based himself on meant something else altogether. For me this was a really, really harsh experience learning Perl because [I was] learning from examples of other people.
What really saved me was not the "camel book" but really the Perl reference, the "man pages" or the "perldoc" they would call it. That's a big deal because the Perl reference is, well, it's really difficult to read, it's a reference book, and the examples are even more complex, but it covers everything. I mean, litterally, everything. So you're not reading the "camel book" or [the] "Learning Perl" book and you're kind of trusting the author or what the author is saying. No, you actually have what it's supposed to do and all the intricacies of the weird stuff it's not supposed to do and what if that argument is missing or not or if it's undefined, etc. It's really, really, really hard to read, but then when you're trying to figure out somebody else's code and that somebody else didn't understand it in the first place, that kind of saves you because it makes you say: "Hey! Maybe I could just rewrite the damn code in the first place, while keeping compatibility." So that's pretty much what I did. That's pretty much a good habit that I have. Almost all the time that I've seen other people's Perl code, it looked too much like people that don't know what they're doing, so I just end up rewriting the entire code. Of course, if I'm lucky I get Perl code from other developers that is almost pristine. Mine's not as pristine as theirs, but there's a tendency that good Perl developers are very clean in their syntax. There are lots of freedom, lots of optional stuff you can do with the syntax, but you restrict yourself to something that almost looks like C. You don't do Object Oriented Design in Perl, you don't do anything too advanced like function polymorphism, you keep it really, really, really simple. Why? Because the syntax is almost ambiguous.
So the good way of learning Perl is, well, the Perl reference manual. That's what I went through. But also using the Perl debugger. The Perl debugger is command-line based, [and] it's just like my experience in C, it's a life saver. Especially since Perl is a scripting language, so you can interpret Perl code from within the debugger. And you can see nested structures. Sometimes when you're stuck with hash references, scalar references and stuff like that, it really starts making sense.
My overall opinion of Perl, well, I'm a bit biased [since] because of work, It's been pretty much the programming language I use the most. It's a language that's been pretty much "engineered", you know, with features that's been added over time, because it makes sense, because it was useful, not because of some overall design elegance or completeness or [provability] or anything. It's just because "We need that feature, let's cram it in." Perl was inspired by **awk, which was inspired by the regular expression command in **ed. It was just a gradual evolution. So if you followed Perl from its inception phase up to now then everything kind of makes sense and you're used to it. For any new software developer out there, I would tell them: Stay away from Perl. Because the first programming language you should learn is a programming language for which you actually understand what the heck you're doing. And Perl is really not that. Perl is really a language for when you've been programming for 10, 15 years, and you're kind of fed up and you want to do a one-liner on the command-line that does nested hash structures. But otherwise, just stay clear of it until you're mature enough to accept a programming language that has many, many design flaws.
Published on September 20, 2009 at 10:49 EDT
Older post: APJ 4: Learning Perl
Newer post: Testing twitterfeed