Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

redspike (9392)

  (email not shown publicly)

Journal of redspike (9392)

Tuesday August 24, 2010
04:23 PM

Why do I blog?

Last week I posted a thingy on 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:-

I blogged

Perhaps the more interesting thing is why I did not blog for such a long time. That question has not really been answered yet. In this respect I have failed. I do not keep up any other blog other than this one at the moment, so it was not as though I was blogged out.

Another case of the missing cheese and scullery maid.

Monday August 16, 2010
08:55 AM

Inside looking out

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.

Sadly I missed YAPC::EU again this year and I have really missed meeting my friends there. I hope to make it next year. It always has the feel of a festival, if there were tents and bad sanitation it would be exactly like it.

A few weeks ago I had to compare two bank account numbers and before I knew what I had done I wrote

perl -e 'if ("0123456789" eq "0123456789"){print "yes"};'

on the command line. It did not dawn until later what this meant. It means that having bludgeoned my brain with so much Perl it has eventually and begrudgingly given up and decided to come along with me for the ride and even started to think in it without telling me. It just let its gaurd down and it slipped out.

Monday March 22, 2010
10:10 AM

Effective Perl Programming

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.

It was spotted last week and jumped out of my bookshelf. As I opened it and started to read it, it did not seem to be the book that I had first encountered. In fact it was really quite accessible and rather exciting. I greedily started reading it and skimming through the code examples. Not until I had read it for about an hour did I see that what was once a mystery was now becoming clear. To my delight I could see things that I could use and apply.

This I am sure is not unusual. It was just the right book at the right time, even though it had collected dust on the shelf for a couple of years. I particularly liked the 'Schwartzian Transform'. It felt like reading module source code because it looks like alot of the examples are realword rather than contrived. If I feel that the code is real code then I do seem to take it more seriously. This may be unfair of me to do but its one of the ways a subject keeps my attention.

Sunday March 14, 2010
07:08 PM

This is the day - or is it tomorrow?

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 have all just sort of grown out of themselves rather than being crafted and started from the beginning without having the nagging feeling that I am doing it the wrong way or it was a Thursday at the time.

Its going to be the same sort of decision to do everything in Vi from a certain date and sticking to it however painful or tempting it was to go back to the way I was doing it before, which actually I can't remember. So this is it brothers and sisters its Perl or bust. Not sure what that means, but I have just spent two days having to sort something out in DOS which I think has finally pushed me over the edge into some semblance of sanity. What it has really done is made it as plain as the nose on my face that the only way to get something done is to set sensible goals and get them done. As I did not have a choice whether I could program in DOS or not I just got on with it.

I remember the Wrox press books had and still have (unless someone has stolen into my house and gone through all the books and removed them.) 'Just Do It' printed on pages in between chapters. I often talked to them and explained that I could not just do it as I did not know what I had to just do. Now I do understand the relevance. Thinking is not doing and neither is thinking necessarily learning in the same way that doing is not always thinking or learining. However they can be all three.

The thing about the last few months is that I have spent a long time saying to myself - I just need to learn a little more and I will be ready to do this or that. Where in fact waiting for the time when I have satisfied myself that I know enough is never going to happen. I just thought that I did not know enough. Well its obvious I do know enough so I am going to stop pissing about.

Friday March 05, 2010
05:34 AM

Intermeditae Perl Review

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.

I then went onto Programming Perl by Larry Wall, Tom Christiansen, Jon Orwant which I read as a sort of novel, when I told this to Larry Wall at a YAPC he said that it was mostly fiction anyway. It introduced me to alot of the advanced features in Perl but was a bit heavy going. After I had read it I wondered if there was something inbetween this and Learning Perl, something intermediate.

I know it seems obvious not but I did not look for a book called Intermediate Perl. I found this sort of pattern happening a lot in my jourmey through Perl, the obvious is so obvious I miss it. I have tried to start looking for the obvious before I hare off and look for the complicated and down right obscure which always seem more easy to see. As I had not cultivated the culture of 'The Bleeding Obvious' I bought a few others which, although good in their way were not really suitable at the time for where I was at. Eventually I got a copy of 'Intermediate Perl' and it all made more sense.

