Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

On differing learning styles, and learning programming through perl

by g0n (Priest)
on Dec 07, 2006 at 17:43 UTC ( #588411=perlmeditation: print w/replies, xml ) Need Help??

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.


"If there is such a phenomenon as absolute evil, it consists in treating another human being as a thing."
John Brunner, "The Shockwave Rider".

  • Comment on On differing learning styles, and learning programming through perl

Replies are listed 'Best First'.
Re: On differing learning styles, and learning programming through perl
by ptum (Priest) on Dec 07, 2006 at 21:35 UTC
    Perl has advantages as a learning language for the 'active' learner.

    This really resonated with me. I'm a programmer by trade, and have developed in at least 8 or 9 different languages over the years with varying degrees of success. I have found Perl to be the best language yet in which to quickly get something done ... for the 'active' learner, as g0n says, this utility of a language is essential. I've been taking some C++ courses lately, and it is amazing how much longer it takes me to do simple things ... I'm convinced it is not entirely because I am such an inept C++ developer. I think that Perl is well-suited to the temperament that views learning as a necessity to getting work done, not to contrast the 'active' learner unfairly with the kind of person who sees learning as an end in itself.

Re: On differing learning styles, and learning programming through perl
by jhourcle (Prior) on Dec 08, 2006 at 15:46 UTC

    I think that some of the issues that you're seeing aren't necessarily related to 'learning style', per se, but in that you don't have the necessary context to make sense of the information that's being presented.

    For instance, to learn a complex concept, you typically need to have at least a peripheral understanding of the basic concepts from which it is derived. At the very least, you need to understand the language in which the instructions are being given. Does it do us any good to go to a lecture about 'associative arrays' or 'tuples', when we've only heard the term 'hash' used to describe the concept (okay, they're not exactly the same thing, but that's part of the problem with terminology).

    The even bigger problem is when different communities have the same terms (words), but they have describe different context -- telling someone to 'go into the other room and strip' has absolutely nothing to do with removing clothing if you're in the printing industry. (the example comes from Axley's 1984 article, "Blow up the communications pipeline", which discusses problems with people thinking they understand the message, but actually didn't). Even Heinlein touched on the issue of language in learning in 1961, in Stranger in a Strange Land -- teleportation made perfect sense to Mike, but he had to teach people the Martian language because the terms just didn't translate into English -- once they knew Martian, the concept was easy.

    Trying to place knowledge into documentation is a particularly difficult process, as you have to write for the person who is going to be reading the documentation -- if you have disparate groups of readers, it's sometimes more efficient to write two or more seperate sets of documentation, if it's for a system that's not going to be changing much. (if it is going to be changing, then you have to maintain all the docs, so it may be easier to maintain modular documentation, some of which are just to set the necessary context to understand the other parts):

    I think your points are valid, and I'd also like to add

    1. It's difficult to learn a completely novel concept; you must build upon concepts you already know.
    2. You must write documentation and training materials with an understanding of the intended audience, and avoid (or define) jargon or concepts that they may not be expected to know.
      Good points, one and all. I would add that:
      • e. At the point in time when one can clearly state, either verbally or in writing, what one has done, one has reached a basic understanding of what one has done.
        • Having recently assisted my wife with her masters program in mathematics education made this point very clear to me.

          Also, getting to know a language of any kind is a never ending process, the damn things change! And I for one am a strong believer in differnt learning styles. Finding one that works for me is probably the toughest task I have ever taken on.

          ...the majority is always wrong, and always the last to know about it...

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://588411]
Approved by BrowserUk
Front-paged by NovMonk
[talexb]: Great quote from Re: (OT) Motivating the Unmotivated Programmer: "As Weinberg suggests, when a programmer becomes irreplaceable, it's time to replace him."
[jedikaiti]: SuicideJunkie++ #Apgrade is the highest point it will reach. They're informing you that it will all be downhill from here until the software hits a PEgrade, or impacts the terrain depending on the details of the orbit.

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (9)
As of 2017-07-25 18:49 GMT
Find Nodes?
    Voting Booth?
    I came, I saw, I ...

    Results (377 votes). Check out past polls.