Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation

Re: How do you master Perl?

by samizdat (Vicar)
on Apr 11, 2005 at 17:05 UTC ( #446682=note: print w/replies, xml ) Need Help??

in reply to How do you master Perl?

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

Replies are listed 'Best First'.
Re^2: How do you master Perl?
by brian_d_foy (Abbot) on Apr 11, 2005 at 19:23 UTC

    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 <>
      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

        I like the Kung Fu example, although I never did watch the show. :)

        It that the same thing as saying that the world is what it is, and you just have to deal with it according to its nature? I've been thinking about that too, especially with Perl. People have all sorts of reasons for liking or hating Perl (or some other language), but the language just is what it is. Maybe we get annoyed by something in it, but there's no reason to take these things personally.

        Or maybe I need to watch more Kung Fu.

        brian d foy <>