Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Reverse Engeering of Learning

by artist (Parson)
on Feb 25, 2003 at 04:33 UTC ( #238353=perlmeditation: print w/replies, xml ) Need Help??

Dear Monks,
This conceptual thought is inspired by How some people live without Perl.

I am not so sure for the exact term, but let me try. "Reverse engineering of learning".

We have found that in perl it's very easy to do the things which otherwise would take more effort and perl itself has also TIMTOWTDIT motto which promotes best and alternative practices.

If we think about various ways of doing the same thing that we are good at it, we can understand better what we have at our hand and it can also open other avenues of learning and better praticing.

For our practices it makes much better sense then 'when eletricity doesn't work, use candles.

Here the idea is to use different types of tool in the toolbox, so every problem doesn't look like the nail, and we have more than one tool to fix the nail if fixing nail is the only problem we have.


Replies are listed 'Best First'.
Re: Reverse Engeering of Learning
by hardburn (Abbot) on Feb 25, 2003 at 15:03 UTC

    I've always had a slight mistrust of the "use the best tool for the job" metaphor, but for reasons I can never quite figure out. The metaphor seems logical enough, but it bugs me somehow.

    One thing I can figure is that creativity can do wonderful things. A hammer might not be the best tool for sawing wood, but I must wonder if someone has a clever way of doing it that is almost as good as using a saw.

    (Which I suppose is more of an argument for VB than Perl--you'll spend much of your time in VB coming up with creative ways around its flaws.)

    Reinvent a rounder wheel.

    Note: All code is untested, unless otherwise stated

      I've always had a slight mistrust of the "use the best tool for the job" metaphor, but for reasons I can never quite figure out.

      In a programming context my unease usually revolves about one of these:

      • often uttered when serious comment was desired
      • best is often a grail, several tools may be nearly equivalent
      • personal bias or hidden agendas may be involved
      • the implied dismissal of the importance of the tool user's experience
      • perhaps the job is not defined well enough for such decisions
      I've had the same feeling, and I think my unease arises from a simple problem: people often aren't thinking of the right job.

      By that, I mean that many times a particular tool my be a perfect fit for the exact job at hand -- but if after a dozen jobs, you find you've used a dozen different tools, then you have an extension and maintenance nightmare.

      The problem is that the immediate job that you're thinking of is usually only a part of a larger job, which is usually something like "get all of these jobs done, and working, and maintainable, and done in such a way that we'll be able to do the next set of jobs well too." And that argues strongly for using a very minimal set of languages, so you can share code and have the various solutions interoperate well, and also so that you can draw upon the existing solutions in crafting new ones. This will necessarily mean that some jobs will be solved with suboptimal tools.

      Extending the "job" further, you may also want to consider other people -- it's a lot easier to find people who know Perl and C than people who know Perl and C and Java and Python and Lisp and Intercal and....

      All that is not to say that "the right tool for the job" isn't a useful metaphor. My manager recently asked why my engineering team had chosen use Perl rather than Java to write a set of command-line tools for managing our system. I looked at him with the same air of puzzlement that I would use if someone had asked me why I didn't use a dead fish to pound in a nail.

        For the real-world, sometimes I'll use my pocket knife for something instead of going to the garrage for the "proper" tool. Why?

        1) it's handy. That's like the overhead needed to write hello-world in C++. For simple jobs, the overhead is more than the job itself.

        2) regular tools are very specialized. A multi-tool swiss-army-knife might have something that's good enough. But if using a good (expensive) screwdriver I don't want to use the wrong one! I might need several box wrenches to figure out which one I need, when an adjustible wrench (the VB of tools) would work.

        Now some tools are general without being toys. A good strapwrench, a "gator grip", vise grips, a 6-tip ratcheting screwdriver, a dremel tool.

        But, in the garrage, I see nothing wrong with having more tools! There is a big benifit to using the right tool for the job, and figuring out how to use a specialized tool is often easier than getting the job done without it.

        I think that last point changes everything. Tools or accessories that are too much trouble don't get used. They naturally find their way to the back of the shelf and are eventually forgotten.

        As for maintainance, that's not an issue with building things, but can be for household repairs. If a plumber fixed my sink, I might need to go out and get the same kind of tool he used next time I work on it myself. As it is, I know that anything I put together I have to right tool to take apart again. The first step to upgrading a Tivo digital video recorder is "go buy Torx #10 and #20 screwdrivers".

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://238353]
Approved by Aristotle
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (3)
As of 2017-01-18 08:42 GMT
Find Nodes?
    Voting Booth?
    Do you watch meteor showers?

    Results (161 votes). Check out past polls.