Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer

OT: Use Perl wisely and cleverly

by simon.proctor (Vicar)
on Feb 21, 2003 at 22:38 UTC ( #237592=perlmeditation: print w/replies, xml ) Need Help??

It always amuses me when people choose to put down a language purely upon speed or based on an arbitrary benchmark. A recent node (Use Perl wisely, not cleverly) based its put down of Perl on a variety of reasons. Now ignoring the fact that the arguments used against Perl can just as easily be applied to Java and ASP (speed and memory) I do wonder why programmers or wannabe programmers get so hooked on speed and ram. Perhaps its a fast car thing that you grow out of ;).

There have been a handful of projects over the last five years that have required any kind of speed in their run. Aside from the fact that I used Perl in each case, I simply made use of the hardware and software (webserver, database etc) correctly and tried to use the best algorithm for the job.

Now I am fortunate that any intensive program I have written has had database, network and internet latency to compete with so the speed comparisons really become moot.

The point? Well a project I had to complete a while ago had to compete with a C++ multi-tier network system. The solution, replace with Perl. Why I hear you cry. Why use something that is so (tonque in cheek mode activated) bloated, slow, old, doesn't do (insert OO principle here) and hasn't had 6 O'Reilly books published on it in the last month alone?

Well, because we used it cleverly. Development time was reduced, debugging time went down from 3 weeks (or more!) to no more than a day, Perl was easy to teach to a larger audience and we were within 10% of the original C++ code speed.

So whats your point

Well my point is this. I'm glad your language has (insert feature here) and if I have to, I'll learn it and use it and do so happily.

But time and time again Perl has gotten the job done quickly enough and has allowed me to go home on time and have a life.

Think about that the next time you are still debugging a memory leak at 2am.

An afterthought

I do believe Perl can do most tasks, however I do know when and when not to use it (cleverly remember?). I just don't believe the speed arguments are justifiable.

Replies are listed 'Best First'.
Re: OT: Use Perl wisely and cleverly
by John M. Dlugosz (Monsignor) on Feb 21, 2003 at 23:42 UTC
    I do wonder why programmers or wannabe programmers get so hooked on speed and ram.

    Once upon a time, it was a requirement. My first computer had 1K and programmed in BASIC.

    I've noticed my feelings toward disk space is out of date, in that I've never had enough and now in recient times it's far more than enough. I mused that it must be like growing up during the great depression: you get a certian mind set and it prevails your whole concept of the subject.

    So, I suppose the same might be true about machine efficiency.


      A healthy appreciation of resources is a good thing IMHO.

      The system I work with is hellishly ignorant of the resources (disk and CPU) available to it and very inefficient because of it.

      We've got several Tb of disk, but waiting for huge files to be written to disk takes an age - I wish some people at least try to keep things sensible.
      We do actually run out of disk space - this is bad, and shouldn't happen.

      I think it might depend on each programmer - some people automatically produce neat/beautiful/efficient solutions out of the box, others just seem to say "what the hell, there's loads of space!".

      Things still have to work and scale.

      Before, on the older machines, you wouldn't be able to compile poor code, now the problems are deferred until the volume testing or production phases if someone doesn't think about these things carefully.



      If the information in this post is inaccurate, or just plain wrong, don't just downvote - please post explaining what's wrong.
      That way everyone learns.

         I agree that there's an enormous difference between the size and simplicity of some peoples code - partly this is due to skill, practise and ability.

         Sometimes it's background too.

         I started programming in BASIC around 15 years ago on a ZX Spectrum, from this I moved on to Z80 machine code, then onto x86 machine code.

         For a very long time I was the producer of prematurely optimized code regardless of the implementation language. There would be little tiny loops of functionality optimized for speed, or size, scattered throught the code - things would be unrolled for performance, and generally everything was a pain to modify.

         Then after reading 'Code Complete', and a few other related books, I achieved some enlightenment. Since then I've been mostly restrained; only optimizing the code which measurably needs it.

         When I get bored I'll write a version of life in 80 bytes of x86 assembly; that usually works it out of my system, failing that I'll decompile a random binary, and play around with it's internals..

         Optimization for me is a very introverted activity which is immensley attractive. At times it's enjoyable, at times it's painful, but I nearly always learn something new, and I usually enjoy the experience.

         For the average programmer optimization doesn't have a place in 99% of the code they'll write. (This is both a good thing, and a bad thing).

         Laziness, Hubris, and Simplicity are indeed the way to code. Optimize only when you need to, and only then after thinking of algorithmic changes.

          I do wonder why programmers or wannabe programmers get so hooked on speed and ram.
        Once upon a time, it was a requirement.

      Still is, in some places. If you have to process a hundred thousand records in one minute (to meet the client's demands for real-time reporting -- yes, I've been there and done that), program speed matters a hell of a lot more than programmer speed. As usual, it's a matter of recognising what problem you're solving, then picking the right tool for the job.

      F o x t r o t U n i f o r m
      Found a typo in this node? /msg me
      The hell with paco, vote for Erudil!

      It's not completely out of date. We do, after all, have limited RAM, HD and CPU to execute our programs. I could probably implement something that is very inefficient very easily. We want to pay attention to the speed, but we don't want to dwell on it (to the point of micro-optimization) or consider it the final word in language merit.

      I could write a script that slurps things into a linear array and do a painful linear search every time I want to see if an element exists. Or I could use a hash to do the same thing in much less time...

        Limits: Well, the engraving I did on another thread of TheDamian's code took 8 hours of CPU time on a 1.2 GHz processor. That would have been a rediculous amount of CPU usage and RAM just a few years ago.

        Back when I first did ray-tracing, I was using a 80286 with no floating point hardware! One time somewhere between that at the '486SX days I wondered about doing a hand-coded machine language version. The response from the group was that it was a waste of time; effort would be better spent on algorithm improvements than on non-portable and probably not maintainable issues.

        In my real work, I feel that using an O(n2) algorithm is "wrong" if you can do it n log(n). That is, don't go out of your way to make it super efficient, but don't do something stupid either.

        As for the ray-tracing, I think it was so slow because the objects generated from truetype font extrusions are not set up with simple bounding boxes. If I expanded that project, I would look at putting simple boxes around each line of text to early-out a non-intersection.

        But it won't stop me from wishing for a faster CPU, or wishing that the program were designed with efficiency in mind in the first place, with respect to the data structures used.


