in reply to On human memory management

There was a time when I knew everything about C++. I was amazed one time that Stroustrup himself wasn't sure if something was one way or another, and I reminded him that it had to be one way because of the way it all fit together.

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

Replies are listed 'Best First'.
Time to re-read the Camel Book (?)
by bronto (Priest) on Jan 29, 2003 at 09:42 UTC

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