I read another review online which suggested a different order in which to read the chapters. The suggested thing was to read Ch 3 after reading Ch 10 and then read Ch 15 because it was thought that you need to know about modules after learning about building larger programs. This I did and it seemed to make more sense. Apart from my normal gripe about not explaining how to get help through Perldoc and a few examples which when typed in verbatum do not work (bottom of page 4 in particular its is not that it is wrong but to make it run you have to do a little more than is written) the book helped alot. This kind of thing is not a problem half way through the book, any book, a little assumed knowledge has been learned, but it is important to make things absolutey implicit in the first few examples. Implied knowledge is an easy way to dishearted anyone and could in extreme cases cause someone to give up. Reading it through at least twice meant that a few things clicked eventually and gave me a sense of achievement when I understood the concepts and put some of them to the test. The story of Gilligan, Skipper, The professor and crew meant a simple but powerful thread kept the example real. Although imagined, these examples explained in fairly simple terms some very complicated ideas that I found fairly easy to apply to real world applications. Having read 'Programming Perl' first meant that I had gone a long way to understanding many of the ideas but anyone going about it in the right order would have less of a virtical wall to look at when they got to the 'Camel'. I use Intermediate Perl as a reference at the moment and to re-read certain chapters when I have a quiet moment.

I would recommend this book to anyone who has just got through Learning Perl or who is coming to Perl from another language and wants to start in a comfortable place before scaling the heights.

