Join PerlMonks! ;) Read the Tutorials. Learn your way around the perl docs.

Indeed. One of my dearest ambitions is to create my own little language, preferably in Perl.

If you think about it, almost every data parsing and control interface program has at its heart a parser for a little language, although usually one that's not very general purpose. Where things get fun is when you add an 'eval' command and the ability to extend the language by defining new functions. I learned about those in one of my only college CS classes, a 200-level language survey class where one of the languages we studied was LISP. Putting X to the power of Y, I was off and running. When I started working commercially, my assembly language microcontroller programs ended up with read-eval-print loops and in some cases even a crude function-definition capability (more like shell scripting than true language extension) with an eval+apply function that checked for user-defined command scripts before going into its primitive list. I use this model when I can, in almost every complete system I write. Once you understand the concept, doing it consciously becomes second nature.

Perl makes it easy, since extensibility and meta-progreamming are built-in resources, but the concepts are valid on any platform and are highly recommended for study and rumination. I've used it effectively in 8051 assembler, C, and even Smalltalk.

with thanks to Thant Tessman, this quote:

Greenspun's Tenth Rule of Programming:
"Any sufficiently complicated C or Fortran program contains
an ad-hoc, informally-specified bug-ridden slow implementation
of half of Common Lisp."

Don Wilde
"There's more than one level to any answer."

If I could go back in time to when I just started learning programming I'd have many much more important pieces of advice to give myself.

Update: Considering I was about twelve at that time, most of it would probably not make sense to the young me though :-( I guess I'd need to play guardian angel for myself, giving the advice piece after piece at the right times.

• No bugs ?
• Code easy to read ?
• Small memory print ?
• Fast code ?
• Programming fast ?
• Code Easy to maintain ?
• Well written documentation ?
• Reusable sources ?

• Don't look at Matt's Script Archive for examples
• undef($foo) is not equivalent to !defined($foo)

(That last one bit me really badly in my first big project ... shift/unshift set the meme in my head, and when i typed it and ran my program, sure enough $foo was undefined ... after that line was executed)

use strict;
use warnings;
[download]

But there are two things I'd like to show my younger self.

The first thing is how much a test suite can speed up development. I knew, then, that tests are good, but was just too lazy to write them. Now I really appreciate tests, and how much they can help you in finding bugs if run every so often.

The second thing is how easy some things are that looked very complicated back then. I always thought that writing a parser or (unthinkable) a simple compiler was horribly complicated - and lots of other things.

Some of this changed while reading other people's code, some by thinking on my own, and the compiler and parser thing by reading Let's build a Compiler

Both of these points are nothing that my younger self believed if being told in one sentence, so I'd have to really show it.

esk555:

I'm replying quite literally to the question of "what can I learn early-on to make learning the hard things in Perl easier?" And with that in mind...

I'm not going to rant too too much about this (I feel like I could type a book to that question) so here's just one angle: Approach Perl as it's own distinct language. It's exactly because Perl is a hodgepodge of all these OTHER *nix wizardrys slammed together, that we must treat it as UNIQUE (i.e. NOT "it's just like the shell" or NOT "it's an awk regex".) It's not just a Awk/Sed/grep/shell facade, it's a language that supports many different types of other languages. I'm not saying ignore the history -- I'm just saying approach Perl as something that's like nothing else. It's general purpose like you never knew general purpose. :-) Once you accept this fact, you'll be able to break outside of that damn box that we all start in...

Maybe the question becomes: How do I treat Perl as it's own unique language? I would say assumptions are the enemy and doing it yourself is the best way to learn. Solve real problems. Refuse to do the same tasks over and over, instead find ways to do them with Perl. Perl can do anything, and therefore, so can you.

Never stop learning, too. ;-)

Kurt

"If I had only known, I would have been a locksmith."
-Albert Einstein