We've had lots of "change your Point Of View" and "Think Outside The Box" Meditations over the years. Ovid is fond of mentioning Why I like functional programming, as a revelation. All of us have blind spots.

Well, it's one thing to read about it and another to have it smack you in the face. Specifically, on over at this node. I don't really use Unix - I'm just now teaching myself the basics of Linux. And the cronjob (and it's moral and spiritual equivalents), which seem common to the Unix culture is less common over in Win32-land. It was a blindspot for me, and now I am aware of it. So far so good.

But I couldn't sleep tonight, for various reasons. So I started thinking. The truth is that blindspots are places where you can't see - even the little bit you need to know that the blindspot is there. I started thinking on my little question. It occured to me that I should be surprised it hadn't been --'ed into oblivion. What I was asking wasn't a Perl question - it was CGI/design question, rooted in my lack of knowledge about multitasking operating systems. And I was aware of that when I wrote it. That's the kicker - I was aware of what prompted my question, but I still thought of it as a Perl problem!

That my friends, is a blindspot.

You see, my problem is that I cannot see any computer problem as a problem for Perl. Instead I see them as Perl problems. Perl has become the problem space in my mind, not the solution. That's a serious deep rut. For me this realization will probably make me a poorer programmer. Why? Because I'm a musician and actor, not a programmer. Programming is a hobby, but Perl has become too deep an aspect of my thinking. It has in many strange and subtle ways improved my composing, but now it's hard to think about music without my train of thought being diverted to Perl, because Perl is a deep part of how I think - which it shouldn't be.

You can't see blindspots because the mental equipment needed to recognize a specific blindspot is often part of what said blindspot excludes. Ask yourself over the next couple of days - is this a Perl problem? Is this a CGI problem? Is this sysadmin problem? Is this a computer problem (tricky one)? Is this a problem (trickiest!)?

Me, I'm taking a Perlmonks and Perl break. Give the rest of my brain a workout. It'll be interesting to see if improving the seemingly distant aspects of myself will improve my thinking with regards to programming. I suspect that it will.


Light a man a fire, he's warm for a day. Catch a man on fire, and he's warm for the rest of his life. - Terry Pratchet

Replies are listed 'Best First'.
Re: don't { use Perl }
by derby (Abbot) on Jun 10, 2002 at 12:24 UTC
    You see, my problem is that I cannot see any computer problem as a problem for Perl. Instead I see them as Perl problems.

    s/computer/domain/; s/Perl/tool/;

    I think this is a truism no matter which profession your in - auto mechanics, home building, medical arts, etc. There is something deep in the human psyche that places special emphasis on the tool rather than the craftsmen. Every time I feel like "blaming" the tool I remember what my dear mom used to tell me while trying to build that go-kart in the back yard:

    It's a bad craftsman that blames his tools.

    So take your break (everyone needs to do that at some point anyways) and think about what you want out of your trade and what tools will help you accomplish your goals.


Re: don't { use Perl }
by hakkr (Chaplain) on Jun 10, 2002 at 09:00 UTC
    look like you need to broaden your computing horizons my friend. There is more than one language to do it. The fewer blindspots you have the better you are. Preventing wheel reinvention is what the CPAN is for and if you had remained blind to cron you might have written a Perl daemon with a lot more effort. Don't think outside the box think outside the octagon.

    YOu are right though Perl day in day out can make you blind and certainly a poorer programmer as you are exposed to fewer solutions and eventualities. I usually turn to computing magazines or websites to keep me up to date with the problem space of our everychanging world. You message should therefore be don't use Perl all the time for everthing just because you like it. Your lucky being artistic I find it hard to work out my brain any other way.

      I don't think that Erik's point was that using just one language made him narrow minded. His main problem is not able to figure out in which domain a problem lies. Knowing more languages than just Perl doesn't solve the problem of determining whether a solution needs to be searched in the language, the protocol, the system, the hardware or something else.

      It's good to broaden your horizon, but I don't give to much weigth to knowing lots of languages. Small domain languages can be useful, but the added value of knowing more general purpose languages rapidly decreases IMO.


        When I read your remark:
        It's good to broaden your horizon, but I don't give to much weigth to knowing lots of languages. Small domain languages can be useful, but the added value of knowing more general purpose languages rapidly decreases IMO
        I immediately thought of Claude Levi-Strauss' remark "Language conditions thought." and wondered if you would agree or not?


        "Never try to teach a pig to sing…it wastes your time and it annoys the pig."
