Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Perl Programming

Perl6 for Mortals 224

Posted by michael from the laziness-impatience-and-hubris dept.
horos1 writes: "Hey all, I just ran across an article over at O'Reilly - Perl 6: Not Just For Damians which covers a lot of the negative commentary posted by slashdot on perl6 'featureitis'. Very interesting read, and IMO makes a hell of a lot of sense."
This discussion has been archived. No new comments can be posted.

Perl6 for Mortals More

Perl6 for Mortals

Comments Filter:

  • Where is... (Score:4, Funny)

    by BiggestPOS ( 139071 ) on Thursday November 01, 2001 @07:51AM (#2506341) Homepage
    Perl6 for IMmortals. Highlander edition. I mean, I think it would take me a few hundred years to really understand Perl, which wouldn't be so bad if I was gonna live forever. :)
  • A good article, and I hope that it accomplishes one thing: that people are willing to give Perl 6 an honest chance before burying it with arguments regarding syntaxis or "it's nothing new". I for one am anxious to see how Perl 6 will feel and how the differences will make my life easier.If it doesn't then I still got 5 waiting patiently to see me return to my senses :)
    • I wish I could get more anxious about it. I was a neophyte and advocate at the 4->5 transition, but alot has changed since then.

      use whine qw(toobusy twokids codetooscarylookin);
      Perhaps the lights are just too bright in the new perl world. Especially for the dimmer bulbs among perl lovers, like me. heh. All-nighters are getting harder and harder to pull, even to learn new fun cool Good Stuff (tm).

      But more power to 'em. I just hope it's not some respectability thing thats drivin' this.

  • Perl 6 is the way forward. (Score:5, Insightful)

    by Anton Anatopopov ( 529711 ) on Thursday November 01, 2001 @08:07AM (#2506360)
    Why is it that people dislike change (read: progress) so much ? Its not like anyone ever said 'perl is perfect - leave it just the way it is'. So why all the sad faces when Larry tries to improve on what is already a great language ?

    If you don't like a particular feature of the language don't use it. After all, the motto of perl is 'there's more than one way to do it'.

    It seems to me that we should be praising the perl developers for perl6, not criticizing them. And I bet most of the moaners and whiners never wrote a line of open source code in their lives.

    • Re:Perl 6 is the way forward. (Score:2, Flamebait)

      by Anonymous Coward

      Why is it that people dislike change (read: progress) so much ? Its not like anyone ever said 'perl is perfect - leave it just the way it is'. So why all the sad faces when Larry tries to improve on what is already a great language ?

      Because the people who like progress are already programming with better languages than Perl; the Perl users are the old guard (or the initiates).

      • I agree, and strongly. Bolting functional features, and elisp is not a functional language IMHO (look at Haskell instead for example), onto perl looks silly. As for some of the syntatic sugar, such as that "hyper" operator, why bother? I use perl, I've even used perl professionally as the only language on a large website project, and for programming in the large it sucks. Give me Java, which is no longer bloated and slow, any day if I have to do programming involving distributed systems, message oriented middleware, or any of the integration work a project always ends up needing.
    • If you don't like a particular feature of the language don't use it.

      It must be super to live in a world where you never have to maintain somebody else's code!

    • Why is it that people dislike change (read: progress) so much ?


      Why is it that people who want to change things inevitably choose the label 'progressive'? ;-)


      Perl isn't perfect, nor ever was. But that doesn't mean that any change is a good change. Not to say those developing Perl have made mistakes before... I'm not that bold... but let's just say that indirect object syntax was a rather dubious feature. :-) And prototypes are... well... broken. Pseudo-hashes really could have been done a lot better. Going way back, was making $a and $b special variables for the benefit of sort() really a good idea?



      If you don't like a particular feature of the language don't use it.

      Some of the changes you can indeed ignore... and most Perl people are pretty tolerant both features they don't use and ambiguity in their conceptual model of the language. You don't have to fully understand Perl to use it effectively... which is good, because very few people understand it fully.


      Some of the changes you can ignore at the cost of some effort. The dot-operator nonsense falls into this category. Yes, they're fixing something that ain't broken, and trying to appeal to the sensibilities of people from other languages at the expense of veteran Perl hackers. But Conway has a good point. In Perl 6, you can redefine operators. This means you can have your -> and . operators back to 'normal' without much effort.


      Of course, if you thought tie() made things hard to read, this and the Unicode support could wind up producing not only different dialects, but different languages. But that's another story.


      After all, the motto of perl is 'there's more than one way to do it'


      That motto should properly end, '...except when there isn't.' Perl presently has reliable destructors, but circular references are the responsibility of the programmer, and may produce a memory leak if you're not careful. Soon (if all goes well), circular references will be garbage collected, but we'll lose reliable destructors. Either way, not everyone was going to be happy.


      Pardon me for cutting this short, but I have to get back to work. Suffice it to say, there are good reasons to be excited, but many of people's concerns are legitimate too. There is both opportunity and danger in change.



      And I bet most of the moaners and whiners never wrote a line of open source code in their lives


      Would their arguments be less valid if they hadn't? Would they be more valid if they had? This is argument ad hominem, and makes no interesting point.

  • It's not only the Perl6 code examples which look scary, most Perl code that uses advanced/obscure features already does. I am a Perl coder, but I have a hard time reading much Perl5 code out there. Perl6 seems to make things worse.

    The bottom line is that Perl is simply not the right tool for general programming purposes. I only use Perl as what it was originally intended to be - a "practical extraction and report generation language" that excels at scanning and computing huge amounts of text, as an integrated, improved replacement of the classical shell/sed/awk/grep etc. toolchain. Perl code can be readable and maintainable if it's written in C style and deliberately excludes the more esoteric features of the language. For anything else, and any "serious" - i.e. complex - programming, pick C/C++ or Python. It is no contradiction for me to concede this and still be a Perl afficionado.

    • Re:Messing things up or using Perl for what it fit (Score:5, Insightful)

      by elflord ( 9269 ) on Thursday November 01, 2001 @09:07AM (#2506464) Homepage
      The bottom line is that Perl is simply not the right tool for general programming purposes.

      Says who ? If you don't use it for "general programming purposes", you're not in much of a position to make such a judgement.

      Perl code can be readable and maintainable if it's written in C style and deliberately excludes the more esoteric features of the language.

      It's disingenious to call the OO support in perl a "more esoteric feature" of the language -- nearly all the modules use it. If you use the modules, you're not really using a "C-style" any more, because you're using perl OO code.

      For anything else, and any "serious" - i.e. complex - programming, pick C/C++ or Python.

      You're getting bogged down in false dichotomies, and arbitrary/absurd classifications. What if you want to write a shortish (~1000 lines) program that leverages an existing module , and the program isn't a drop-in shellscript replacement ? And what if there's no such module for python ?

      • I ended up with this job because it is interesting and challenging. It's a fairly major application - we sell it for some pretty serious dough.

        Anyhow - OO in Perl sucks. It's inelegant and not terribly efficient. End of discussion. No public, private, protected variables. Poor performance on inheritance and polymorphism. Should I go on? Sure, the modules use OO programming, but only a very simple subset of all the powerful concepts a real OO implementation will provide.

        Furthermore, perl has virtually no typing. The code is rarely readable, escpecially the code written by the so-called perl gurus which use all kinds of funky constructs and features that don't translate over to another language.

        The $_ variable itself is a good reason to boycott perl.

        Overall, can you do stuff like "synchronized int counter" in perl? Even the threading is not production quality. (That would have made non-blocking sockets much easier)

        However, perl has one gem. A true gem, that is a super-gun that will annihilate almost everything - it is the eval. Eval used correctly will save you hundreds of line of code. Used badly, it will slow your application to a crawl.

        But why spend lots of hours on rarely run code, when you can use an eval and do the job in an hour?
        • typing is a pain in the ass a lot of the time, I have found. The casts and such get in the way of really expressing what you are doing. This point was made clearly in the discussion of the hyper operator. We are trying to calculate a whole list of values based on other lists of values. Why do we have to explicitly set up loops, and go through each element? Sure it works, but that is just stuff vaguely related to what the program is trying to do: calculate a list of values.

          The semantics of that block of code are obscured by the loop semantics. By replacing it with a single hyper operator, the semantics are much clearer, I think.

          This same thing can be applied to Perl's weak-typing. When we convert back and forth from the types, the semantics are now less clear. Dropping the types allows for the code to be much more readable and understandable since there is less crap that must be filtered out.
        • Anyhow - OO in Perl sucks. It's inelegant and not terribly efficient. End of discussion.
          No public, private, protected variables. Poor performance on inheritance and polymorphism. Should I go on? Sure, the modules use OO programming, but only a very simple subset of all the powerful concepts a real OO implementation will provide.


          OO in Perl was a bolt-on, so it's not surprising that many of the features you claim it lacks were later bolted on. "use fields", for example allows you to have private member variables (just prefix the variable with an underscore). Likewise there are ways to produce private functions: declare an anonymous sub with my; it's even faster than OO.

          Polymorphism in Perl5 is O(n) with respect to the inheritance tree depth, so it has the potential of being slow, agreed. None the less, I've never found OO-constructs to be the bottle-neck. (Ever use Devel::DProf?)

          Furthermore, perl has virtually no typing.


          Once again, the bolting on approach.

          my FooObj $obj = new FooObj...;

          When used with the "use fields" and "use base" directives is fully type-case. In fact, I find myself using this for non-oo methods to enforce type-casing on hashtables (such as from database requests which would otherwise have NO type-casting in ANY language). It is the idea that you can use your knowledge of how the device works to minimize programming time (Such as w/ database queries), that perl's power shines.


          The code is rarely readable, escpecially the code written by the so-called perl gurus which use all kinds of funky constructs and features that don't translate over to another language.


          Yes, it makes for more cryptic code on occasion. But that's just part of the learning curve. Did you ever get confused by:

          struct my_struct_t (*my_func_ptr[20])(struct my_arg1_t arg1, int arg2);

          When you work out the context it makes sence. The complexity is just a by-product of the adopted parsing conventions. Java tried to alleviate much of these syntactic line-noise, but it had the benifit of hind-sight. Java already has this garbage "bolted on" in subsequent versions:

          BaseObj obj = new BaseObj() {
          public run() { ... }
          };

          Now C# has the advantage of hind-sight. But guess what, the next great feature will make even C# look occasionally awkward in version 3.0. That's what's great about evolution - you have all these wierd things like an appendix lingering around, and get to fuddle over what their original uses were. :)

          In any case, one of perl's design goals has always been (and continues to be in perl6) huffman encoding of the syntax. Meaning easy things shouldn't require a whole hell of a lot of typing.. Java NEVER valued that. You can't just type a one line program. Even a simple (and VERY common) for loop requires:

          Enumeration list = obj.createEnum();
          try {
          while ( list.hasMoreElements() ) {
          MyFooType obj = (MyFooType)list.nextElement();
          ...
          }
          } catch ( InvalidIteratorException e ) { .. }

          But here's the catch... If you don't like the obscurity of say:
          for my $idx ( 1 .. 20 ) { ... }

          Then you can write:
          for ( my $idx = 1; $idx The $_ variable itself is a good reason to boycott perl.

          Granted, this was another legacy feature, but is still around because of the huffman encoding. If you're creating a new app and don't like cryptic stuff.. Or better yet, if you're a department and want to make it easy for new developers to join, then you simply utilize "use English" and viola, you have
          "$ARG". No fuss, no fetter. (Though this doesn't work well in MT environments as I've found). But if you're not squeamish, then you can go the opposite route.. $_ was designed as the "default", and thus can be excluded in most uses. Thus

          #!/usr/bin/perl
          use IO::File;
          $fh = new IO::File $ARGV[0];
          while( $ARG = $fh->getline() ) {
          $ARG =~ s/x/y/g;
          print $ARGV;
          }

          can be replaced by:
          #!/usr/bin/perl
          use IO::File;
          $fh = new IO::File $ARGV[0];
          while( $_ = $fh->getline() ) {
          s/x/y/g; # default $_
          print;
          }

          can be replaced by:
          while() { s/x/y/g; print; }

          can be replaced by:
          %> perl -n -e 's/x/y/g; print;'

          can be replaced by:

          %> perl -p -e 'tr/x/y/'

          can be replaced by:
          %> perl -p -e 'y/x/y/'

          If you find yourself typing the first entry thousands of times for simple shell-scripts, you too would understand the power of the last statement. Once you've used the last statement enough times to memorize it, it's very hard NOT to use these features in your larger programs. Therein lies the problem. Most developers don't "use English" because they don't have to. Much like most java developers don't use javadoc comments (even though it's trivial to do so). Programmers are inherently lazy.. And that's a good thing (tm).

          Overall, can you do stuff like "synchronized int counter" in perl? Even the threading is not production quality. (That would have made non-blocking sockets much easier)


          Not sure what you mean by sync int counter. In the highly volitile MT library you can just lock any variable to synchronize it.. That's the equivalent of:

          synchronized (foo) { ... }
          in java. So no loss there. Additionally if you want non-blocking sockets in java, forget it.. It's not even an option. In perl, on the other hand, you have the full use of the non-portable ioctl and fcntl. What's more, you have "unix-select". Which is an awsome power to behold within servers.

          A java-threaded instant messenger (via IBM benchmarks) crawled to a halt after some number of users had connected. The extra memory requirements for each thread were insane for such a simple task as IO multiplexing. select-based servers, on the other hand only have the overhead of one additional file handle. Granted threading approaches are insanely easy to understand and maintain, but they're not benifitial to performance (since the unix-select model could simply have multiple workers bidding for the same collection of file-handles). In perl, you have the choice to do either. In java, you don't.

          However, perl has one gem. A true gem, that is a super-gun that will annihilate almost everything - it is the eval. Eval used correctly will save you hundreds of line of code. Used badly, it will slow your application to a crawl.


          More generally, this is a feature of any late-bound application. Ironically even Visual Basic (and hense most ASP) is early-bound. Python, Ruby, Lisp, and many others fall into this category. There are many unfortunate consequences of this design scheme, however. Most notably much compile-time-checking and provability of code. Further most concepts of object-oriented optimizations go out the window. Even perl6 which will be compiled will still be late-bound (It's just too useful).

          • Your post was really good, but I object to:
            Granted, this was another legacy feature, but is still around because of the huffman encoding.

            The huffman coding consideration hasn't gone away - therefore I don't see why $_ is legacy. It is an intuitive, human-centric way of recognizing focus. Which of the following is more intuitive:
            1. Wash, wax and vacuum each car in the lot.
            2. For each car CAR in the lot, wash CAR, wax CAR and vacuum CAR.
            I don't see how (1) is more "cryptic" than (2). Anyone who objects to $_ ought to also object to having a current directory in his shell. If I type 'ls', isn't that cryptic? I'm not specifying which directory to ls.

            I find $_ clean and elegant, especially when it's used implicitly. It removes the visual noise of variable names that didn't matter anyway.

            And by the same token, I am pleased with the unary '.' operator as described in the article. I really don't like typing '$self->{ whatever }'; it's more repetitive noise.
      • elflord wrote:
        If you don't use it for "general programming purposes", you're not in much of a position to make such a judgement.
        Who says I didn't? I tried and decided that others languages fit that purpose better.
        It's disingenious to call the OO support in perl a "more esoteric feature" of the language
        Who says I referred to OO support as an "esoteric feature"? While I think that other languages are more fun to use for OO, the "esoteric features" in Perl I meant is everything that makes Perl syntax terse, obfuscated and hardly readable for everyone but the original programmer. The Perl6 code snippets I saw don't exactly seem to improve that situation.

        Perl allows coding styles so different that two Perl programs may look as if they were written in entirely different languages. Perl6 seems to further this balkanization. This is why I consider Perl the wrong tool for large projects involving many programmers. (Imagine a Mozilla, Emacs or KDE written in Perl - shudder...)

        • Who says I referred to OO support as an "esoteric feature"?

          Using OO is not "programming in a C style". I extrapolated, perhaps incorrectly.

          This is why I consider Perl the wrong tool for large projects involving many programmers.

          But not all projects are "large" and involve many programmers. I agree that Perl wouldn't be the best choice for something like KDE. But for me, Perl works nicely for small programs (note emphasis: the use of the word "program" implies the task at hand can't easily be solved by shellscript or sed !) It's also handy for writing a throwaway prorotype prior to coding something in a "ral" programming language.

    • "as an integrated, improved replacement of the classical shell/sed/awk/grep etc. toolchain"

      Agreed, that's very true in some situations. I don't want to reinvent the wheel when the sed faq ( http://www.dbnet.ece.ntua.gr/~george/sed/sedfaq.tx t ) answers this so well:

      6.5. When should I ignore sed and use Awk or Perl instead?

      If you can write the same script in Awk or Perl and do it in less
      time, then use Perl or Awk. There's no reason to spend an hour
      writing and debugging a sed script if you can do it in Perl in 10
      minutes (assuming that you know Perl already) and if the processing
      time or memory use is not a factor. Don't hunt pheasants with a .22
      if you have a shotgun at your side . . . unless you simply enjoy
      the challenge!

      Specifically, if you need to:

      - heavily comment what your scripts do. Use GNU sed, awk, or perl.
      - do case insensitive searching. Use gsed302, sedmod, awk or perl.
      - count fields (words) in a line. Use awk.
      - count lines in a block or objects in a file. Use awk.
      - check lengths of strings or do math operations. Use awk or perl.
      - handle very long lines or need very large buffers. Use gsed or perl.
      - handle binary data (control characters). Use perl (binmode).
      - loop through an array or list. Use awk or perl.
      - test for file existence, filesize, or fileage. Use perl or shell.
      - treat each paragraph as a line. Use awk.
      - indicate /alternate|options/ in regexes. Use gsed, awk or perl.
      - use syntax like \xNN to match hex codes. Use perl.
      - use (nested (regexes)) with backreferences. Use perl.

      Perl lovers: I know that perl can do everything awk can do, but
      please don't write me to complain. Why heft a shotgun when a .45
      will do? As we all know, "There is more than one way to do it."

    • Re:Messing things up or using Perl for what it fit (Score:4, Insightful)

      by mikosullivan ( 320993 ) <miko AT idocs DOT com> on Thursday November 01, 2001 @12:18PM (#2507232)
      most Perl code that uses advanced/obscure features already does

      I'm preparing a presentation on Perl for my coworkers right now and I address this issue. It's my position that Perl's reputation for ugliness "comes mostly from fancy-pants Perl hackers showing off their obfuscation skills."

      I use an actual example of code that someone used to "prove" that Perl is ugly:

      #!usr/local/bin/perl
      #
      $_ = <STDIN>;
      chomp;
      s/(^|\ )([a-z])/\1\U\2/g;
      print "$_ \n";
      exit;
      Actually, that's just lousy coding. The following code, which does the same thing, is much better:
      #!usr/local/bin/perl -wT
      use strict;

      # grab a line from STDIN, chomp off the EOL
      my $input = <STDIN>;
      chomp $input;

      # change first letter to uppercase
      $input =~ s/(^|\ )([a-z])/$1\U$2/g;

      # output it
      print $input, "\n";
      In answer to the inevitable question "why is it better?", two reasons. First, it uses warnings, strictures and tainting which strongly channel the programmer towards writing robust, secure code. Second, by using well-named variables and comments, it's clear what the program does and how it does it.

      Perl does provide the freedom to write lousy code, perhaps even more so than other languages, and many programmers use that freedom. That's one of the side-effects of freedom: people will make choices you disagree with.

      There is a movement afoot in the Perl culture to shun bad programming ... that's also how freedom works: if enough people don't like something, social pressure reduces it. For example, if the author of the exmple above were to post the code in comp.lang.perl.misc [google.com] asking for help, he/she wouldn't get much help beyond "use strict and warnings" because those techniques are regarded as essential to any Perl programming and people won't help you if you don't help yourself (again, that's how freedom works).

      IMHO, Perl is the language for "general programming purposes". Don't let some lousy coding throw you off on this point.

      • <HUMOR>

        #!/usr/local/bin/perl7

        # grab a line from STDIN, without the EOL
        input = raw_input()

        # change first letter to uppercase
        input = input[0].upper() + input[1:]

        # output it
        print input

        OR:
        input = raw_input()
        print input[0].upper() + input[1:]

        </HUMOR>

        I think most mortals will prefer Perl 7, despite its revolutionary syntatic/semantic changes :)
      • #!/usr/bin/perl -wTn
        print ucfirst($_);
        exit;

  • Perl sucks (Score:2, Troll)

    by Anonymous Coward
    I think perl as a language sucks like a vacuum cleaner.

    Why? Because I've tried and tried in the past to write some small programs in perl. Each time it was a hassle to get aquinted with the stupid syntaxis. Forgot a $ sign here, did something wrong with a list there. The end result in each case was something horrible that couldn't be maintained after a few months of leaving it alone. And I don't believe it's me. People see me as a very experienced C++ developer and even give credit for the way I write perl code. But the fact remains that I can't read my own perl code after not touching it for two weeks.

    I'll never, ever write perl code again. IMO for fast admin like stuff people should use {ba,k,c}sh, sed, awk and expr.
    • I've tried and tried in the past to write some small programs in perl. Each time it was a hassle to get aquinted with the stupid syntaxis

      So, what you're saying is, that you couldn't write a script without learning the language, and thus you don't like it?

      Well, so what? I don't like C. So I don't write C. Big deal. I don't go on about the way I think managed code (decent garbage collection for example) is nice, and that C forces you to cover your own memory space, and if I make a tiny mistake it'll leak and eventually slow/crash my machine.. instead I use something I do like.

      I know this is /., and looking for a constructive comment is like searching for the one piece of hay in a big stack of needles.. but please.. live and let live..
      • Because expressing legitimate criticism is valid, and part of a constructive improvement process.

        I personally think Perl is a dead end, but if it weren't criticism could have helped it.
    • People see me as a very experienced C++ developer

      Then you're no doubt familiar with the concept of a language that lets you shoot yourself in the foot (-; I'm sorry that Perl didn't work for you. But a lot of other people find that it works very nicely. The syntax is quite ugly, but it's not a show-stopping misfeature. Those familiar with the syntax can read it without that much difficulty. I use C++ and often come back to perl after a long break and don't have much trouble picking it up again.

      IMO for fast admin like stuff people should use {ba,k,c}sh, sed, awk and expr.

      These languages aren't substantially nicer. Try doing anything nontrivial in any of them (except perhaps awk) and you'll have a truly hideous beast on your hands.

    • I think perl as a language sucks like a vacuum cleaner.

      Why? Because I've tried and tried in the past to write some small programs in perl. Each time it was a hassle to get aquinted with the stupid syntaxis.


      Let me preface my response with this: Since I started programming I've learned/used Applesoft BASIC, 6502 Assembly, Pascal, QuickBASIC, x86 assembly, C++, Java, and Perl. Never once was a language intuitively easy enough for me to jump write in a code without learning the language first. However, out of all of them Perl was the easiest to learn and put into real use.

      Really, your post and most similar posts seem to read like "I don't know how to use it so it sucks."

      That's kind of ridiculous. Not long after I learned Perl I got interested in learning Python. I guess in a way I expected that I'd pick it up quickly and it would be banging out code in a day or two. This wasn't the case. I gave up on it (at least for the time being) because I didn't want to spend the time to learn it. However, I at least learned enough about it to be impressed with it and put it on my list of languages that I'd like to learn at some point.

      I find Perl much easier to use than C++, but just because you know C++ doesn't mean you'll automatically be able to program in Perl without learning it.

      As far as posts about the ugliness of _some_ people's Perl code, I think there is a reasonable explanation for this. Perl is easy enough to use that people are able to write code in the language before they've really come to understand the pitfalls involved with writing unclear code.

      Also, addressing comments about being able to accomplish different things in more than one way: Yes, it's true that this can lead to harder to read code. This also makes it easier to write _clearer_ code if used properly.

      Well-written Perl code is extremely easy to read. There may be a lot of ugly Perl code out there, but it doesn't mean that clear, well-written Perl scripts are impossible.
      • That's kind of ridiculous. Not long after I learned Perl I got interested in learning Python. I guess in a way I expected that I'd pick it up quickly and it would be banging out code in a day or two. This wasn't the case. I gave up on it (at least for the time being) because I didn't want to spend the time to learn it.

        That's extremely weird, as Python can be picked up in about 2 hours, by complete programming newbies, who know no language (unless you consider Visual Basic a language).

        I found the Python tutorial to be quite awful at teaching Python, and maybe, when I have some time on my hands, I'll write a better one.

        In any case, knowing quite a bit about Perl, and quite a lot about Python, its learning experience, and how it compares to other languages, I must recommend Python and recommend against any important usage of Perl.

        Sure, if you somehow find it easy to use (all people I know, and myself can't even imagine how this is possible), use it for some simple text parsing scripts. But if you want anything you want to ever read again, use Python.
    • I totally agree with your criticism.
      However, I've tried the *sh languages, and I have to recommend Python. Its not like Perl.
      Its very very elegant, and I can almost guarantee you, that you will love it, at least if you try to be openminded about syntatic indentation, which is something everyone grows to love over time :)

  • Perl 6 for Perl 5-ers (Score:5, Informative)

    by mir ( 106753 ) <mirod@xmltwig.com> on Thursday November 01, 2001 @08:53AM (#2506438) Homepage

    One of the coolest things about the Perl 6 development is that it leads to lots of improvements available right here, right now with Perl 5.

    Attribute [cpan.org] for example have been incorporated in perl 5.7.2, and a whole unch of new modules [cpan.org] by Damian and others use them in tons of creative ways.

    I am not sure this would have been done without the Perl 6 process. It forced the whole community to re-examine the language, take a step back and think of new ways to improve it. This would have been much more difficult if we had not had license to do it freely under the Perl 6 RFC process. This is the kind of things that keep a community alive and creative.

    And BTW Perl 6 will still let you write quick'n dirty one-liners, and the first goal of the design of the interpretor is Speed (Larry mentionned "and it'has to be fast" about 25 times in 60 seconds in his last State of the Onion [perl.com]0.

  • What's wrong with you people? (Score:5, Insightful)

    by shaka ( 13165 ) on Thursday November 01, 2001 @09:12AM (#2506485)
    I know I'm going to be modded to hell for this, but here goes:
    What's wrong with the people posting to /. in this day and age? It wasn't that long ago that it actually was worthwhile to read people's comments here, but nowadays I mostly see my "threshold" going up, up, and not wanting to stop. I saw this article and thought "Wow! A nice, positive article about Perl 6 on my fave site /. which uses Perl", you know. And then I read all these pointless, silly and sometimes even mean comments about how baaaaaad Perl 6 is, and how everything Larry has done is wrong and screw Perl 'cause it's a sucky language, I use {Java|Python|New mega-exciting superlanguage} instead.
    So do that.
    Personally, I think Perl is the "Nike-language": Just Do It. When I want to code in C or C++ (I like C, I'm not too happy about C++) I always have to do all these things first. Look at man pages all the time, worry about casts and memory allocation and what not. When I do something in Perl I just do it. I find the modules, write some code, and it works.
    And that's worth a lot.

    • Re:What's wrong with you people? (MOD PARENT UP) (Score:5, Insightful)

      by Christianfreak ( 100697 ) on Thursday November 01, 2001 @11:38AM (#2507032) Homepage Journal

      I agree. And the funny thing is that perl is not at all hard. When I first started serious programming I tried learning C and I dabbled in Java but I just couldn't *get* it. And then I discovered Perl and everything was right with the world.

      Don't like the crazy symbols? Don't use them! Other than the $ @ % you can get by without using things like $_. And I'm sure with perl6 you won't have to use $^ if you don't want to. There's more than one way to do it. AND to one guy stated in an earlier comment that he couldn't read his own Perl after just two weeks -- don't whine comment your code.

      A lot of people use and love perl, there's no reason to flame it even if you don't

    • Personally, I think Perl is the "Nike-language": Just Do It. When I want to code in C or C++ (I like C, I'm not too happy about C++) I always have to do all these things first.

      What makes my threshhold go up is people who think that there are only three or four languages in the world. Perl is more productive than C or Java. Wow! And my Camry has better pickup than dump truck.

      Is Perl more productive than Python? Lisp? Ruby? SmallTalk? Maybe it is. Maybe it isn't. Those languages at least a better point of comparison.

      It's a big world out there! C, Perl and Java are not your only choices.

      • For a lot of business computing, C, Perl, Java, and VB pretty much ARE your only choices.

        Companies invest lots of time and effort in an environment; they don't just hop from one language to another as the fads change.

        Thats why a lot of people still care about Perl, because they like it, and have invested a lot of time and code in it.

        Why change all that and move to Python/Ruby/Lisp/etc...?
      • Hrrmm. Well, I don't "think that there are only three or four languages in the world". In fact, I'm happy to code Python, Lisp (Scheme), Java, C, Perl and some other languages as well (hell, I even tested Prolog back when I was 12-13).
        That was not the issue. I can't get things done fast in Python, Scheme or Java either, but I do get things done fast in Perl. Just Do It.
    • I agree that the average quality of posts has declined. However, this is a side effect of the massively increased user base. I look on the bright side, which is that slashdot propogates certain beneficial ideas to a much larger audience. Inevitably, more time is spent simply correcting the misconceptions (and, unfortunately, refusal to read) of newbies. But it's worth it. I sometimes think a small quiz should be required before posting. The quiz would be geared to the material at hand, and would include hyperlinks to places where you'd find the answers. As for the people who have switched to shiny new languages with less mindshare, I suppose they feel a bit of anxiety at the massive scope and momentum of Perl 6, just as we feel a bit of anxiety when Microsoft hypes .NET or whatever. It's quite possible that Perl 6 will negate whatever advantages $superlanguage once offered, just as Microsoft is nibbling away at the advantages Unix offers.

  • Pros and Cons of Perl (Score:2, Interesting)

    by lkaos ( 187507 )
    To me, perl seems to have so many good points but at the same time seems to have a bunch of bad points.

    The great thing about perl is that you can do anything in it. It also provides a good mechanism to abstract high-level concepts from the end-developer. The fact that it also provides low-level interfaces allows for one of the most flexible languages that I've ever used.

    The problem with perl is that it is bloated. IMHO, a good programming language is simply, yet eligant. There should not be five ways to do something. There should also not be duplicate operators that accomplish the same purpose.

    Operator overloading is one of those dangerous areas of C++ because it used improperly, it can create code that is unbelievably mantainable. Unless strict standards are followed when developing perl, perl is almost doomed to be horribly unmaintainable.

    Even with all my criticisms, I would still use perl any day to lisp... It's great for little scripts. Perl6 seems to be moving in a general direction to make code even more unmaintainable.
    • Now there I have to disagree with you. I think that the changes in Perl as we move to Perl 6 are going to make it easier to write clearer code. The new function definition semantics for instance will move all the code for dealing with function arguments out of the body of the function, so someone reading/maintaining that code can concentrate on the meat. Replacing $self->foo with .foo is nice too. The emphasis gets shifted to the things that are important.

      Of course, many of these tools will allow criminal bastards who shouldn't be allowed anywhere near a production codebase to perpetrate monstrosities. But they can do that already in any language they choose to pollute. And Larry has been making noises about allowing folks to write their own versions of things like strict, which, when taken hand in hand with the more accessible parser should mean that sites that want to can enforce their own rules for coding.

      If you want to be good, Perl 6 is going to let you be better.

    • One of the biggest reasons I find Perl so useful is precisely because there often are five, or more, ways to do something. TMTOWTDI (There's More Than One Way To Do It) is, to my mind, one of the biggest programming productivity enhancers ever. Simple and elegant is fine if you want to spend your time thinking like a computer. Five ways to do something is great when you want the computer to Do What You Mean.

      Maybe Perl is bloated in that it's big, but what does that matter in practical terms? If performance is what you're concerned about, it's usually cheaper to throw more hardware at a problem than to throw more programmer-hours at it; I say, let programmers write in a language they can be productive in. (Obviously there are exceptions if you're building an application where performance is truly paramount, but in my experience performance is merely one consideration, along with issues like solution complexity in a given language, maintainability, portability, and so on.)

      Perl definitely does give you enough rope to hang yourself with. But if you think that something like operator overloading is dangerous, then don't use it! Just because my car can go 140+ mph doesn't mean I mash the pedal to the floor every day, but it's nice to have the capability when I'm out in the middle of Montana and want to push the envelope.

      In my experience, code maintainability has a lot more to do with the practices and discipline of the programmer than with the language they use. It's possible to create convoluted, hairy, unmaintainable code in any language. (I won't say the converse is true, because there is always Intercal...)

  • Perl is like Juggling (Score:5, Insightful)

    by dannyspanner ( 135912 ) on Thursday November 01, 2001 @09:38AM (#2506556) Homepage
    It took me ages to learn to juggle but now I can keep three things up in the air instead of two. It took me a fair ammount of time to grok Perl but now it lets me be very productive. Complicated things take time to learn, so don't write it off just because it doesn't look (or think) like C/C++/C#/Java. To the people saying "use C/C++/Java for proper apps" it's like saying "don't build your house from wood, you must use bricks".
    • It's more like saying: "Don't build your house with sod." Perl is an abomination. I shouldn't have to consult tide charts to find out if the sun is shining.

      Oh, and it took me about 40 minutes to learn to juggle.
    • Heh! That seems to imply that C++ isn't something that takes a fair amount of time to grok in order to be productive!

      (I know you didn't mean that, but the implication is funny.)

      It hilites one of the truths of life. The languages you know are simple, straightforward and obvious while all those languages you don't are wildly confusing and wierd.

  • Fear Not: Pick and Choose (Score:5, Insightful)

    by airuck ( 300354 ) on Thursday November 01, 2001 @10:28AM (#2506712)
    Why all the griping? Am I also supposed to feel inadequate or frightened because I've not mastered Perl 5 and am now faced with Perl 6? Afraid not. I may not be a Perl wizard, but my scripts do some heavy lifting.

    As a biologist turned bioinformatics programmer, I find Perl to be a fantastic tool. Bioinformatics Perl = string processing and glue. My Perl scripts move LARGE numbers of sequences in and out of Postgres DBs, feed and clean up after a variety of open source tools (written in C, python, tcl, and perl), serve up web based tools, and all within a clustered linux environment.

    I openly admit to cracking the camel book and visiting cpan on a regular basis. I do this not because I'm a slave to a complex language, but because I find Perl and its associated community to be a rich source of tools. I harvest what I need to get the job done now.

  • Useless quote of the day (Score:3, Funny)

    by Sapien__ ( 156881 ) on Thursday November 01, 2001 @10:33AM (#2506732)
    And, on rereading Damian's example with an eye to what hasn't changed, the whole thing still looks like Perl.

    Yeah, well, duh...

  • Hammers, nails, etc (Score:4, Insightful)

    by Balinares ( 316703 ) on Thursday November 01, 2001 @12:19PM (#2507244)
    Just wondering...

    Programming languages are tools. Trying to nail a screw with a hammer and trying to write a CGI script in Java are two instances of the same problem (the latter generally of managerial origin, it would seem *sigh*). Right?

    So. Is Perl6 the same darn fine '(formatted text -> data) && (data -> formatted text)' tool Perl5 is? If so, then it's great. Don't whine, you'll get used to the new syntax. (Note, I'm not a Perl junkie, so my appreciation of its aim as a tool may be inaccurate, I'll admit)

    I'd be more concerned if the aim of the language itself shifted significantly. The mention of Python in the quote, "Yeah, and Perl 5 doesn't give us anything that a Universal Turing Machine, Intercal, or Python don't." makes me pause. Python in the same bag as Intercal. Hmm. Resentment? I hope Perl6 isn't trying to compete with Python out of resentment. That'd be stupid -- both languages rock, each in its own ecological niche (which don't seem to overlap much, BTW).

    Bottom line: if Perl6 is a better (faster, more flexible, etc) tool for the same task, well, the new syntax is no big deal. However, if it starts undergoing featuritis just to compete with different tools, I'd start to worry.

    Anyone care to enlighten a total Perl novice?

    • Re:Hammers, nails, etc (Score:3, Insightful)

      by EvlG ( 24576 )
      I think that comment in the text of the article was intended more to point out that there really isn't a whole lot to add to a language besides syntactic sugar, since perl is already Turing-complete.

      I don't think the author intended for a comparison out of resentment.

      As for featuritis, what's wrong with looking at other languages, seeing what they did right (and wrong), and then learning from it? It's how the body of knowledge grows. Perl borrows bits from other places and perl-ifies it. Then at some point in the future, other languages borrow from what perl did, and improve upon it. The result is a cycle of improvement and innovation.

      I love programming in Perl for many reasons; one of which is the lingustic aspects Larry designed into the language. If more features are added to make my use of perl more efficient, I'm all for it!
      • The Turing-Compeleteness argument is a very silly irrelevant one. FUD, so-to-speak.

        Turing-completeness has NOTHING to do with the issue at hand, of creating a language serving ease of development, eliminating error-proneness to shorten the development cycle, etc.
        Almost all languages out there are Turing complete. The most obvious example is a Turing Machine.

        To say "Perl5 didn't give us anything that Turing Machines didn't" is basically saying Perl's features do not exceed a Turing Machine's in terms of getting things done.
        • You miss the point of what the author is trying to say.

          Of course the Turing-complete argument is FUD. However, if you read the article, you see that it was used in a sarcastic sort of tone.

          I think the author was trying to say that new features will give new ways of doing things, not necessarily new things to do. That's a subtle distinction, but it is one worth making for many of the people that tend to complain about "mere syntactic sugar."

          That's what the author, and many other people working on many other languages, are trying to say. OF COURSE the language can theoretically do anything; itis Turing-complete afterall. How effective it is at expressing a given operation in a reasonable amount of time is another matter. That is what Perl's syntax (especially the new additions in Perl 6), and that is what I think the author was trying to say.

  • Filehandles (Score:4, Insightful)

    by Erik Hensema ( 12898 ) on Thursday November 01, 2001 @12:22PM (#2507263) Homepage

    Are they're going to implement filehandles properly? I want to be able to do:

    my $fh = open $file or die;

    Because right now implementing a recursive function which opens a file is... odd... wrong... ugly:

    Example snipped because of lameness filter.

    (from man perlfunc, the open function)

    Having to pass a string as a filehandle and manually incrementing it is just plain silly. Filehandles shouldn't be global. IMHO they just should be a reference or something similar.

    Furthermore, the use of '$| = 1' to autoflush a stream is ugly. Why not 'autoflush($handle)' or something similar?

    I do know about the FileHandle module. This module is proof that regular filehandles are too ugly. You shouldn't need the FileHandle module to be able to do basic filehandle stuff.

    • Re:Filehandles (Score:4, Interesting)

      by Piers Cawley ( 1193 ) on Thursday November 01, 2001 @12:39PM (#2507395) Homepage
      What version of perl are you using? In 5.6.0 and later


      open my $fh, $file or die;


      will give you a nice shiny, lexically scoped filehandle.


      And yeah, $| = 1 is a historical PITA. It's going away in Perl 6 though. Hurrah!

    • Re:Filehandles (Score:2, Interesting)

      by mrpotato ( 97715 )
      my $fh = open $file or die;

      That works well with Perl 5.6...

      '$| = 1' to autoflush a stream is ugly

      Then use the full variable name? $| is in fact a shortcut for $OUTPUT_AUTOFLUSH (just make sure you Use English;)

      I really don't see what you are complaining about, all you want to do is there, right here right now.

      • I guess my docs and knowledge are out of date then ;-) Glad to hear they fixed it already.

        On the autoflush: it's ugly to do:

        select HANDLE
        $| = 1;

        I want to be able to do

        autoflush HANDLE;
    • I do know about the FileHandle module. This module is proof that regular filehandles are too ugly. You shouldn't need the FileHandle module to be able to do basic filehandle stuff.

      Well, I think you'll be dissapointed then. I don't think file-IO is going to be part of the core. Meaning I think you might have to include at least one module to get any IO to work.

      Given that, FileHandle is outdated. Use
      my $fh = new IO::File "...", ".."

      Even if you hate OO, its the most feature complete of the file-types.. Not to mention it's the only one that evolves with file-enhancements.

      TypeGlobs are going away I think, so *FH won't be applicable anymore (though perl5 compatabilty mode will deal with it properly). Likewise with the global symbols which aren't thread-safe I don't think.

      -Michael

  • Comment from a real PERL programmer (Score:3, Insightful)

    by LunaticLeo ( 3949 ) on Thursday November 01, 2001 @12:41PM (#2507414) Homepage
    I program large complex programs in perl. I use OO Perl all the time. I write small once off scripts in perl as well.

    Some of this Perl 6 stuff scares me too. Mainly because I think perl can be abused to write bad code. I am thinking stuff that is REALLY obtuse. I've seen code with $|++. Which is stupid. Because if $| == 1, then the code doesn't do anything and the inverse $|-- fails to achieve your purpose when $| == 2. STDOUT->autoflush(1) is the clear way to write it.

    Just because dumb-ass "programmers" CAN write obscure code in perl, doesn't invalidate the value of Perl. Any language with expressive power is vulnerable to having "Obfusicate-X" contestants write programs in that language. A wise quote: "Fortran programmers can write Fortran in any language".

    Perl 6 is looking to be the exact opposite of LISP. In my view, LISP has little or no syntax; just Lots of Incessant Silly Parenthesis. Well it looks like perl 6 is going to be nothing else but syntax.

    This might be valid perl6:

    %b{@a} := ^-x @a ^_ '.c';
    I like perl by this might be to much for me.

    Of course the real reason I use perl is two fold; it's expressive power (unlike bondage and discipline languages) and CPAN (the killer feature).When I look at other languages like python or ruby, I look for their CPAN equivalent. Right now their is none, but maybe soon.

    BTW, for the JAVA fans out there the following url [sun.com]is the same code as:

    $/ = undef; $wc{$_}++ for split(/\W+/,); print($_, " = ", $wc{$_}) for sort keys %wc;

    48 lines (took out comments and empty lines) versus 3.

    BTW, This is as obfusicated as my code gets. I did it mostly for brevity.

    • You wrote:

      $/ = undef; $wc{$_}++ for split(/\W+/,); print($_, " = ", $wc{$_}) for sort keys %wc;

      and got rid of 45 lines of java code.

      AWW, MAN! How am I supposed to make any MONEY with perl if I get paid by the number of LINES OF CODE I write???? I have a LOC quota, you know.

      (Just kidding)

      --jeff

  • perl motto summararizes its fatal weakness (Score:4, Insightful)

    by kleene_star ( 232097 ) on Thursday November 01, 2001 @12:53PM (#2507487)
    Have you noticed how many times the perl fans reiterate "isn't this cool, but of course you don't need to use it." "There's >1 way to do it."

    Now I like functional programming as much as the next guy, but "There's >1 way to do it" is actually a symptom of the problem with perl. Yeah, I don't have to use the object-oriented triple-ended-pipe closure-thingeys so handily represented by $_?:^, but the last guy who worked on the code I'm trying to maintain now, did. So I'm stuck using (or dealing with) them whether I want to or not. When I interview a programmer I can't just ask, "Do you know Perl?". I have to probe just what subset s/he knows.

    In my ideal programming language, there is exactly one program that solves each problem. That limits my search space while I'm trying to find it.
    • But note that this is a problem of documentation.

      If the programmer didn't correctly document his algorithms, it is unreasonable for you to decipher them.

      This is a problem shared by all languages; without proper documentation, a piece of software is much more difficult to figure out.

      • There's hardly any Perl code readable without commentary.

        There's hardly any Python code unreadable without commentary.

        Python code can usually be shorter than any Perl equivalent.

        If you investigate the consequences of these sentences, you can produce the facts:

        Perl is inefficient at representing code as a language (Getting the thing done)

        Perl is ineffective at having working code convey the code's concepts to the next human reader (Getting the thing across to the next programmer)

        This makes Python more efficient for thedevelopment process, and more effective for maintainability.
        The fact Python is more easily learnt by newbies, and has strong typing and other more powerful semantics, is an added bonus.

    • that you can't institute coding standards, then yeah, stay away from perl. And from C, C++, java, lisp, etc etc etc. Unreadable code can be written in any language. But I say fix the real problem; gather your developers and put into place a set of coding standards and hold code reviews.

      Perl isn't your problem, your organization is--try fixing it before you worry about features in language X.

      And remember to use the language element that when done right makes any code readable: the comment.
    • In my ideal programming language, there is exactly one program that solves each problem. That limits my search space while I'm trying to find it.


      This already exists.. It's called CPAN. :) All kidding aside, I disagree that perl's crypticly compacted syntax is a search-space problem. What you are instead searching for is to update someone else's solution-space. Imagine, for a moment that you're company decided to use some 3'rd party java module (such as a logger). Now what if one day you found that it had a bug.. Or worse yet, you needed a new feature that wasn't implemented. Well, if it's closed source, you contact the vendor and keep your fingers crossed. Unfortunately if it's a bug, you might have a headache trying to find out what happened, where the bug originated, and even if the 3'rd party module was at fault.

      In open-source (as with almost all perl), or when the 3'rd party was via another developer within the company, you at least have the option to trace through the code. Now most developers have to make some assumptions. These assumptions SHOULD be documented somewhere, but even when they are, the location of that documentation isn't always known. Perl again comes to the rescue with pod-documentation (similar to javadoc inlined documentation). You can put the description right next to the relavent regions, and at least in the relevant files. But, as we all know, developers are lazy and thus the added work of thourough documentation (in both java and perl) is lacking.

      Now if you're proficient with the perl-code basics, then you have all the tools that you need to trace through a perl-module (or executable). Perl is highly context-sensative (name-spaces can be dynamically changed), arguably you have your work cut out for you (when it happens that sufficient documentation on such subtlties were not noted). The same can be said about java and package-spaces. There are tricks and tweaks a developer can do to perform efficient "magic" which is incomprehensible to an outsider (at least at first glance).

      But to alleviate your problems, we have the debugger, which allows not only real-time inspection of the context, but thanks to the magic of late-binding, you can modify the context on the fly (importing new symbols, redefining old ones, etc, adding ad-hoc test routines). Java / C can't do this.

      So yes, it is "harder" to debug / update someone else's code when they programmed above your level of proficiency. But if they were indeed more sophisticated developers they'd document their "magic". And if you weren't proficient enough to at least utilize the analitical tools at your disposal, then what are you doing modifying someone else's code?

      -Michael
  • Perl is a richer, more sophisticated language than those so-called heavyweights like C++/Java ( both of which I have used extensively. ) The 'funky' syntax, and 'strange' punctuation allow for more expressive and concise forms than in languages that force one way of saying something.
    I use compound words all the time in speech, or even the occational big, or high falutin' word. Used with some judgement, using a wider vocabulary in discourse ( or in code if you are using a language that supports it ) makes you easier to understand. If someone doesn't know what you are talking about let them look it up.
    • A rich vocabulary increases compactness. A richer syntax increases compactness.
      While Perl offers a rich vocabulary, how is its syntax any richer, than a language that would allow representing anything Perl does, but forcing some specific readable representation?

      Example: Is a language supporting: if a b;
      and if b a; as two ways of saying the SAME thing, is it any richer than a language that supports if a b; alone?

      The so-called richness of Perl syntax is merely duplicated syntax, increasing parsers' complexity (including the human parser), and do not compact the code.

      In fact, the much stricter Python language can usually represent Perl code with fewer characters/lines, and still remain a lot more readable, etc.
      This is because Python has a very rich, yet small syntax (probably richer than Perl's, as shown by the fact its more compact, usually), and a very rich vocabulary (libraries/modules/etc).

  • Perl going the way of C++ (Score:3, Interesting)

    by mikec ( 7785 ) on Thursday November 01, 2001 @04:08PM (#2508803)
    Perl6 suffers from the same problem that C++ has had over the years. In both cases, people tend to look at lots of tiny examples and come up with cool ideas to make things "nicer" for that example. The problem with this approach is that there are a very, very large number of cool ideas that make one situation or another "nicer." So lots of them get stirred into the mix. Adding two or three hundred cool new features to each version makes for a very complicated language after a few versions, especially when they interact and get used in unexpected ways. This is exactly the problem that C++ has had over the years, and the reason that other languages (Java, etc.) have gained in market share.

    So, here's what will happen. Perl gurus will follow along. After all, Perl6 isn't that much more complicated that Perl5. Incrementally speaking, it's not too bad. But more and more newcomers will go with something a lot simpler: Python, Ruby, or the Next Big Thing. Why? First, if you look at Perl6 from ground zero, it is extremely daunting. The Perl6 Camel book is going to come in three volumes if it tries to maintain the same sort of coverage. Second, the design of a lot of Perl6 will be inexplicable except to people who know Perl5 and understand the history of the language. Finally, new programmers, especially good ones, want to really understand their tools from the inside out. They don't take kindly to the idea that they should learn 10% of the language, start using it, and catch up with the experts in a few years. So, over time, interest in Perl will dwindle. The old timers will retire or go into management, the newbies will be using something a lot simpler and more elegant. By the time Perl8 or Perl9 roll out, no one will care.
    • Perhaps someone should write a truely object oriented, cross platform, scripting language derived from some other cool languages and actually call it "The Next Big Thing". I can just see it now "The Next Big Thing for Dummies", "Learn The Next Big Thing in 24 hours". Of course it wouldn't be long before M$ released "The Next Big Thing.NET"
    • I agree that C++ is certainly a painfully complex language, but I don't agree that it became that way because of overzealousness to add features for every little thing.

      If you look at the current state of the language, I see few features you could remove without compromising its fundamental goals of being C-compatible and object-oriented. References and operator overloading are the only ones that come to mind.

      IMHO, Java is simpler than C++ only because of all the C baggage that was removed. Its removal of const and multiple inheritance did not make the language simpler, only more foolproof (multiple inheritance does have a frustrating tendency to unexpectedly blow up in your face, but it's no more difficult to understand than interfaces). And nobody who has ever used templates argues that C++ would be better without them (mmm, templates). I think it's really the legacy baggage of C++, and the need to have "two languages in one" that made it such a mess.

      Anyway, complexity is certainly a major problem for C++, as its target audience is large team projects. But as for Perl, I think extra features don't harm its niche of small to medium-sized projects where maintainance isn't a major issue. And unlike other languages, it doesn't need to be mastered completely to be made effective use of, since there is more than one way to do it.

      I learned enough Perl to write useful scripts in a weekend. Its huge number of features actually made things easier, because I was able to easily apply my knowledge of C and awk (which didn't help me at all when I learned Lisp, for example). I don't see Perl's death on the horizon (C++ isn't becoming unpopular anytime soon, either).

  • All Perl (<= 5) scripts I've seen, *including* ones for text processing, and heavy regular expression usage, were smaller to MUCH smaller as Python scripts, which were a lot more elegant and easily readable. Is there a reason to use Perl (6), other than Turing completeness that I find in Turing machines as well, over Python?

Slashdot Top Deals

Real Users know your home telephone number.

Close