in reply to TMTOWTDI... and most of them are wrong

I'm pretty new to Perl, but its key attraction is how much you can do with how little. I think Perl loses a lot of its advantage when you a start writing large chunks of code with it.

To misquote a little: Easy things are quick and hard things are possible. Although hard things are possible, they may take a long time and be troublesome to get right and to maintain. Other languages that provide more type safety may prove better in the long run than Perl for "hard" or large projects.

Good programmers can write good code in pretty much any language. Bad programmers write bad code in any language. Average programmers who are trying really benefit from the discipline imposed by some of the heavy duty general purpose languages like C++.

So, I don't think "standard Perl" is likely to be a crippled Perl. It would be nice for use strict; use warnings; to be default behaviour (for script, but not for one-liners) to make it harder for "bad programmers" to write bad code. Perl should continue to make easy things easy (and quick) - hard things are likely to be hard no matter how you do it.

Perl is Huffman encoded by design.
  • Comment on Re: TMTOWTDI... and most of them are wrong

Replies are listed 'Best First'.
Re^2: TMTOWTDI... and most of them are wrong
by jhourcle (Prior) on Jun 27, 2005 at 02:31 UTC
    I think Perl loses a lot of its advantage when you a start writing large chunks of code with it.

    From my experience, length has nothing to do with things, for the most part -- any large chunk of code is just an assemblage of small chunks of code. Of course, because you can do so much with so little, some people may try to use techniques that they would use for throw away scripts for larger programs.

    Larger programs take a different mindset on the programmer's part -- making sure that you choose effective variable, subroutine and package names; adequate comments and documentation; etc. I don't think the language plays as much as a factor as the programmer in these sorts of situations.

    From my experience, the main issues that I have with Perl are when assumptions are made, that you may need to supress -- like autovivication, or that a scalar can hold a number, string or reference, or that the first argument to print may be a filehandle.indirect object syntax with print

    I've never found that I couldn't work around any of the problems that I've had, but there are times when you're writing something, and things don't behave as you expected (this tends to happen more with non-core modules -- I've lost way too much time redoing large chunks of the serializer in SOAP::Lite so that it behaves how I prefer it to work.)

    In times like this, I have yet to find that I couldn't work around the issues, but it can be a time suck, as you sift through documentation, websites, the code, etc. -- this is the time when I find I lose any advantages.

    A few times, I've had to change my logic to more closely mesh with the modules that I'm using, or otherwise rewrite large chunks of it, but I've never had to give up and move to a completely different language. (well, for some web-based stuff, I'll use JavaScript, too, or use PL/SQL for Oracle stored procedures, but that's been because of how I thought about the problem, not because I tried to do it in Perl, and failed).

    Update: I realized I probably shouldn't have singled out SOAP::Lite in the above example, as the reason I had to rework the serializer was to get it to work with a Java toolkit... so in a way, it was actually Java's fault that the Perl wasn't working.

    Update: revdiablo reminded me that technically, print doesn't take a filehandle as an arg -- it's a different calling syntax. So I'll complain about indirect object syntax in general.