Re: OT: Use Perl wisely and cleverly
by Nkuvu (Priest) on Feb 21, 2003 at 23:01 UTC

    Well said.

    There is a time and place for everything, and no one language is suitable for every problem. And, as you have already pointed out, ease of development and future maintenance are also factors to look at before choosing a language.

    I do also want to point out, however, that people do tend to see the world through their favorite colored glasses. If I see a problem, the first programming tool I look to is Perl. Which may prevent me from properly seeing a more efficient solution. Keep your options open as much as you can and things will work out just fine. IMHO, of course.

      I couldn't agree more. So IMHO too :)
Re: OT: Use Perl wisely and cleverly
by Aristotle (Chancellor) on Feb 22, 2003 at 00:51 UTC
    More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity.
    -- William A. Wulf, A Case Against the GOTO

    Makeshifts last the longest.

Re: OT: Use Perl wisely and cleverly
by pg (Canon) on Feb 22, 2003 at 05:41 UTC
    I absolutely agree with you that Perl's ability to support rapid development is one of Perl's biggest winning point. It does improve every Perl programmers "development experience".

    Said this, I am not saying Perl is the only way of rapid development and to improve one's programming experience. I know not everyone like Microsoft, but you have to acknowledge that Microsoft does/did spend a huge effort in this area, and they did it very well. It is not very wrong, if I say Microsoft is actually one of the pioneers.

    Java is also a well recognized try in this area, and it is a big success.

    Acknowledge those other successful languages does not hurt Perl, absolutely not. Each language has its own use, its own strength, its own weak point...

    Perl is not fast, and uses lots of memory, those are agreed by most IT guys, but it still has its own seat in the hall of fame.

    To say there is applications not require speed is a little bit misleading. You have to quantify the speed requirement of an application. For example, we want to create a piece of code to do so and so, and the requirement says that it is fine for it to finish within n minutes, after our analysis, we decided Perl can meet this requirement, and we want to take advantage of Perl's rapid dev ability. so we pick Perl.

    Next day we have another application, it is only allowed to take m minutes. After a brief study, we decided that, Perl can not meet the requirement, and base on what the application will do, we find both java and c++ might be a good fit, then we go Java or c++. (Said this, I am not judging whether Java is faster, or Perl is faster. My feeling is that it would depends on the nature of the application, but in this example, I assume java is faster in what we want to do.)

    We don't need it to be "that fast", becasue it is not required, does not mean we don't want it to be that fast. If you can make it faster, you obviously would make it faster. However we have other requirements need to be taken care of, for example, as you said, we don't want to debug a memory leak at 2am.

Re: OT: Use Perl wisely and cleverly
by Anonymous Monk on Feb 22, 2003 at 00:07 UTC
    Agreed. It's another case of premature optimization. If you claim to need the speed while you are still choosing the language, then either you're ignoring the real issues, or you're good enough that this conversation is pointless. :P

    However, certain long lived, heavy duty server type programs certainly are much better off in a language like C. the OS, system libraries, servers like bind and apache... These systems certainly do benefit greatly from being programmed in C.

    Otherwise, rapid development in perl can save a lot of time and headaches (if the syntax doesn't kill ya :P ) and then a bit of memory profiling can show you the areas that get run the most and either need to be tightened up or programmed in a lower level language.

Re: OT: Use Perl wisely and cleverly
by shirkdog_perl (Beadle) on Feb 24, 2003 at 19:16 UTC
    Deja Vu the feeling you have done something before
    Deja Vu the feeling you have done something before
    Deja Vu the feeling you have done something before
    Here is my same reply to this wonderful posting Like I said the other day: BOTTOM LINE: Perl may not be the right solution for every job. However, there always is a solution in Perl.
Re: OT: Use Perl wisely and cleverly
by hsmyers (Canon) on Feb 24, 2003 at 20:34 UTC
    I suppose "I just don't believe the speed arguments are justifiable" doesn't apply to fractals?


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

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://237592]
Approved by Enlil
Front-paged by gmax
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (3)
As of 2023-03-29 16:45 GMT
Find Nodes?
    Voting Booth?
    Which type of climate do you prefer to live in?

    Results (72 votes). Check out past polls.