Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

How do you master Perl?

by brian_d_foy (Abbot)
on Apr 11, 2005 at 10:40 UTC ( #446556=perlmeditation: print w/ replies, xml ) Need Help??

I've thinking about what's beyond the basics of Perl, and here's where everyone gets to expand my thinking and provide a reality check. What comes next? What's the "upgrade path"? Do we keep teaching them more facts about Perl until they know all of the documentation? Teach them to use the modules they need to use to get their particular job done? Or is it something else?

I just finished working on the fourth edition of Learning Perl, which should be out towards the end of summer. (I don't have details on anything yet, but I'm working with the O'Reilly marketing people to get all that stuff. And yes, Randal and Tom worked on it: I was just renamed "Dances with Wolves and Editors" ;) Teaching beginners is easy because we know where to start and everyone is pretty much in the same place. A lot of people are content to stay at that level, and that might be okay for them. What catapults people into the higher levels, though?

Besides specialized topics like CGI, LWP, Testing (chromatic and Ian Langworth are quickly approaching a completed manuscript that looks really, really good), there isn't a long vertical path, or even a contiguous one. People's interest diverge. At Stonehenge, after we teach the intermediate Alpaca course, it's either a buffet of shorter classes on specific topics or custom-designed courseware. It's also a captive, targeted audience. What about the Perl world at large? If we can't group them into a particular class because that's the class they signed up for, what do we pick out of all the things that exist as the important things to teach or write about?

Beyond Learning Perl, which we designed to cover the 80% of Perl that most people will need to know to write basic programs, there is Learning Perl References, Objects, & Modules (which we are now updating), Simon Cozen's soon-to-be-released update to Advanced Perl Programming (which is a very cool book, having just read the pre-galleys), Mark Jason Dominus's Higher-Order Perl (which he talks about in my interview with him), and Damian's upcoming Perl Best Practices (which I'm now reading in pre-proofs). There are a few other general subject books too, so my apologies to those I've neglected. I've read too many books this week. Most of these, however, focus on something to do with the Perl language (surprise!)

The more I think about this, the more I'm convincing myself (for good or ill), that the things programmers need to learn next aren't so much about Perl as things they should know how to implement in Perl, but could also do in some other language. Surely I can teach more and more Perl stuff, but at some point the student who really wants to learn more needs to have a "programming lifestyle" that supports it.

I've jotted down a couple of these lifestyle issues. They aren't revolutionary or new, and I don't have complete discussions on them. When I started this, I wanted to write the complement of How not to code, but I really think mastering Perl (or any language) goes beyond the stuff that other people can tell you: you need to do things yourself.

You need a safety net

Most of us know we should use source control and write tests, but I'm starting to think that to teach advanced concepts, people need a base camp to start their exploration. If you mess things up, you haven't completely horked your production system or corrupted your operating system. What else does the safety net comprise?

Be bold

Once you have the safety net, just try things. You shouldn't have to ask questions like "What happens if I do this?" because you do it and find out. An expert is someone who has made every mistake, so you have to start making more mistakes. Or, in a foodie analogy, I heard an interview with a food writer who said "If you aren't getting food poisoning, your not being adventurous enough". To experience the really good things, sometimes you have to be bold and take risks. Maybe you get burned a couple times, but the times you don't are worth it.

You have to know more

A lot of advanced stuff is just knowing more, and that usually means knowing things that aren't immediately useful. You can't wait until you need something to learn it if you want to do fancy things since fancy things tend to be the cobbling together of many things.

I think one of the greatest enemies of this part is "Search". When you can jump right to the part you want, you often miss a lot of unrelated but interesting things that surround it. You don't get the opportunity to subconsciously remember stuff. I have a love-hate relationship with online dictionaries because I miss running my finger down a column of words and learning a word or definition I didn't intend to learn.

As part of this, I recommend to my beginner Perl students that they read all of perlvar and perlfunc, although I stress they don't have to try to remember any of it. Some day in the future, they may remember that there is a function called gethostbyname (or kill, or whatever). They may not remember exactly what it was or how it worked, but they should recall that Perl has a lot of built-ins that deal with socket stuff.

Learn other languages

In a Perl class or book, I'm not going to teach Lisp. MJD talks about Lisp in Higher-Order Perl, but not enough to distract from the Perl. Still, the book is all about using ideas from functional programming. In a recent thread, Randal talked about a particular Smalltalk book.

Other languages give you perspective on the one that you want to use. You might hate Java, or C++, or something else, but the honest programmer has to admit that smart people developed those things and had at least a couple of good ideas. Even the bad ideas simply make you appreciate your language of choice that much better.

Once you know other languages, even if you only can read them (rather than create useful things in them), you can read other books on programming to learn high-level skills and techniques which you can then apply to Perl.

Knowing that, do we really need a "Do Bar in Foo" book for every combination of task and language? You cut yourself off from mastering your favorite language if you don't pay attention to the good ideas and idioms in other languages.

Learn how to answer your own questions

The best part of my college education were the classes where the professors wouldn't answer questions. It's not that they didn't want us to ask questions: they were training us to be able to answer questions on our own. Every upper level chemistry class I had in my undergraduate days had a tough library assignment that came with no instructions other than "the answer is in the library". A couple classes were merely "this instrument needs to be rewired, and here's a bottle of mercury to build the barometer you'll need. It's due next week. Good luck." To be certain, it sucked, but after a while, I knew how to find information and answer my own questions. I didn't even have Google then.

Or do you just ask questions as Anonymous Monk? :)