Re: don't { use Perl }
by vladb (Vicar) on Jun 10, 2002 at 13:29 UTC
    Perl is really just one of a number of excellent (or not quite so :) tools to accomplish a given task. For example, If you need a script that has to run perpetually and rotate logs once in a while, well, you still can write a perl script to do the actual log rotation and crontab to schedule your script's work. Of course, a programmer with limited exposure to Unix system functionalities (or lack thereof), yet ample Perl programming experience, could write a daemon to also run perpetually, yet do the same job, and probably do it good.

    Now, to me the question of when to not use Perl is actually rather straightforward. Mostly, the answer would be 'yes' if I'm dealing with CGI, sysadmin, or any other tasks that could be accomplished by a cleverly crafted 'script' (Perl is a clever language :). However, if there's a task where you clearly see that no script would help, certainly Perl wouldn't be the answer. For example, lack of processing power of a given computer is certainly a 'computer problem'. While, you could optimize your Perl script to squeeze maximum performance, replacing your processor or adding a couple extra MB of RAM might help. Hack, it does sound like a double edged sword in certain cases, doesn't it? ;-)

    $"=q;grep;;$,=q"grep";for(`find . -name ".saves*~"`){s;$/;;;/(.*-(\d+) +-.*)$/; $_=["ps -e -o pid | "," $2 | "," -v "," "];`@$_`?{print"+ $1"}:{print" +- $1"}&&`rm $1`; print$\;}
Re: don't { use Perl }
by FoxtrotUniform (Prior) on Jun 10, 2002 at 18:28 UTC

    It's difficult for me to get out of the habit of using whatever tool I've been working with at the moment to solve any problem that comes up. (Usually, that means C and Perl.) When I can break out of that rut, though, very good things happen.

    For instance, a while ago I was handed a fairly nasty data munging problem (I can't recall the specifics, so this story may sound pretty vague; my apologies). Naturally, I first attacked it with Perl. It wasn't responding well to the attempts I made at solving it, and I was getting pretty frustrated. In a fit of right-brained brilliance, I realized that, if I only had the data in a DB, it would take but one line of SQL to solve the problem. Five minutes later, I was done.

    This is one major advantage to having a reasonably broad knowledge of the field: other solutions are constantly bubbling and percolating just behind your subconscious. Sometimes, they escape; sometimes, they're better than what you've been hacking on for the last hour.

    The hell with paco, vote for Erudil!
    /msg me if you downvote this node, please.

Re: don't { use Perl }
by boo_radley (Parson) on Jun 10, 2002 at 14:18 UTC

    erikharrison says :

    Me, I'm taking a Perlmonks and Perl break.

    You'll be back.
      They all come back.
Re: don't { use Perl }
by Juerd (Abbot) on Jun 12, 2002 at 16:55 UTC

    What I was asking wasn't a Perl question - it was CGI/design question

    Many of this can be solved by widening your horizon, as some have already said. One way of doing that is using other programming languages, but every time I do that, I only get annoyed by the other language and wish it was more like Perl. My way of seeing things apart from each other is reading specifications.

    Let's take CGI programming for example. We use http, so let's skim over its specification (rfc2068) and see what happens. In the abstract, it states that http is stateless. So we know our CGI script won't be running forever, but will handle only one request. It also mentiones headers, which is important: apparently headers are not a CGI-specific thing. So let's see what CGI is then. Using its specification, of course. It says some things about standard input and output, but Perl is never mentioned. Hey, CGI is not Perl-specific!

    Reading non-Perl documentation is often a good way to know that some issue is not a Perl issue. When googling for information, try "-perl" to refuse all documents with "perl" in it, and see the other approaches.

    - Yes, I reinvent wheels.
    - Spam: Visit eurotraQ.