Whilst reading the chapter on references I was struck by the one of the many lighthning strikes out of the snaffed and blurreddy that is 'The Bleeding Obvious'. It may be called a reference but I thought that that was just its name. Unlike a the fact that a variable is called a variable because its value can vary but not its declared name,(I know that that is not necessarily the case as it is its address in memory that does not change or perhaps something else that I don't know yet, but humour me) a reference is called a reference because it is a reference to some thing, usually a scalar, array, subroutine or hash or something. As a reference it refers to something. You cannot believe how I wondered how I had managed to get through at least 3 rather large books before it finally sank in. I am not sure if it was the fact I did not read the right books in the right order or the fact that I was not really reading what I was reading. Either way, I have had the same experience several times. I think that because it has always been pointed out that Larry Wall is a linguist and therefore has crafted Perl in a liguistic way that I assumed the opposite. I have the same experience with other languages and with other things too but that is part of the joys, or not, of not taking the obvious as obvious. Tell me one thing and I will often assume the opposite because that is what I thought you meant, and just when I think I have got it I will the think the opposite of the opposite which is of course the obvious but not everytime. Sounds dumb when you write it down but with everyone trying to be so damn clever I am not sure who is genuinely clever and who is trying to look clever by inference. In Larry's case I think he is just being genuine.

I will do a more indepth review of this book as it has helped me a great dealm but this will do to get started for now.

Sunday February 14, 2010
06:58 PM

Confidence in one thing leads to confidence in another

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 settle down to have a leisurely look at some aspect of Perl, start testing something out, forget the exact sytax and have to thumb through pages and break the train of thought, by which time it had started to rain and the fawns had gone home for tea and I had forgotten what I was trying to do and would have to start all over again.

Its a amazing what a little confidence, in one language brings to another and how it takes all the anxiety out of the process of getting things done when you don't know quite what you are doing but know where to go. Finding the door to all knowledge and wisdom that is Perldoc that has been hidden from me has given me new found confidence, even perhaps a rather cavalier attitude to other new things too.

I have had to learn how to use Joomla as it is the preferred tool of one of my clients. I have tossed around with it a few times but never really got to grips with it in the past. As there is an incentive to use it I found myself getting to grips with it a bit more easily, even though my first reaction was to resist it.

There is a little lesson there too: learning is greatly improved when there is a sensible achievable goal with a little bit of lookah involved and a doable deadline . Not the huge, re-invent the world in a day type mountains I have set myself in the past. Not impossible if you have all the tools to hand but a bugger when you can't find the secret to planet making in Mrs Beeton's, Omelettes for All Occasions.

As learning experiences go it was not too bad after all it is like using a WYSIWYG editor with a few extra functions. What at first seems a weird way of linking everything together, is not in the end a bad concept, its probably more the case that the documentation is aimed at the non-programmer, which did help. Of course I am always comparing experiences to see if one will help with the other.

As soon as I had installed the system, had a play around with a template or two and then put some content in to be able to get a feel for what I was looking at, I opened the php and css in a text editor and started to customise everything in the code rather than from the web interface.

If I had had to delve too much into the PHP I may not have enjoyed the experience quite so much as it is not my language of choice and I could see from the little of the code that I did see that I would not have done it that way if I had started from there in the first place. I was just pleased that I did not run off screaming into the wind.

Honestly, a few months ago I was so hacked off with all programming languages that I would not have attempted to even install a new cartridge in my printer in case it involved me writing Post Script. The difference now is that the more time that I have been learning Perl the better I have become at seeing the commonalities in all languages and systems and so when faced with a new challenge things seem clearer. I am nothing if not persistent.

I think it proves that I am climbing the tree and tasks that seemed a real arse ache a few months ago are now possible because Perldoc had taught me one vital lesson - have the confidence to know that you will be able to get to the next step, and after that you will be able to get to the next. Belief in the ability to be able to do something because you know how to find out how to do it.

I may be repeating myself here, I said I might be repeating myself here but it is worth repetition, I said its worth repetition.

Saturday February 06, 2010
05:52 PM

Its not kept behind the scullery maid under an aarvark

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.

  1. Started it at the command line
  2. Wondered how the hell I opened a file
  3. Wondered how the hell I closed a file
  4. Wondered how the hell I edited it
  5. Wondered what all the fuss was about
  6. I then bought a book and read it
  7. Understood somethings and not others
  8. Discovered how powerful it was and realised what all the fuss was about
  9. Flirted with the idea of using it all the time
  10. Found I could use it to do something I needed to do
  11. Discovered how to use the help files
  12. Understood what to do with a file and to do something useful that I could do however small
  13. Used it infrequently when I had to during an ssh session on a server or just played with it
  14. One day decided to use it all the time and be damned
  15. It took a bit of working out and the first project I did with it took at least twice as long as normal
  16. Now I use it all the time except when I am using Emacs in fact I cannot imagine life without it

So what is the difference with programming? Well I thought there would not be too much after all people have said 'if you can use Vi you can program'. So here we go with Perl.

  1. Started it at the command line
  2. Wondered how the hell I created a variable
  3. Wondered what the hell I did with a variable once I had one
  4. Wondered how the hell made anything do anything to do anything
  5. Wondered what all the fuss was about
  6. I then bought a book and read it
  7. Understood somethings and not others
  8. Discovered how powerful it was and realised what all the fuss was about
  9. Flirted with the idea of using it all the time
  10. Found I could use it to do something I needed to do
  11. Null
  12. Null
  13. Used it for a few scripts which help with some very basic cgi stuff
  14. Would liked to have used it for lots of things but could not work out how
  15. Became frustrated because it seemed like a shiney ball that I could not get into
  16. I do not use it every day to do stuff

The big difference which is glaringly obvious now, but I had not seen before is the help system and understanding something I could do that was useful.

I came to this conclusion from the other end of the stick by trying to see where I was falling down and why I could not dash a script off when I needed to do something. I knew that if I was to use it to achieve the programming goals I needed to use it frequently to be able to progress onto larger programs that I have in mind.

It came to the fact that I could not remember things sometimes. I related this to my Vi experience and realised that I had had the same sort of problem but that had not stopped me from using it everyday. The difference was that it was so hard to get help from the help system. In fact I had been using the web for quick howtos and stuff had made it harder as it was a second hand help system in a way, it was not from the guts if you like.

I was walking around the office talking to myself and gesticulating a pieces of paper and trying to see how I could get the kind of help from Perl than I did from :h in Vi.

Of course its perldoc and man perlmodlib. I had played around with it but at no point had any book walked me through the way to use it. I sort of bumbled through and got by the best I could by using books and search engines. While learning any program like vi, emacs or Open Office the help files are there and most are accessible from a help menu or command. Books are bought and read and understood and exercises accomplished. When I forget something I can look it up in the help files, I do it without thinking. So once you learn one program and read some books, you know that there will be a help system to hold your hand when you need it. The book is part of the help system in a way but it is never implied it is just there and assumed that it will be used.

Switching to learning a programming language the same is not true there is not a system called help. In Java there are loads of documentation and tons of libraries of classes to wade through. In Perl there is perdoc. These two are alluded to but not really explained. You get instructions like 'There are thousands of libraries to get to do all the things you want to do without writing code' or 'There is always perldoc to help you out and thousands of modules'. Similar direction are found in program books referring to the help system, but everyone knows about help systems its there in the culture of using a program.

Once I looked at the similarities and differences in learning programming and learning a program and treated them the same it dawned on me that you all out there must be able to find stuff in perldoc that I am missing. So I knew I had to find a way to get what I wanted to know out of the Perl Help System. I looked on the net and looked in books for the bit that I was missing. I got to perldoc but it did not tell me everything. I askerd on IRC where was the list of stuff on Perl that is on the perldoc website and I got the answer. Perldoc perl or perldoc perltoc. WHY IS IT NOT THE FIRST CHAPTER IN ANY PROGRAMMING BOOK OR ON THE FIRST PAGE OF A WEBSITE THAT EXPLAINS HOW TO FIND OUT WHAT YOU WANT TO KNOW? I found it but it has taken me ages to find it. I new it was there but did not know how to access it. If there are books out there that do explain this then I am sorry that I have not read it or perhaps I missed that chapter.

'man perlmodlib' to see what the core modules are

'perldoc -f insert-function-name'

'perldoc perl' for a summary list of functions, other perldoc pages and loads of other stuff. Decide what you want to look up and type perldoc perlref for stuff on perl references - easy huh

'perldoc perltoc' for a an in depth look at everything in Perl

This is the entrance to Perl, not the back door to be found behind the scullery maid under an aardvark when every other avenue has been exhausted

Given this revelation on how to find what I wanted to find I took up the editor of choice and started a very simple script. when I got to something that did not compile and I could not figure out why it wouldn't, I could, with confidence go to the 'help system' and find the right syntax etc.

It then smacked me in the face, I may be wrong but there does not seem to be the same thing in any other system, it may be close but not the same. So why wasn't the 'perldoc how to program like you a have never programmed before even if you have never programmed' message out there. A healthy language needs new recruits and helping them find what and how they can achieve what they want to do is paramount in keeping those new recruits and keeping the language alive. Maybe it is presumed that programmers who are familiar with such things will always read programming books/articles/blogs. Well nobody is born with innate knowledge of a system, they have to learn it and the first thing is to learn how to get help. To a complete novice it is the most important thing to be able to help themselves to help themselves.

Perldoc is not documentation, yes I know they are documents, it is the help system, and it is there on your machine tailored to the version installed on your machine. It is easy to access anywhere where there is Perl installed - your friend in a box. How cool is that?

Wednesday January 27, 2010
07:46 PM

Don't let the language dictate your thought processes

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.

For a long time I have been trying to understand why I find it difficult to think in Perl or indeed any other language. It all seems so easy when following a tutorial but when I have a problem to solve there did not seem to be any way of starting. I do regular problem solving every day so it is not a strange concept. I can intellectually understand the starting point and what it required and indeed the steps in between. However putting that into practice has prove more elusive than I first would have thought.

In designing graphics, logos, pictures and stuff I use the shapes as ways of communicating an idea. Someone gives me an outcome they want to achieve and a load of things that vaguely have something to do with it. I ask questions or not and then process the information giving them a graphical representation of the thing they said they wanted to achieve. I have techniques and mental patterns that let me get those odd scribblings or random conversations that people give me to produce something coherent.

In programming I do the same thing but in information not shapes. The bits of information to me internally have shapes and so I have tried to use the same techniques that I have always used for producing designs. I have struggle to understand why that was not working. The processes all seemed the same but when I came to write the code after making my plan I was always left with the question 'Now what do Ido? An the answer never seemed to come.

I have accepted up until now that perhaps I just did not have it in me and just to carry on do the odd script and a bit of cut and pasting there. I also accepted the perceived wisdom of the conventions used and best programming practices and all that. When trying to ask for help I have not been able to ask the right question to get the help. Everyone has been as helpful as they can. The most popular answers to my question 'Why don't I get it?' are 'Some people just do and others don't', 'Don't know what you're talking about' and 'I don't know it just happens'. Not a great start.

I have followed the tutorials and bought and read books by the ton. I have understood them to a certain degree and been able to use what I have learned to do what I have needed to do, but it has been a struggle. I am not averse to hard mental gymnastics however the whole thing is not intuitive for me. So my frustration was knowing that I deal with similar problems and come up with the goods in graphic design and that the mental processes are similar.

In the explanations and examples that I followed I could see how they got to where they wanted to be but I was unable to allegorically use that pattern to solve another problem. I was being shown one way to do it which is the natural way for that person or is the perceived best convention. There are of course more than one way to do it but I was only being shown one or at least I was not familiar enough to know how to find all the different ways and so I had this seemingly mad idea that I had to fit the whole of Perl into my head before I could do anything. Which of course is madness. Its not the way I approached using computers to do graphic design, I did not understand everything about the programs and processes before I was able to give a printer an eps file which separated the tints out for 2 colour printing that would appear that it was done in 7 colours.

So how had I got the wrong end of the stick? After I had decided what my program needed to do and mapped it out and then said 'So now what do I do?' I had not been able to get any further, I could not see the next step because I was trying to write Perl in the way that the tutorials and books ahd told me but it is not the way that I can write Perl. On of the reasons using Perl was because I had read at length that it was flexible and there was a myriad of ways to do the same thing. Ah yes unless it seemed you did not think like the people who wrote the tutorials (not a criticism) or that you had not come up through the same paths, which include neural ones too.

Graphically (image manipulation) my tools are the programs which I had transposed wrongly to be editors in programming (inli> manipulation). This may be correct if I was using a gui development environment but that only allows me to do the things that the program allows me to do not the programming language. Its the tools within the programming language that I needed to be comfortable with, than I would be able to think of a goal and then (as I do in graphics) be able to make that possible with the manipulations of the data. Intellectually of course there is no different but the methods are less so.

Today I traced the exact process by which I design things both on a drawing board and in a computer environment. I then applied this to the way I have been trying to do the same sort of process in a programming language. I came up with the following plan.

  1. Decide what I want to do
  2. What is the first step?
  3. How many different ways can I do first step in Perl
  4. Make a quest to find out all the different ways of doing that first thing which could be for instance getting the inforrmation out of a file.
  5. Make a choice as to which ones suit me and eventually I will be able to choose the one that is for other reasons too but lets not get ahead of myself
  6. Apply that method
  7. Carry on to next step and repeat the process

So I will start with a simple goal and then go questing, which will give me the broad spectrum of the different ways things can be done to acheive that same goal which in turn allows the language to adapt to my neural pathways. By cracking this nut all the others will be easier and I will not have to get the whole of Perl in my head. What a relief.

By doing this I will discover all the TMTOWTDI ness that Perl really has and will then understand enough to make my own path through the language to get to the desired outcome. The important thing is that it is my own way, everyone sees the world in a different way and has got to the position that they are now via many different routes and if the way that you are shown something does not fit into that way of thinking then all the book reading in the world will not cure it. Reading the source code as I have been doing has helped me to understand this.

It may seem blindingly obvious to you but it is not. What I had been doing is trying to make my mind think like Perl or at least he tutorials and not making Perl think like me. I had to learn not to let the language dictate my thought process because Perl can't think but I can. By discovering all the different ways Perl does things I will have a matrix to find my way to the outcome in a way that follows the way I think.

To the people who could not give me the answer to the question I did not know how to ask I apologise, you could not have understood the question because you have probably not had to ask a similar one yourself or if you did you would not have asked it from where I am. I could tell that from the perplexed expressions on your faces. Yes I can see your expression when you type.

It is probably just as well to note that the methods by which information is found is as important as the information that is provided, if there is not a track to it you can't visit.

I chose Perl because it promised that there was more than one way to do it. I took this to apply to every aspect and that it would allow me to do it my way which I will now test. I then got bogged down in doing what convention said because I was learning and thought that it new better but of course it doesn't do it better otherwise we would not improve things or find different ways to do things or find new things to do with the things we already have. I am aware of other considerations like efficiency and refactoring and endless boring list but make the programming language suit you, and if it won't let you do that, ditch it.

Thursday September 03, 2009
05:59 PM

The People

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.

When I was looking for a language to focus on for use in my work as a graphic designer and web designer and all round cheese and custard cream devotee, I remember looking for a group near to me who were active as I wanted to meet people to get a grip of whatever was going on. Having being part of Malvern LUG for many years I presumed that there must be eqiulvelant things for other languages.
I had started programming in Java years earlier before I learned HTML, so I had a look around for JUGS which are far and few between.
My search for PHP groups did not really give me anything to shout about as they did not seem to be doing alot, however while looking I came across Perl Mongers. This exotic sounding name with a hint of the arabic (camels), could it be the language for me? More importantly would there be a group near me? Luckily the Birmingham Perl Mongers were close by and I decided to take a trip. I had heard things about the black art of regex's and line noise but had never really given it a go. The group turned out to very active with an emphasis on technical talks which was ideal as I started to learn the basics.

I got a great deal out of the meetings even though they were often beyond my experience, I understood them and they gave me reason to persevere. However my first YAPC, which just happened to be hosted in Birmigham that year was my first introduction to the community at large. As I lived fairly close to the venue I only went during the day but did not socialise during the evening. The talks were really good and I could not believe that I was getting all this for less than a good night out for four, when some of the Java conferences were just out of my reach financially. Not only that I was meeting the top programmers in the country/world.

I had a great time in Birmingham and I carried on using Perl for doing simple scripts. I actually managed to write some that were chargeable - always a good thing in a hurrican with the mast just broken and the safest port miles away across the horizon.
The big change came the next year in Vienna. What I had not realised was that when you ate, drank and slept at a YAPC (not literally, although its never ruled out as there is more than one way to do it), you realised how great the people were, how passionate they were about the language all the time, not just in the lectures. Most of all people at YAPC's had a great time.

It is no underestimation that YAPC::VIENNA changed my life. Suddenly it was not about the language it was about the people.
We had a brilliant time getting up to all those noble things that you do when you are away in a foreign country on your own - staying up to watch the sunrise, going to wild nightclubs and watching people getting very drunk. The people were fantastic, informative, erudite, witty, enthusiastic, genuinely interested in what you were doing or trying to do and had a love of the bizarre. Because of the people I met in Vienna I started hanging out on IRC and got to know people from Milton Keynes Perl Mongers and London Perl Mongers, I felt I belonged and that I was valued. I work alone most of the time but now it was like having an office full of mates to have a chat to or to ask stupid questions of or just annoy when I felt like it.

There are other reasons why Perl changed my life in Vienna but those are between me and my camel.

Due to a few odd turns I sort of dropped Perl for a while as I was doing lots of graphicy designery stuff. I even dropped out of IRC life. However I had been playing with Java after a long boute in a dark tunnel which turned out to be a cul-de-sac and suddenly found myself on again. What I had missed was the connectin with people and the reassurance that there were people out there who could help me if I asked. It is the people that brought me back to Perl not the syntax or the this or the that or the other, its the people. Although the economy of code needed to just get a simple script running compared to other well known brands is a good enough reason to use it.
I can accept that it can be hard to learn sometimes when you get a little deeper or that there appears to be no logic of how it all fits together or that is uncool or because it is cool or because my mother never used it or because its a Thursday, because I know that eventually, with help from the the people, I have the best chance of acheiving the things I am going to acheive by using Perl as my programming language of choice.

Its people who do the work, find the answers, solve the problems and get stuff done not the language. Although if it is half decent it helps.

If you have never got on or been to a Perl Mongers meeting or been to a YAPC, where have you been? It does not matter what language you use, go to a YAPC and you will have a great time, make life long friends and you may even learn something.

Saturday August 29, 2009
06:56 PM

Reading Source Code

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.

I have read numerous books, in fact I have more Perl books than on any other single subject onmy shelves, but they do not always help. There is an assumed knowledge which is often expected and not always explained. It was reading Eric Steven Raymond's article on hacker culture where he said that reading and writing code was more useful than going on courses or reading books, that prompted me to read the modules in the first place. The most gratifying thing was that I did understand most of it and because I was reading modules that I have a little knowledge of and what they do I could make the connection between the code and the end result.

I have found Perl very confusing at times because there are so many ways of doing things (I know this is also one of its strengths) and so faced with such an array of different ways, I have often opted to not do them just because there seemed to be no road map. Now that I am starting to 'get' a few things I see the deep pleasure of understanding how it all works and how, by that understanding I can use Perl to solve programming problems. My main gripe is that it took a lot of effort to get to that point. Whether that is because I have had to find a particular way of learning Perl for me, or whether that is a general problem in the methods of teaching Perl, I don't know but I am going to explore that as I go through the process and hopefully be able to lay down some pointers for others who may have a similar problem.

So if there is anyone out there struggling with getting started, have a go at reading some source code, it puts a lot of the programming techniques into perspective and gives you a starting point to research the things you are reading. Being code that is in production and not just in a book which can only give examples because of the limited space and worth in that format, means that it is easier to see the point of the structure that you are presented with. Relevance to the real world is very important in understanding.