Reinvent the wheel

In Advanced Perl Programming, Second Edition, Simon talks about the "rites of passage". Those are the things that the intermediate programmer has to go through to pass onto the ranks of advanced programmer, and they are all about re-writing something that is usually already done much better elsewhere: templating engine, command line argument parser, and so on.

There's some inflection point in the learning path where all that good advice we give to beginners is bad advice. Stuff like "use a module" and "just use a regex" get in the way of "kata", where the intermediate programmer needs a topic against which he tries new techniques and approaches.

Back in the day when I was answering a lot of questions on comp.lang.perl.misc, instead of giving just one code sample, I'd give several. I tried to get each answer to do the job with a different feature. One might use a regex while another one uses index().

Not only that, but it's in re-inventing something that you discover just how difficult the problem is, and you appreciate design decisions and limitations in what already exists. It's almost like you have to bang your head against the wall or touch the hot frying pan to learn that those things hurt. It's empirical learning: there is no knowledge without experience.

You don't have to use the re-invented thing in production, though. :)

What other good beginner advice is bad intermediate advice?


Okay, I'm stopping there because it's 5:30 am and I'm starting to babble. My mind is mush and open to the wisdom and experience everyone else has to offer on what you need to do to master Perl. :)

--
brian d foy <brian.d.foy@gmail.com>

Comment on How do you master Perl?
Re: How do you master Perl?
by spurperl (Priest) on Apr 11, 2005 at 11:47 UTC
    About the safety net...

    You raise the topics of source control and tests. Both are safety nets, but they are from different worlds.

    Tests is a coding safety net. Its cousin is designing code for testability / debuggability, using assertions (even contracts are here but this is way too much for beginners).

    Source control is coding tools safety net. Its relative is keeping track of bugs/features, for example.

    Also, I'm not sure that learning other languages is the best advice for beginners. For once, most Perl beginners probably come from other languages, either from work/self study or from University. Learning other languages (the well known one of each of the 4 paradigms) can be left for later, intermediate stages.

      Tests is a coding safety net. Its cousin is designing code for testability / debuggability, using assertions (even contracts are here but this is way too much for beginners).

      Source control is coding tools safety net. Its relative is keeping track of bugs/features, for example.

      Depends on how you look at them. I see testing and source control gain extra utility when you look at them together. Tests demonstrate bugs and features. Source control track them over time.

      For example if you're doing TDD you're writing a failing test before each bug fix or feature. If you do a commit each time your code goes from a failing test to a passing test then you will track each new feature / bug fix as it is completed.

