Learning styles

Research suggests that learning styles differ significantly between individuals. Some learn best through verbal presentation of information, others through visual. Some learn best by 'doing', others by theory. There's an interesting self assessment questionaire intended for engineering disciplines here, which (subject to the usual reservations about psychometric tests) might be useful for identifying your own learning characteristics.

For my part, I'm a strongly 'global' learner. I find it difficult to learn things for the sake of it (at a micro level - as long as I can see a use or application for it, there's nothing I like better than learning something new - 14 years as a part time student attests to that). This has made learning programming difficult. Working through a tutorial, writing 'hello world' code, largely copying the 'CD database' example bores the hell out of me, but it's necessary to understand the basics before going on to do something useful.

What's this got to do with Perl?

This is where Perl has made the difference. If I hadn't been introduced to Perl, I don't think I would ever have learned to write code. The combination of simple scripting facilities with full blown application development facilities meant that I was able to get straight on and do things (badly, but they worked), and gradually learn the basics whilst doing useful things. Then, as time went on, because I understood the basics of the language, I was gradually able to progress to writing more formally structured applications using 'strict' and 'warnings', encapsulating my variables in the narrowest possible scope, generalising reusable code and so on, without having to start at the beginning and learn a whole new set of basics.

As time has gone on, this has extended way beyond just Perl. Six years ago (before I started writing code, beyond a few limited attempts to learn C over the preceeding decade, and BASIC in school) I was taught the basics of UML by a developer colleague. While I was fascinated by the idea of OO in general, and class hierarchies in particular, I couldn't really see how to apply the concepts beyond analysis (and I used class diagrams and use cases for business process analysis for years without writing any OO code at all). Once I started to really get the hang of writing imperative code, I experimented a little with semi OO code that didn't use inheritance. Then a couple of years ago, someone here showed me how to implement inheritance in Perl, which saved a couple of hundred lines of code that would otherwise have been duplicated. That marked a step shift for me, and from then on I was able to do something useful with each new OO concept I learned.

Then came java.

I'd written odd bits of java before, mostly cargo-culting the structure and twiddling until I got what I wanted. Earlier this year I decided I was damn well going to learn java properly. I knew some of the basic syntax, but had always struggled to get my head around the structure, in particular why it wasn't possible to call a non-static method from a static method (and since main() has to be static, that always seemed to present an insuperable problem). I bought a very noddy introduction to java book (this one - for a really basic intro to java I found it pretty good) and that cracked it. Of course you're going to have to instantiate a class to be able to call an object method! I hadn't realised that 'static method'=='class method'. Concepts that I'd learned in Perl carried straight over. As a result, yesterday I started to use the first java application that I'd written from scratch, and also successfully wrote my first junit test case.

Test case you say?

Test case. Yes, I know I got it backwards, and I should have written the tests first, but this was an exercise in learning the language, not following good development procedure. The point is, as a result of hanging around here, I started to engage with the Perl community. As well as learning a lot of interesting and useful programming concepts (and having a lot of fun), that exposed me to the emphasis that the Perl community puts on testing. I've detailed elsewhere how that has made a difference to how I work lately, but more importantly I've learned in Perl the importance of unit testing, and how to go about it. That knowledge carries over easily into other languages.

Learning from the community

I stumbled in here more or less by accident, and got involved in the community that way. I can't begin to describe how much difference that made to my rate of, and opportunities for, learning.

Five years ago I had no idea what a version control system was. Four years ago I had, but it was limited to Visual Sourcesafe, and I didn't really like it very much. Now I run Subversion locally, and store all my code (and increasingly everything else I do) in it. Testing, version control, code reuse, the list of programming rather than specifically Perl related things I've learned from the Perl community goes on and on. Not being a career programmer, I probably would never have bought 'The Pragmatic Programmer' if it weren't for adrianh's enthusiastic recommendation at YAPC::EU this year, and I've learned a lot from that too.

So what's your point?

Several points spring to mind:

• Different people learn in different ways, and Perl has advantages as a learning language for the 'active' learner.

That's not to say that Perl is an ideal teaching language. Various people have said in the past that Perl has disadvantages for teaching - TIMTOWTDI and the lack of a strong typing system being two. I make no comment either way - I don't know. But for someone 'learning by doing', especially in the early stages, both of these are IMO definitely advantages, not disadvantages.

• Many advantages lie in the community as well as in the structure of the language.

Many things that can't be learned as you go along if you learn in isolation can be learned from the community. Testing, design, development methodologies, version control are all promoted. The trick is finding out that the community is there to be learned from at all.

• Many programming concepts carry over from one language into another

OK, that's old news. But the relatively free form nature of Perl makes it IMO easy to learn those concepts in Perl, especially when trying them out. When I came across AOP, it was in a java based tutorial. My immediate reaction was to download Aspect and try it out in a short POC Perl script, because it's quicker and easier than trying to do the same in java. The same is true of just about every other new concept I've come across (dispatch tables is one that comes to mind).

• Sometimes the docs just don't make sense at your current level of learning

A few months ago I made one of my periodic assaults on perlguts. To my surprise, it wasn't completely opaque any more. Granted, I still don't understand much of it, but I got the gist of some. Part of that is down to things I've learned here, part to things I learned from theDamians 'Object Oriented Perl'. Every new thing you learn helps to make sense of the next thing waiting to be learned.

Ultimately my point is that a) learning styles vary, and b) there are many things about Perl which make it ideal for learning as you go along. Many formal teaching structures don't take account of a), but thankfully, b) remains as an alternative.