in reply to Hmm, has anyone read Heart of Darkness?
in thread My Laptop talks to me.

Perl proves it's worth over programming languages on a daily basis.

This is not about one being better than another, this is about programming standards. There are many standards that can be applied to any and all languages. I would certainly not say perl has proved its worth OVER any other language. I as a programmer have a toolbox of languages and techniques to call upon. Perl is a valuable tool in that box.

This is one of the first lessons I picked up in a Perl coder rich environment: Perl is not wholly a scripting language and not entirely a programming language. As a result it doesn't sit entirely in the idiom of either. You will concede that the coding philosophies for these two differ?

I would be interested in hearing what differences you percieve between the two languages. Larry has his own opinions He feels that the difference is meaningless and I agree.

I am upset by the slanderous comment about side effects, if I removed the return from the line of code you've quoted and relied on the fact that Perl returns the value of last item used in the sub-routine, then that would be a sort of side-effect (I prefer to call them features).

Side effects Have specific meaning have a look at Referential Transarancy Avoid side effects in general to improve the resiliance of your code. It is general and good advice IMHO and has nothing to do with perl in specific. It is CERTAINLY not slander, I can only assume you did not understand my comment.



  • Comment on Re: (Zigster) Hmm, has anyone read Heart of Darkness?

Replies are listed 'Best First'.
Oh Brother.
by frankus (Priest) on Apr 12, 2001 at 15:44 UTC

    This saddens me, not least of all as I conceded, did you read past the word slander?
    I wouldn't mind but I don't even believe in polarising things to right or wrong.
    Couldn't we just agree to agree?

    Brother Frankus.


      FWIW this time I agree with zigster.

      Perl is a language that allows you to play fast and loose. However it does not free you from the laws of human comprehension. It does not change anything about what is and is not good programming technique. And the sooner you learn that, the sooner you will truly master Perl programming. Allow me to summarize the key points:

      1. If you wish to solve small problems, then scripting is acceptable and can be done much faster than real programming.
      2. If your problems grow into the realm of real programming tasks, scripting as a style is inherently a bad idea.
      3. Perl has not proven or disproven any general principle about good programming technique. It merely sits at an unusual combination of design choices that intentionally does not try to force you to program well.
      4. As I have said many times, I do not like working with programmers who have not absorbed these principles.
      Please read what you wrote and what zigster replied with carefully. Then read Re (tilly) 6: Ways of commenting subroutines. Then read all three parts of Avoid symbolic references.

      Hopefully between those I have convinced you that good Perl programming is first and foremost good programming, and only secondly does it have anything to do with Perl as Perl.

        I have to comment. Using symbolic references of the form $$i is stupid. It's more than stupid. You're creating unknown global variables in your script. If you're a dealing with user input, you should be socked. (Homey don't play dat!)

        However, if you use symbolic references of the form ${"$package_name::$i"}, I think you're quite a bit safer. You have made sure that the global namespace is safe, especially as you're in control of $package_name. Why would you do this? Well, there's a way of implementing objects using parallel arrays instead of hashes. In certain cases, where you have a large number of instances of this class and/or you will be creating/destroying them on a regular basis, it's much faster, even with the cost of string interpolations and symbolic references.

        To sum up, I don't think symbolic references are necessarily a "Bad Thing"(tm). I would actually say it's that global things are almost always bad and that the default way of creating a symbolic reference is in the global namespace.