Re: How do you master Perl?
by cog (Parson) on Apr 11, 2005 at 11:52 UTC
    What other good beginner advice is bad intermediate advice?

    I don't think that a good beginner advice has to be bad intermediate advice.

    One of my advices when it comes to Perl is to join the comunity. It's one of the greatest I've ever seen.

    From time to time I find a Perl programmer who doesn't know about the comunity nor about other Perl monks or even Perl books. Not rarely, that person considers him/herself a hot-shot!

    It's in learning more and more that you realize how much more there is still to learn.

    It's by staying confined in your small room, doing the same thing over and over again, that you convince yourself that there's nothing else to learn. And this is just wrong.

    So my two advices at the moment are: Join the comunity and see what it has to offer and Try doing new things and explore new areas, don't be confined to the same thing over and over again (or otherwise, you'll get to the point where you say "I have three years or Perl", but you really have three months... repeated endlessly).

      Join a community: excellent. I actually give this advice to everyone (having founded Perl Mongers, it's not that surprising :)

      Being around other people expands your world, but also gives you a chance to see how other people think. Certainly we can all read what people write, but we often leave out a lot of ourselves in that and stick to the topic. Knowing other people who are doing the same thing lets us connect their taste in movies, beer, and Perl idioms. :) We're also forced to hear about the things they're thinking about, which isn't usually the same things we're thinking about.

      I've noticed that strange dialects of Perl spring up in isolated Perl programmers. It's sort of like divergent evolution. They turn into a new species of Perl programmer. I also remember this really smart kid from high school who never talked to the other kids and mispronounced a lot of things because he only ever read those particular words. Being around other people re-inforces and refines what we already know, but it also pushes us back toward the mainstream so we don't develop into the Perl program who uses Parse::RecDescent for absolutely every program (I have met a couple like that, beleive it or not :)

      --
      brian d foy <brian@stonehenge.com>
