Perl is so good at connecting stuff and massaging data; Also, it can be done so fast that there is the temptation to use it as a cement to assemble disparate material when it would be wiser to restart from scratch. That can be the price to be casted as a Perl programmer even when you would think it would be sometimes wiser to write bricks in C, than to haphasardly cement material that have been imposed on you.

Management: do it in Perl, that will be done faster. Well but not always better :(

-- stef

Replies are listed 'Best First'.
Re: Downside of Perl (relative) popularity
by footpad (Abbot) on Mar 29, 2001 at 20:36 UTC

    I'm not certain there's a downside to Perl's popularity so much as there's a downside to short-sightedness and poor (or lack of) planning.

    A few instructive clichés come to mind:

    • When your only tool is a hammer, everything looks like a nail.

    • It's possible to write bad code in any language. (or perhaps more appropriately: You can write good code in any language.)

    • Poor planning on your part doesn't require poor planning on mine.

    The main points being:

    • Use the best tool for the job.
    • Evaluate and test solutions carefully.
    • Keep an open mind. It's nice to enjoy using certain tools, but learn the alternatives, even ones you find distasteful.
    • Experiment, test, and learn.
    • Actively, and continually, seek to improve your skills
    • Discover, accept, and then find ways around your limitations and your mistakes.
    • Document your findings, even if only in personal journals and/or "notes to self."
    • Effective solutions balance the idealistic and the realistic.

    Specialization and success are both nice, however, there is no excuse for complacency. I believe wise programmers (and managers, for that matter) will actively seek ways of doing things better, even when handed a disorganized or poorly designed mess to start with.

    --f

[reply]
      "Poor planning on your part does not consititute an emergency on mine."
[reply]
Re: Downside of Perl (relative) popularity
by mirod (Canon) on Mar 29, 2001 at 20:05 UTC

    You are probably right that sometimes it is better to restart a project from scratch than to try to re-use pieces of code that really don't belong together.

    I have to object though to the way you seem to consider C superior to Perl. C is right for low-level stuff, basically when you want efficient code, both fast and using little memory. When you are writing perl, the interpreter for example. For most other tasks the price is too high. You loose a _LOT_ in development time and potential bugs or security problems. I have worked in very few projects where the cost of using C would have been justified. And I have been involved in a lot of projects, both in C (in my pre-Perl days) and in Perl.

    So yes, start from scratch, but why not start from scratch in Perl?

[reply]
      So yes, start from scratch, but why not start from scratch in Perl?

      I put it to harshly when I said starting from scratch. . In fact I am dabbling with linux networking stuff: ipvsadm, keepalived.and ip commands and some added configuration layers. Eventually I end up with the same data in different configuration files. keepalived polls services defined by ipvsadm so its configuration file repeats material needed for ipvsadm. Compatibility with installed stuff is a criteria as well.

      So It is difficult to decide which configuration file is authoritative for what. Anyway I need to deal with inconsistencies between them. I intend to provide a Perl API to some C code extracted from these commands. But I am not sure I will be given the time to do it. What I want is to avoid to massage many configuration files but to have one that drives everything.

      In other words, one should not always work by adding layers on top of layers in Perl (*) but must deal with C to reorganize and/or to provide an clean Perl API.

      (*) later edition In Perl or any scripting language. My point was that because some managers know you can pee code in whatever language, they may prefer quick fixes over quick fixes and one ends up in a mess.

      -- stefp

[reply]
Re: Downside of Perl (relative) popularity
by stephen (Priest) on Mar 30, 2001 at 09:55 UTC
    You might consider this:

    If you build the cobbled-together solution carefully, putting good wrappers around the disparate pieces of the system and writing careful tests for all aspects of the system's functionality, you'll learn more from building the prototype than you would from a month of pure design time.

    Also, remember that Perl and C are far from being mutually exclusive. If you can get a running system in Perl, you can run a profiler on your running system and find the parts that need to be optimized. Then, if you need more speed than Perl can provide, you can use XS or Inline to port only the code that you need to C.

    I don't mean that good up-front design isn't important; it is. But getting a solution going in Perl, even a slapped-up prototype, can greatly aid a good design, and frequently can be turned into a final solution step-by-step.

    stephen

[reply]

Back to Meditations