Personally I think that you can learn programming in at least two ways: studying it from the ground up and/or step by step, guided by the problems you are trying to solve. That's how our brain manages available memory, right?

The first way to learn takes its roots from rationalism that was put forward by Descartes: one can achieve understanding by pure reasoning and methods.

The second way to learn is a pragmatic way that was developed mostly in the 20th century (Anglo-Sax philosophers Dewey, James).

I don't think you can learn everything about a programming language. Neither you can learn everything about a chess game. There's always something new to find out about it. The more you learn, the more open roads you see.

When I studied Perl at the university, I used the rationalistic way. At my work I take the pragmatic approach. At the university I tended to be slow because very often I didn't know which variable to set, which function to call. On the other hand, I knew the language syntax better. Because I start to forget language syntax, I tend to avoid some nice and clever solutions, choosing a fast and dirty way. That's why sometimes I should forget my day-to-day scripting, sit down and meditate on things, look up the Perl Monks posts.

We live in a postmodern age and if one becomes religious about one way or another of doing things, this seems very suspiscious to me. I think the most principled Perl programmers and best monks here tend to find a solution to each problem they meet and never give up.

The first way to learn takes its roots from rationalism that was put forward by Descartes: one can achieve understanding by pure reasoning and methods.

Let's also take a lesson from Voltaire and remember that reason isn't the end-all and be-all. You can't achieve understanding through reason alone.

Update In case you are curious - there is a neato-keen book on this subject: Voltaire's Bastards. I forget the author. Just use Voltaire's Bastards. I've had this book stolen from me twice now while I was reading it. I can only assume others really wanted a copy.

---

Seeking Green geeks in Minnesota

John Ralston Saul is the author of Voltaire's Bastards. He's also the husband of Adrienne Clarkson, Canada's Governor General.

Fun book...

Researchers have shown it takes about ten years to develop expertise in any of a wide variety of areas, including chess playing, music composition, painting, piano playing, swimming, tennis, and research in neuropsychology and topology. There appear to be no real shortcuts: even Mozart, who was a musical prodigy at age 4, took 13 more years before he began to produce world-class music. In another genre, the Beatles seemed to burst onto the scene, appearing on the Ed Sullivan show in 1964. But they had been playing since 1957, and while they had mass appeal early on, their first great critical success, Sgt. Peppers, was released in 1967. Samuel Johnson thought it took longer than ten years: "Excellence in any department can be attained only by the labor of a lifetime; it is not to be purchased at a lesser price." And Chaucer complained "the lyf so short, the craft so long to lerne."

Makeshifts last the longest.

It's a scary thought that most hardware is considered obsolete before anyone has enough experience with it to write decent software to run on it.

Particularly in the case of operating systems!

__________
"Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work." -- (Author Unknown)

With a language like Perl, I don't think that day-to-day problem solving tasks limit what you can learn about the language. Thinking through the ways of doing things, thinking about why you need to do it the way you are, even down to writing the actual code and debugging it - all of these subconciously advance your knowledge and ability, your "comfort factor", with the language.

From a maintenance point of view, I personally find script maintaining quite a dull task, although it's something I try and keep my interest up with by trying to learn from code that (most of the time) someone else wrote.

I think that limitations on learning are purely a psychological thing - if you have a mindset that's willing to explore and consider new things you encounter, and learn from problems and mistakes, then you'll never stop learning new things..

As far as knowing everything about a language goes .. we recently had an interesting discussion on a similar/related theme: Self-improvement and TMTOWTDI. The conclusions people came to were quite varied, though *grin*.

I find the presence of a community invaluable, both as a support forum for problems I encounter with the language and as somewhere that I can learn an immense amount about areas of Perl I haven't/wouldn't have considered if someone hadn't asked about it, or it hadn't come up in some other way.

From my point of view, the distinction between a virtual and "real" community are purely theoretical. The same benefits can be attributed to both (with the possible exception of social contact *g*).

-- Foxcub
A friend is someone who can see straight through you, yet still enjoy the view. (Anon)

do you think it is possible to know everything about a programming language?

To a certain extent. I think you can regularly use all of a relatively small language like C. But the base language isn't the most important part; the functionality of standard and 3rd party libraries is much more interesting. The basic syntax of Perl is interesting but CPAN is where Perl really shines. Knowing which modules to use for certain kinds of problems can be much more helpful than knowing everything about Perl's syntax.

Computer languages are tools for solving problems. Some people see the language itself as a subject for exploration, and others just need to get a job done, preferably as fast as possible. The latter type of people are just interested in the end result and don't really care if it can be done more elegantly.

are day-by-day problem-solving tasks a limitation on the things that you can learn about the language?

Not necessarily. If all you do each day is write the same type of programs, then learning some new features isn't really necessary. However, I think that being a programmer means that you're allergic to repeated tasks, and look for ways to automate those away. It's that search for automation which almost forces you to learn new things. Of course, lots of people are happy with using a fixed subset of a language and have no desire to learn more.

how important is the presence of a community, real or, like perlmonks, virtual?

It always helps to have access to "real" people for asking questions, handholding, etc. Some people need that very badly, others are more inclined to search for answers to their questions by themselves.

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

Also, I remember reading (maybe in an interview -- quoting himself?) that Larry has been known to say "I didn't know perl could do that."

  p

how important is the presence of a community, real or, like perlmonks, virtual?

I'd say it's very important.

One important source of knowledge and insight is problem solving. That is (partly) what this site is about.