Re: How do you master Perl?
by dragonchild (Archbishop) on Apr 11, 2005 at 12:56 UTC
    A few thoughts, in no particular order.

    The more I think about this, the more I'm convincing myself (for good or ill), that the things programmers need to learn next aren't so much about Perl as things they should know how to implement in Perl, but could also do in some other language. Surely I can teach more and more Perl stuff, but at some point the student who really wants to learn more needs to have a "programming lifestyle" that supports it.

    To me, this is the heart of it. I first learned Perl in 1995, and thought it was a heck of lot better than C or Pascal, but it was just a year-off from college, so I didn't do much with it. In 1999, I started working seriously with Perl and, after reading the Camel 3rd a few times, realized that I already knew all the language stuff, but didn't know the programming stuff (despite have a CS degree). I was lucky enough to be directed here, where I have happily undergone a 4+ year apprenticeship to some great people.

    Teaching beginners is easy because we know where to start and everyone is pretty much in the same place. A lot of people are content to stay at that level, and that might be okay for them. What catapults people into the higher levels, though?

    This is also very important. Most people who write stuff in Perl do so because they're not programmers, don't want to be programmers, and know just enough to get done what they need to get done. They don't need to know how to do more. At best, a quick tour of CPAN is all they need to be more productive.

    You can also look at Saints in our Book and catalog what they thought they'd be when they grew up. I'll bet you less than 20% thought they would actually be real-life computer programmers. Yeah, there's the people like me who wanted to be a programmer ever since they first played around with AppleBasic or CP/M or whatever. But, most just fell into it because some random job accidentally asked them to go beyond what they thought they could do. How many times do we get the question that goes something like "I can write cronjobs, but now I'm being asked to write mission-control software. Help!"

    As for your safety net ... every dangerous task has its own safety net. I think that instead of trying to build Safe for mid-level developers, you should instead look at trying to develop habits. I programmed for 5 years before I even knew that you could have automated tests for software. It was something missing from my foundation. Now that I know about them, I (try to) follow the XP guideline of "write test, fail test, write code, pass test." It's just a more sanitary way to live, but you don't know that until you've seen it.

    For your "Do Foo in Bar" thing ... we're actually have this discussion on the extreme-perl mailing list. (Well, Rob Nagler and Ovid are having the discussion while the rest of us are making sure no blood spills on the carpet.) I tend to agree with Rob, though not as vehemently. He feels that Perl has all the tools he has ever needed for the projects he's run into, and I agree with that. The big eye-openers for me have been when I learned to program thinking of

    • lists instead of items (map/grep/sort vs. for/while)
    • functions as first-class items (dispatch tables, closures, etc)
    • objects as both instances of classes and entities in their own right (classic OO vs. prototyped OO)

    I'm certain a few others can be described, as well. If you teach those, in Perl, then you're well on your way to giving your students many of the benefits of other languages. This isn't a substitute for learning Haskell or Smalltalk, but it's a good start.

      For your "Do Foo in Bar" thing ... we're actually have this discussion on the extreme-perl mailing list. (Well, Rob Nagler and Ovid are having the discussion while the rest of us are making sure no blood spills on the carpet.) I tend to agree with Rob, though not as vehemently.

      I think it's interesting to note that no one on that mailing list who argues that you can "learn all that stuff in Perl" has any experience with languages in paradigms other than procedural or OO. Do they know any functional languages? No. Logical? No. Heck, not one of them even knows a pure OO language (or, at least all have been silent when I have repeatedly asked).

      It reminds me of a kid in an English class who told our professor that he (the kid) doesn't need to visit any foreign countries because he has the Internet. Once someone is that far gone in their misunderstanding, it's often difficult to explain what they're missing. Let's call that kid Alex. Imagine that Alex smokes Gauloise, reads about France on the Internet, and recites from memory the dialogue to every Eric Rohmer film while wearing a beret. That still doesn't mean he understands what it is to be French or to experience French culture first-hand. However, never having even visited France, Alex would have no way of knowing what he's missing. Further, having never been to France, many of us would rightfully mistrust him as an expert on French culture, particularly if he is disagreeing with someone who has lived there.

      Sure, you can learn functional programming techniques in Perl, but it's a piece of cake (and natural) to fall back to procedural or OO techniques. If you are forced to work in a purely functional or logical language for a period of time and you have no comfortable techniques to fall back on, you can gain a better appreciation of those other points of view. However, Rob Nagler and friends have never directly experienced those other cultures. I hardly feel they're well-placed to judge Perl's merits vis-a-vis languages they do not know.

      Mind you, this is not to say that they're not a bunch of great guys and sharp programmers. They just have a bit of a blind spot.

      Cheers,
      Ovid

      New address of my CGI Course.

        Somehow I missed this reply earlier: that's excellent advice. I deal with this situation quite a bit since I spent a long time in the Middle East and now get to listen to people tell me all about what's it like over there since they saw it on CNN. :)

        At some point, you have to stop relying on the information you got second- (or third-) hand and experience it yourself I didn't really define "master" before, but now I think I'll have to include "first-hand, direct experience".

        It also reminds me of what a physics professor said about the Dirac equation for the electron: "Schrodinger is a nice place to visit and walk around, but you have to take a picnic basket with you to visit Dirac." Some places you can visit for a couple of hours, but other places you have to set up camp and stick around for a while if you want to get anything good out of them. :)

        A big part of living in the culture deals with discovering why they do things. Almost everything, including the stupid things, has some sort of history behind it. That doesn't justify it, but it makes it understandable. Once you understand why something is the way it is, you can deal with it more effectively (including changing it if need be).

        --
        brian d foy <brian@stonehenge.com>
