in reply to What should you know before you start to learn Perl?

Thinking back to the mistakes I made in my first year of perling ...

I realise that the first of those may be somewhat controversial, but I found that by using Windows, I didn't learn as quickly as I could all the tools that support a perl user on Unix-a-likes, because by the time I switched to a Unix environment I'd learnt horrible labour-intensive work-arounds. I'm *still*, 15 years later, learning better alternatives to those. Using Windows crippled me as a tool user.

In your second year as a programmer (not necessarily your second year of perl!) you should learn how the OS creates processes, how they talk to each other, how I/O works, and the basics of filesystems - what dirents, files and inodes are and how they're related. MJD has two excellent presentations on this.

  • Comment on Re: What should you know before you start to learn Perl?

Replies are listed 'Best First'.
Re^2: What should you know before you start to learn Perl?
by Corion (Patriarch) on Nov 09, 2010 at 11:51 UTC

    With regards to "Don't use Windows", I would change that to "Use at least more than one operating system". Knowing only one (kind of) operating system makes you blind for things that could be different. Very often, I see Perl programmers simply take (and propagate) things as a fact, like "file systems are case sensitive", "you can delete an open file" or "file locking needs cooperation", when they happen to be just quirks of the one operating system they use.

    Of course, Perl is more geared towards programmers wanting all the world to be like (some incarnation of) Unix, but across with unixish operating systems ranging from HPUX over Linux to OSX, many assumptions don't hold true. Being able to quickly identify and question your assumptions is a great tool, and being exposed to a diversity of operating systems helps hone that skill.

      "Use at least more than one operating system"
      Redhat and Debian? ;-)
      Of course, Perl is more geared towards programmers wanting all the world to be like (some incarnation of) Unix, but across with unixish operating systems ranging from HPUX over Linux to OSX, many assumptions don't hold true.
      Yeah, but don't overdo it. The other extreme (which you find voiced on Perlmonks every now and then) is the assumption that every piece of Perl code should run on every platform under the sun (where "every" often turns out to be "Linux" and "Windows"). I wouldn't be surprised if more than 90% if the code written out there is written to solve a particular problem/requirement/job for a particular machine. It doesn't make sense to spend an effort in making your small script cross-platform if it's going to cost millions to port the environment it runs in to a different platform. It'll be a wasted effort.

      While both of you said sane things, we're now diverging from the original answer. If we start giving advice along these lines, we're way more advanced, and giving advice about portable programming and Module-Quality (through testing).

      Modules should not only be tested on as many as possible OS's (and versions thereof), but also on as many versions of supported perl versions, threaded and unthreaded, 32bit and 64bit, with or without longdouble and with or without DEBUGGING.


      Enjoy, Have FUN! H.Merijn