use Perl

Last week I posted a thingy on use.perl.org which is my first blog for a while. Today I recalled the blog and how I had got there. It is interesting following links when idly browsing. This was my path:-

• Tom Hukins from mk.pm posted a link to YAPC::EU videos
• I watched the video by Dave Cross on the Perl

I am reading MJD's Higher Order Perl again and its great to see that my time reading other books on Perl has not been wasted. The first time round I read the words but I did not understand them. Now I am on the inside looking out rather than on the outside looking in.

It matters not how many times I look around I always come back to Perl as it is now the language that I know more than any other. This is a really great thing to realise.

I bought 'Effective Perl Programming' by Joseph N. Hall and Randal L. Schwartz, about two years ago along with 'Intermediate Perl' and 'How to Joust Underwater'. When it arrived I quickly flipped through it and decided I could not really understand a lot of it. My decision then was that it was not the book to read until it looked more friendly.

I have made a decision. Having made friends with the internet again. (I had a long and protracted argument with it and decided that we ought to go our seperate ways for a while whilst I found out what the rest of the world was like.) My decision - to eat more cheese, if that was at all possible and to plan a new project out and do the whole thing in Perl. I have worked piecemeal on stuff and have several projects that have been done sort of half-heartedly in Perl or PHP or even ASP but they h

Well after what seems like several decades I am finally going to Review 'Intermediate Perl by Randal L. Schwartz, brian d foy and Tom Phoenix. The book is on the whole very well written and has an amusing style which belies its importance. Initially I read Randal Schwartz and Tom Phoenix and brian d foy which gave me the basics, enough in fact to use some cgi scripts that, although now need a re-write to due my added knowledge, are still in use today.

Since FTFM(Finding The F*****g Manual - courtesy of dagolden) and now being able to RTFM whenever and wherever I am as long as I have access to Perl means that I don't have to worry about remembering everything or take loads of dead trees around with me. I used to wander off with a laptop and a book in hand, sit under a shady tree with the sound of the wind rustling in the trees and fawns pronking in the meadow then settl

Thanks dagolden its good to be read and heard. Its also a nice quote.

How to learn how to get help in Perl

I made a great discovery today but it has taken me a few years to get to it. I have wondered why it has been so hard to get into the shiny ball that surrounds some of the programming languages. This is not just Perl but many of them. I started to compare the way I learn text editors with the way I have learned programming languages. Vi was the first real editor I decided to learn.

You have prompted me to follow up a few things that I had started and that I had not been finished.

Interestingly I was chatting this over with a friend and he asked if I generally worked from the beginning or the end. Usually I visualise what I want and then start at the beginning keeping the end in sight. He suggested visualising what I wanted and then asking '..what would be the previous step..' and so on. My immediate reaction was that I was not too comfortable with that way of looking at it, however your method now looks quite appealing so I will have a look at it.
It is also interesting that when I was working some of this stuff out on paper I drew blocks to represent the code, so perhaps this may work for me too.

Something else also dawned on me that in my comparison with the way I design graphics I equated buttons in a graphics program with buttons/shortcuts in the the ide or text editor rather than seeing that the buttons in a graphics program as being equal to the functions/methods in Perl

Thanks for the feedback and book reference, I will take a look

Don't let the language dictate your thought processes #1

The problem I have found of coming to a different discipline (graphics to programming) is that I forgot how I learned the disciplines that I was familiar with in the first place. Today I was able to untangle some of this conundrum.

It started with the statement 'Don't let the language dictate your thought processes' which is similar to 'Don't let the media mask the message' but in a different guise.

The People

This is often overlooked or just mentioned as a footnote, but it is the reason that I started to look at Perl in the first place and why I have come back to it several times (sometimes kicking and screaming).

My other main criteria was that I did not want to have to learn one language to do sysadmin stuff and another to do web dev stuff. Perl seemed to offer both.

Last night and tonight I started to read the code in several Perl modules and I realise why it is a good thing. It seems daunting sometimes as I have felt that I need to know so much more before it makes any sense. References, anonymous arrays/hashes and autovivification has started to make sense and by reading the source code I can see how this all fits in even though I am not accomplished at using them yet, the whole subject is not such a closed book.