Re: How do you master Perl?
by naChoZ (Curate) on Apr 11, 2005 at 14:07 UTC

    It's not surprised you're thinking about this. I remember your post Re: Indicators of your Perl skill. :)

    By that measure, I'd say I'm advanced, or pretty close to it. I definitely don't muddle as much as I once did, but master is still a far cry for me.

    As for how I got to my current skill level, reinvention has been a big thing for me. I have trouble learning things that I can't visualize or somehow create a mnemonic that is personally meaningful.

    Sometimes I have to try doing something my own way in order to see why someone might do it another way. Sometimes, I blindly try to do it the way that they're doing it, without understanding what am doing. After I've tinkered with it enough, broken it enough, fixed it enough, it will finally start to gel and penetrate my often thick skull.

    Like OO, for instance. I still don't have a *totally* solid understanding of it, but what helped me make progress (aside from merlyn's fine alpaca book) was RT. I had to monkey with it a lot for work. At first it was quite mysterious how all those modules interacted with each other, which modules inherited from each other, with methods were available in which place. After a while it finally started to make sense and I could finally see how an OO model could work together, be organized, intelligent, maintainable, and useful.

    I know your question is "How do you master Perl?" but in this context, can you define master? Is a master someone who can use Perl as productively and efficiently as possible? Or is it Erudil and his ingenious posts. Or is a Perl master someone who can successfully earn a living based upon Perl. Or is it... Or is it...

    Perhaps it's not really "mastery" that we seek?

    --
    "This alcoholism thing, I think it's just clever propaganda produced by people who want you to buy more bottled water." -- pedestrianwolf

      I've never really thought about how I would define "master": I'd probably get into the same argument I do with Perl certification. ;)

      I certainly don't think there is one level of mastery. We might separate Perl programmers (or any programmers) into three rough cuts of beginner, intermediate, and advanced, but then we could go into each of those groups and cut each into three more groups.

      I think the heart of the matter, however, if that a Perl master bends Perl to his will, rather than being limited by it. Damian, king of source filters and Perl magic, makes Perl does what he wants instead of the other way around, for instance.

      Maybe the definition is just a subjective comparison, and everyone puts different labels on people. I think most people would agree that Autrijus, Randal, Damian, and Larry are masters. People can also probably pick out the beginners pretty well too. After that, fists start to fly :)

      --
      brian d foy <brian@stonehenge.com>

        After that, fists start to fly :)

        True. And your old post directly addresses that also. Number 2, Intermediate: You think you know a lot of Perl....

        ;)

        --
        "This alcoholism thing, I think it's just clever propaganda produced by people who want you to buy more bottled water." -- pedestrianwolf

Re: How do you master Perl?
by chas (Priest) on Apr 11, 2005 at 14:46 UTC
    "Reinvent the wheel"
    I'm really glad to read your comments on this. I spent a lot of time figuring out how to unencode form data, parse email headers, etc, etc and then finally used the appropriate module to achieve that. But I learned a whole lot. I'd often get accused of trying to reinvent the wheel, but my thought was always that if someone had figured out how to do those things I ought to be able to do it also...well, maybe my self confidence was more than was due, but the exercises were really instructive!
    Great post!
    chas

      When I have gotten past the basics of a particular language, I start to think about other play projects I've worked on and try to decide how to reimplement them in the new language. Things I like to try are

      • building a binary heap
      • building a simple HTTP library
      • implementing various sort algorithms
      • parsing an RSS file

      These kinds of little projects for me help me to get a gauge for what the language is like and what its strengths and weaknesses are. It also helps me to understand the gaps I currenly have in my understanding of that language.

        I know of another Steve that does the same thing. He wrote a module he called Node.pm and is now polishing up a rewrite of it in Ruby (Node.rb). I think he's rewriting UMENU in Ruby, too. That certainly strikes me as a good way to learn things in a new language: it provides a clear, simple benchmark against which to evaluate your progress.

        print substr("Just another Perl hacker", 0, -2);
        - apotheon
        CopyWrite Chad Perrin