By being exposed to not only your own, but other people's problems, you pick up important, actual, real-world solutions. Canned experience. By being curious you can keep yourself informed about not only the things you do daily, but about the things you might be doing in the future. It widens your horizons. You get to hear smart people ask questions that you never would have asked yourself, making you (at least appear :) smarter in the process.

I find this tremendously beneficial to my own knowledge about general software development, to my computing street-smarts, and to my ability to have informed opinions about a wide range of subjects.

This doesn't even have to do with Perl, but with general concepts that you pick up by hanging in an environment (like Perl Monks) where they are used; MD5 hashes and what they are good for, error handling strategies, other programming paradigms, project management etc, etc. Things that may be difficult to come in contact with in day-to-day problem solving activities on your own.

/J

I second this. I'd like to believe I had more clue than is average for those new to the site when I arrived here, and yet I have to say my 1.5 years here on Perlmonks and the direct exposure to some of the most capable folks around have benefitted my growth tremendously. And I realize it's still a long way to get where they are; it has been a humbling but altogether pleasant experience.

Makeshifts last the longest.

Self-improvement and TMTOWTDI covered some of the same issues you're thinking about. Might be worth a read.

That's the key: everything fits together with features' subtle points designed to lead to elegent combinations with other features, or the result of strict application of general principles.

I could know how some feature should work without reading the details, because I knew the general philosophy and concepts. When I did read it, that just re-enforced things, and I noticed anything that wasn't expected and remembered just that.

The example of a negative limit for split doesn't work this way. Through application of principles, you get either (1) a negative number is just another number, and a single simple statement of what that number does should handle all cases. Well, that's wrong since 0 is a special case and negative is a different special case. Or (2) it would count from the right instead of from the left, returning the last n values if you specified -n. Well, it doesn't do that either.

If you didn't look it up, you have no reason to suppose negative split limit does what it does, or even exists. It's an arbitrary factoid to remember.

The very nature of Perl to be like natural language--inconsistant and full of dwim and special cases--makes it impossible to know it all without simply memorizing the documentation (which is not complete or totally correct anyway).

—John

Really interesting point, John

Of course, every single reply before yours gave me some things to consider, but I think that you really get a point here:

If you didn't look it up, you have no reason to suppose negative split limit does what it does, or even exists. It's an arbitrary factoid to remember.

The very nature of Perl to be like natural language--inconsistant and full of dwim and special cases--makes it impossible to know it all without simply memorizing the documentation (which is not complete or totally correct anyway).

I really feared that.

In the beginning of my Perl experience I started reading all the Camel Book; so, in theory, I should have known almost everything of every function. In practice, all construct that I never used, or that I tested with sample code but never used in practice, have disappeared; probabily, my brain simply discarded them as "not useful"

Gee! Is it time to start reading the whole Camel Book again? Maybe the thing I know now will give a new light to it...

Thanks everybody!
--bronto

PS: You are going to be in my new signature :-)

# Another Perl edition of a song:
# The End, by The Beatles
END {
  $you->take($love) eq $you->make($love) ;
}

Broadly speaking, there are 2 (at least) kinds of book; those that are read once and those that are read again and again. Without regard to fiction or fact, I prefer books of the second kind. Certainly the Camel is one, so is “Effective Perl Programming”---obviously there are others, the fun is in finding them. If as Silverburg teaches, “90% of everything is crap” console yourself with the fact that the value of the ten vastly exceeds the overhead of the ninety...

--hsm

"Never try to teach a pig to sing...it wastes your time and it annoys the pig."

One of the big contributions of an online community to the learner and practitioner of a language or a computing technology is have your problem or trial solution looked at by a variety of inteligences.

By this I mean by people whose profile of computing strengths complement yours. Some are exceptional exceptional strong at keeping a encyclopedic array of detail at instant recall. Others excel in seeing a path through the thicket to the solution that is eluding you. Some have a crucial insight through experience in the problem domain. Often someone helps you read the documentation you have been reading with a slightly different slant or directs you to different lore (or CPAN modules). These same facets often emerge in successful project teams.

Programming can be a much more social activity some of us admit. Regarding perl, I am glad a took my vows in this order. Thanks, Perlmonks.

Bob

Clever signature unintentionally omitted.

So, I think it's possible to know everything about a programming language (provided it doesnt evolve faster than we learn :) - But impossible to be able to recall all that knowledge, the more complex and different programms you write, the more parts of the language you will be able to recall. Which means that the day-to-day tasks are a limit, in my opinion.

Having a community such as this one, and not only asking questions, but also reading and answering others, is very important, if you want to go beyond your own boundaries.
I find I *like* to learn, reading questions I have no clue about usually makes me go look up the answer, and try things out. So I learn about things that I otherwise wouldnt have come across, and benefit from the view of others on the subject at the same time.

C.

This is very true. The human brain is basically a very efficient association machine fed by an incredibly powerful pattern matcher that builds connections even as it uses them. Knowledge you gain is never lost, but if you don't recall it often, it does not get associated with a lot of things. So the patterns you can feed your memory with to retrieve it are very exact, in other words, you will only remember it within a specific context. You can, however, with deliberate training improve your pattern matching ability and thus your ability to retrieve seldom needed facts from memory.

In this respect, the mind is like a muscle - the more you strain it, the more capable it gets.

This means it pays off to feed your memory stuff for two reasons. It will be there, even if you don't currently have the circumstances to recall it. And your matching abilities get better the more distantly related the facts you manage to associate are - for which broad and plentiful knowledge is a prerequisite. It's a feedback process.

Makeshifts last the longest.