*grin*

Actually this really reminds me of a phrase that I first heard in ping-pong. Someone was asked how he was, and he answered, Well I am good enough that if you think you are good, I am probably better, but if you are good enough to know what I mean, you are probably better. The point being, of course, that if you have never met people who know how to play, you aren't very good. But if you play seriously then you wouldn't usually think of yourself as good because you are painfully aware that there are better people out there.

It is the same way with programming. There are a lot of people who think that they are very good because they have never been exposed to good people. The person you describe sounds like one of those to me. Is knowing how to look something up in the index of a book which is better replaced by knowing how to search the POD really mastery of Perl? Gee, I know that I went well beyond that level of competence without, for instance, appreciating strict, or knowing how to use Exporter to ease the pain of the package command.

But sadly, even then I knew more about Perl than the vast majority of people you see in interviews who call themselves Perl programmers. :-(

-- Randal L. Schwartz, Perl hacker

Hmm, does buying you cheesecake count? (How about not discussing what happened with that waitress at the Red Rock Tavern? :)

Yeah, I'm itching to move up a level...

That has a nice ring to it, but I'm at least mildly serious. A novice tries to write Perl code that looks like other languages he knows. An apprentice works Perl idioms into his code, and a journeyman uses the idioms correctly. A master stops noticing any of that and just writes code.

See also The Tao of Programming for a humorous take on mastery, which isn't quite as humorous if you know what you're doing.

It seems that most programmers stop as rank (emphasis on rank) amateurs when they are satisfied that they know enough for their needs. In fact I suspect that a programmer who has stopped trying to master the art is probably not very good...

Well by *that* definition I can speak fluent Greek, as long as I have my English-Greek dictionary. :)

Maybe you could print out some Obfuscated code from this site and (with a look of slight fawning and total innocense) ask him he could help you with a small section of it. Perhaps even reformat it a little so it doesn't appear quite so obviously obfuscated.

We don't have Masters in Perl, we just have the Seven Stages of a Perl Programmer: Novice, Initiate, User, Adept, Hacker, Guru and Wizard.

"...is fairly easy to learn, but takes a lifetime to mater."

Mike - mps@discomsys.com

"The two most common elements in the universe are hydrogen... and stupidity."
Harlan Ellison

Yes. That's the lingo printed on boxes for the game of "Othello".


AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.

I disagree, to an extent. Some languages evolve. ANSI C hasn't changed enough to affect seriously affect anyone who wrote C 15 years ago. 6800 assembly is still 6800 assembly, 18 years later. Fortran-77 is still what it was.

More complicated languages have a tendency to evolve, such as Perl, C++, Python, etc.

Are you going to tell Brian Kernigan he hasn't mastered 'C'? Or Strousup on C++? How about Charles Moore on Forth?

Mastering a language is comprised of several pieces. One piece is that basic grammar of the language. C has a simple grammar, as do most assemblers. Forth has a *very* simple grammar. Yet, simply mastering the grammar doesn't make you a master of the language.

Mastery of a language is being able to clearly accomplish a goal, with a minimum of waste. A shorter program doesn't always mean that the author is a better master of the language than a longer program. I may write a very simple one liner that solves a problem, but it may not be efficient, well documented, etc. A master of a language uses idioms, styles, and documentation that allow subsequent users/maintainers of the program to understand what is going on. One only has to look at some of the by the more famous authors on CPAN to get a feel for this. The code may work, but it's not necessarily well documented (in fact, this is one of the biggest weaknesses of these aforementioned people. Dog help us all if the author of CGI.pm ever gets hit by a truck).

Mastery involves knowing *how* to apply your knowledge of the langauge you know to solving the problem. An incomplete understanding of the language or the problem can yield inefficient or incorrect results, indicating that you are NOT a master.

In fact, the more I think about it, the less I believe in the concept of mastery of a language. I can make a 8051 stand up and beg, and write really honking tight code, but I can't write a 'C' compiler in it. Mostly, because I'm not skilled enough. But I have really tight fast serial drivers that many people have used. Does that make me a master of 8031? No, I don't think so. I'm good at implementing the problems I know (or can figure out) how to solve with that toolset.

Rather, I think people who exhibit "mastery" of a language are in fact, simply good programmers. They know enough about the language to solve the problem, enough about the problem to generate a solution, and it's tested, documented, and presentable to the world at large. The two are inseparably combined. You can't have a worldclass programmer who can't write code (those are called theoreticians, and hand algorithms to programmers), and you can't have a programmer who doesn't understand the problems, or he has no way to implement anything he understands (those are called quota-hires).

A good programmer knows what the language is capable of, and knows how to put that knowledge to use solving problems. S/he knows that it's a trade off between readability (inherent to the coding style), documentation (which is affected by the coding style), and efficiency. Some people are better at exploiting the full capabilities of a language than others, some people are better at solving the problems. And the people who can do both get paid a helluva lot.

My $0.02 worth.

--Chris

e-mail jcwren

> ... Quidquid perl dictum sit, altum viditur.

Umm...

foreach $thing (@said)
{
    $thing =~ y/<>?:"'{}[];\+=|)(*&^%$#@!~`//d;
    regard(R_HIGHLY,$thing) unless (system("perl -c $thing"));
}
[download]