Re: How do you master Perl?
by NateTut (Deacon) on Apr 11, 2005 at 16:05 UTC
    Maybe this should be one of the basic topics, but I see plenty of "experts" making this mistake. Write readable code! Use meaningful variable names. Yes "foo" and "bar" are cute names but they don't say much about what is going on in your code.

    Obfuscation and golfing are fun diversions, but don't write your production code that way. Use comments and spend some time on the layout of your code to make it presentable. Be proud of your work.

    My $0.02.

      Ah yes, the dear topic of the organized mind!

      I actually tend to think the people who golf and obfuscate aren't really the culprits of the everyday unreadable code.

      I really don't know how to deal with that problem, and some Perl masters don't have the greatest styles. I vaguely remember a great quote from a master programmer who said that computer program where meant to be read by humans, not computers. Was it Knuth? Does anyone know this quote?

      I think this comes back to a master controlling his environment. Randal could probably instruct me on further koans about this (and he did learn quite a number of interesting things in that part of his life). I'll have to think more about this one.

      --
      brian d foy <brian@stonehenge.com>
        I agree I think Obfuscating and Golfing are unrelated to unreadable production code. One technique I was taught early on (in another programming language) is to write the comments first. Write in the comments what you are going to do in the code. It really helps to clarify your plans and to remember what that plan was after you've struggled through the early portions

        Unreadble code often comes from unskilled coders, but not always. Some people just hate typing so much they make all their variable names 1 character. I like code that reads like poetry...

        I vaguely remember a great quote from a master programmer who said that computer program where meant to be read by humans, not computers. Was it Knuth? Does anyone know this quote?

        I have that quote on my homenode. It’s from the preface to the first edition of Structure and Interpretation of Computer Programs by Abelson, Sussman and Sussman. The exact phrasing is

        Programs must be written for people to read, and only incidentally for machines to execute.

        With regard to the topic of this thread, that book is highly recommended – and it’s available online freely, in full.

        Makeshifts last the longest.

      Obfuscation and golfing are fun diversions, but don't write your production code that way. Use comments and spend some time on the layout of your code to make it presentable. Be proud of your work.

      As a golfer, I have to point out that golfed code is production code. It's just a different kind of "production" than the one you get paid for. Same with obfuscation, even more so than golf. Layout is extremely important, especially in multi-line golfs. And, I am proud of every golf I write.

      Now, I understand what you're trying to get at. Readability is the key is code that is meant to be edited. So, you should "golf" for editability. :-)

Re: How do you master Perl?
by ysth (Canon) on Apr 11, 2005 at 16:28 UTC
    I think one of the greatest enemies of this part is "Search". When you can jump right to the part you want, you often miss a lot of unrelated but interesting things that surround it. You don't get the opportunity to subconsciously remember stuff. I have a love-hate relationship with online dictionaries because I miss running my finger down a column of words and learning a word or definition I didn't intend to learn.
    That reminds me of something somebody once said, that I've since been unable to find again. I think it was during the postmortem of one of the first golf tournaments on fwp. A golf master (who presumably did already know all this stuff) recommended working on a golf problem by reading through perlvar, perlfunc, and all the core module doc, examining each item for applicability to that one particular golf problem.
Re: How do you master Perl?
by exussum0 (Vicar) on Apr 11, 2005 at 16:40 UTC
    On re-inventing the wheel and advice, look at what most people use and understand how it works. My favourite type of thing is CGI::Application and understanding how it works and why it works as a pattern of use. It's not simply about perl and the neat-o things you can do, but workflow as well.

    Look at Log4Perl. It's not a hard program to write. It's great in that it makes programming easy. CGI.pm. You can love or hate the innards, but look at how it solves stuff on the high level.

    For every time one wants to reinvent the wheel, look at what you thought of, and what exists. The robustness between original thought and the good existing stuff is what one needs to learn. Generalizing into reusable components is where you should concentrate. Learn between too much and too little. Think outside of the original problem so the next time, you can work faster by using the general solution if applicable. The real world thing is done to death. Not a lot of new stuff is popping up. If you want to play with really novel or just hard stuff, get your PhD. Play with NP == P (Or not equal :)

    ----
    Give me strength for today.. I will not talk it away..
    Just for a moment.. It will burn through the clouds.. and shine down on me.

Re: How do you master Perl?
by samizdat (Vicar) on Apr 11, 2005 at 17:05 UTC
    Brian, you're hitting lots of nails square-on. I'd harp more on things they should know how to implement in Perl, and also HOW they are implemented. The most empowering courses I ever took (and I haven't taken a lot of pure CS) were courses that got into the implementation of things: data structures, algorithms in abstract, and the fundamentals of interpretation and compilation. I think it's critical to understand the nature of data representation and 'little language' creation and parsing.

    It's also Awfully Damned Important to know something about efficiency and the various coding tradeoffs one has to deal with in the Real World: CPU, memory, disk, network bandwidth, propagation latencies, etc., etc., etc.

    I also think Perl has benefitted greatly from Larry Wall's 'swing from the hip' mentality. I don't consider myself a Perl master by any means; in fact, by your scales I'm not even sure I'm even 'intermediate'. ;-D What I do know is that I'm a damn good programmer and I manage to succeed in solving all my tasks, and it's definitely 'hubris' that carries me through the tough spots.

    I think there's something you really need to get across to any programmer who you want to launch into the 'great' category that runs counter to what you'd tell a newbie. A newbie needs a dictionary, i.e., lots of study of perl books, lots of perldoc absorbtion, etc. Great programming comes from understanding of the gestalt of the system, the tools, and the project. (oh, hey, and don't forget users and management!) A programmer who doesn't start taking flying leaps will always be a good intermediate programmer, but he'll never become a Larry Wall or a Brian Kernighan, and it's all too easy -- especially in an academic environment -- to stress the explicit technology of coding so much that students get bogged down.

    Perhaps this is outside of the scope of your question. After all, you are asking for ideas for formulation of an 'intermediate' level course. I do think you should think about what I've said in the sense of not choking your students who are capable of going further. Then, perhaps, we can brainstorm a 'how to become a genius programmer' course with you on another thread. :D

      The "gestalt" idea is very interesting: learning about one part of the system teaches you about other parts, mostly because that other part was probably designed by the same person.

      I've been thinking about this when I use my TiVo. It's a wonderful human interface, and I've never read any instructions on how to use it. Often, I'll get to one of it's menus, and just try something because that's how it worked in some other part of the system. Often, surpriseingly, it works there too.

      I think in some contexts, people might call this "grokking" the system. You understand it at some gut level.

      Once you get one Larry's wavelength, for instance, a lot more of the design decisions make sense. Maybe that's sort of like the struggle intermediate programmers go through to have a breakthrough in understanding. For some reason, I'm now thinking of that scene in the Matrix where Neo gets up after being shot several times and realizes, despite all of his suffering through the movie, that "Hey, I am The Man!" as he flexes his deltoids and the walls in the room bulge. :)

      --
      brian d foy <brian@stonehenge.com>
        Without a doubt, grokking (as per Heinlein) is a major component of hitting home runs in programming. Certainly, that's why I included both users and management in my list of subsystems. I was actually thinking in terms of getting programmers to understand components of their 'system' (in the biggest sense) that are NOT designed by the same person. Your machine and your OS were not designed by the same person as your program, and your users even more emphatically so. The synergy that makes a TiVo or a Macintosh so intuitive comes from understanding the deeper action metaphors of human decision-making.

        I'm not saying that grokking all of these are necessary to produce great (or good) code; but I'd suggest that such an understanding is a goal to strive for on a greater level than understanding the primary programming paradigms. I personally think a good Renaissance (wo)Man programmer is far more adept and far more useful than a hundred code-wankers.

        I'd diffidently suggest that your Matrix example is an example of a breakthrough on a much lower level, where a programmer realizes his power on a level of control of an abtract machine which he thinks but is NOT the universe. It's just a movie, after all!

        Programming Gestalt is the realization that the hardware IS, the OS IS, Perl IS, users and management ARE, but one can create a glorious dance that brings them all together in a synergistic fusion that creates accomplishment of goals. More like Kwai Chang Caine in Kung Fu. :D
Use Something Different
by Ninthwave (Chaplain) on Apr 11, 2005 at 18:48 UTC

    I worked at an ISP in the states and my first real engagement in Perl was working with the perl programs we used to manage the web hosting accounts. Some people were trying to move up the chain and were writing there own programs to automate their work. I would debug their programming logic. Not knowing perl but having been schooled in programming, I could spot the bug better than they could. I ended up being one of the tech's to help fix customers problems with perl, still never coding anything myself.

    I would say the web turned me off perl intially, I liked Miva, and was hoping php would become something, but I would still use C if I needed an application on my web server. After some work with php and hating it and loving it at the same time, I met a young lady and moved to England. I got work in the IT department of a Financial Services company. It was the type of work here that made me fall in love with Perl. Now if I need something on my web page I will most likely do it in perl. If I need anything I will do it in perl. I think what helped me here was the finding flexibility in the language in areas I didn't expect it. I also think working on problems with Win32, threads, ODBC, DBI, cross platform portability issues, made me engage with the language more. I am still a neophyte, most of my programs are writen quickly and are very dirty, though I am cleaning them up more and I am starting to implement practical code reuse.

    The whole point of this ramble is for me each step up the perl ladder for me has been faced with a problem and trying to find a solution. Perl can box you into habits and safety zones. If you pop out of those habits and safety zones you might find you gain enough perspective to gain more knowledge.

    As an aside why is there a Learning Perl and a Learning Perl for Win32?

    "No matter where you go, there you are." BB
      Because Learning Perl takes a Unix slant to things. Win32 is sufficiently different that it makes sense to have both. Specifically, there are a huge number of Win32-specific modules that have little to no analogue in the Unix world.

        Learning Perl is about as non-unixy as we could make it. Any residual unixisms are from Perl itself.

        The stuff that is Windows-specific (or Mac- or Solaris-) is beyond the scope of the book.

        --
        brian d foy <brian@stonehenge.com>
      As an aside why is there a Learning Perl and a Learning Perl for Win32?
      There really shouldn't be, any more. We worked hard to eliminate the Unix-knowledge bias for the 3rd edition of the Llama. But when I suggested that this signaled the end of the Gecko book, the O'Reilly staff said "why stop printing a book that sells?".

      So, the Gecko continues to sell, but in an ideal world, it'd be gone by now.

      When we teach a "Learning Perl" class, we always use the Llama, regardless of the mix of the students between 100% Unix and 100% Windows. I don't think I've ever even ordered the Gecko for a class.

      -- Randal L. Schwartz, Perl hacker
      Be sure to read my standard disclaimer if this is a reply.

        Thank you for the hard work, it shows and I have been sending people to the Llama no matter what the platform, I can now do it with a bit more confidence that they won't be stuck.

        "No matter where you go, there you are." BB

        I refer nervous, fearful people who live in the Win world to the Gecko Book. It reassures them to see Win32 in the title. They open it with the expectation that they will have the comforts of their familiar environment. To someone who lives i a world of hierarchical menus this is a big thing.

        Be Appropriate && Follow Your Curiosity

        Hmmm. I just noticed that my copy of Learning Perl says "UNIX Programming" at the top of it. I'm guessing the unix bias was weeded out after the second edition of the book. Since I currently don't even have a Windows system of my own, though, this bothers me not one whit.

        print substr("Just another Perl hacker", 0, -2);
        - apotheon
        CopyWrite Chad Perrin

Re: How do you master Perl?
by bsb (Priest) on Apr 14, 2005 at 05:13 UTC
    I've certainly done and redone the wheels Simon mentions. I then found it instructive to compare the working of my solution with others. How does Kwiki do configuration? How does So-And-So debug his code? If they do something better then I learn, if our designs converged I get a warm glow.

    Another thing I've tried to do, but not really succeeded, is to think about the limitations of the way I use Perl. After looking at Prototyped OO I found cases where I was badly half-implementing it. Likewise with AOP.

    Then the Apocalpses came out. I read along as Larry solved the problems I couldn't even see I had (and Perl had).

    This changing of perspective has teaches me most but it's difficult to turn into a process. Therefore, it's probably difficult to teach. I just continue to bang my head against things I don't understand until one or the other cracks. Good luck finding an alternative.

    Brad

Re: How do you master Perl?
by arcnon (Monk) on Feb 12, 2006 at 19:13 UTC
    To myself a master is defined by a consensus of ones peers and the causual viewer of your work, at least in the art world and in the most part the Perl world as well. Some will never touch mastery for whatever reason... I never will. But like Data from STNG, "Becoming human isn't important as the attempt to be more than we are.".

    Mastery is it knowledge? Is it the understanding the core of the beast? Could it be something as intangable as God? Is it the ability to write a interface so simple that we are amazed?

    I don't think it is merely successfulling creating a goal. I have writing things that wow 'the guys at work'. But to the larger Perl community at best crap... a hack. I am not saying I am a master nor do I desire the responsiblity/expectation that would accompany such a great and noble title. But mayhaps it is not something we can set a goal to become but happens more by chance than by skill.

    So from a high standard that has been defined by those that are considered masters. A master is someone who has contributed in a significant way to perl and its larger community. And atested to that fact by the community at large. Not the code they wrote or the style it was written in, but a recognition of how they made, or though implicity made, our programming lives easier.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://446556]
Approved by Arunbear
Front-paged by pernod
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (13)
As of 2014-07-22 10:39 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (109 votes), past polls