Forgot your password?
typodupeerror
Perl Programming

Perl Turns 25 263

Posted by Soulskill
from the added-support-for-rental-cars dept.
Several readers sent word that the Perl programming language turned 25 today. In his commemorative post at the Perl Foundation's website, mdk wrote, "So what does the future hold for Perl? Well I don't have a crystal ball but I cannot see the language fading from usage in the next quarter century, the truth of the matter is that even though there are languages that can do some of the things that Perl does, some of them do some things better, others do things Perl wasn't designed for, there is no language that has been designed to do the things that Perl is very good at doing. No language in the current scripting languages seems to have the flexibility, maturity and extensibility of Perl. The main power of Perl has always been its ability to quickly adapt, and be adapted, to suit purposes. ... The greatest challenges we will face for Perl is a shifting end-user base that will become more reliant on devices that are feature focused but crippled in application choice, the rise in mobile devices will continue and Perl will need to evolve to work with that. A better challenge for us to face would be the integration with electronically aware, and connected devices and systems, the apocryphal internet of things, in this Perl could be a powerful tool. I also believe that the more we see a divergence of language uses in the other scripting languages the more they will face issues in their core designs, issues that Perl avoids due to its malleable nature, what some believe is the crippling factor for Perl is likely to be its saving grace as it has the power and flexibility to cope with the shifting goalposts of an increasingly technologically reliant world."
This discussion has been archived. No new comments can be posted.

Perl Turns 25

Comments Filter:
  • Recent convert (Score:5, Interesting)

    by DCFusor (1763438) on Tuesday December 18, 2012 @03:28PM (#42328835) Homepage
    I recently became a fan of perl as my goals changed towards things it excels at - sticking together big other functionalities easily.
    • Re:Recent convert (Score:5, Insightful)

      by vlm (69642) on Tuesday December 18, 2012 @03:30PM (#42328869)

      AKA I'm a CPAN programmer not a Perl programmer. Works for me! Wake me when another language has the depth of CPAN. I might switch, then. Maybe.

      • Re:Recent convert (Score:5, Interesting)

        by DCFusor (1763438) on Tuesday December 18, 2012 @03:39PM (#42329003) Homepage
        Yup. Me too. It's just awesome to be able to get stuff from CPAN with about the right "chunkiness" and documentation vs say trying to learn some huge monolithic library. Better yet - those cool modules often "accidnetally" document other things, like say, Gnuplot, so you can roll your own specialized versions easier than trying to understand the "native language" dox written by someone who didn't code in some other language, then translated by another non-programmer. And I can't believe I got first post.
      • Re: (Score:2, Informative)

        by Anonymous Coward

        there is, it is called "CPAN+Gems+PyPi+Maven" ... amazing stuff out there if you're agnostic. Rubyists, in particular, seem to write amazing tools. Chef and Vagrant are two of my faves.

        However, I still don't recommend you use Node.js.

        • Re: (Score:3, Informative)

          by Anonymous Coward

          RubyGems is very expansive, but the quality of the modules that rubyists write is atrocious. The language is such a poor performer (spend 30% of the time doing GC, oh but don't worry better GC is in the next version, oh wait the next version, nm the next version), and the whole Rails community is built around absurd bloat: nobody seems to care/notice that their gems are poorly implemented for anything other than scraping something together.

        • CPAN has some of the highest quality compared to other repos (especially compared to javascript), it has test stats for dependencies, quick access to view the source without downloading, documentation and just about any other info you want. Pypi is great for finding things and installing but supporting information is lacking. Maven I can't comment on but Ruby suffers from the same sort of problems that other brogrammer languages suffering from (more variety in quality and a lack of documentation).
      • When considering a new project, I look first for libraries I want to use. CPAN has the most commonly used ones, but get a little obscure, and you're out of luck. For instance, CPAN has OpenGL, but not OpenSceneGraph. Then I find out what languages interface with them. It quickly narrows down until maybe one language is left, and most often that language is C/C++. Sometimes no languages are left, and then I have to decide if I want to go through the pain of linking multiple languages, or search for more

        • by skids (119237)

          Been waiting for Perl 6 for years now.

          There's enough of it working now to start toying around. The "NativeCall" interface got to draft standard status recently, and works, mostly. Lack of many C ("native") data types will be a point of pain for some time to come, though.

        • by jandrese (485)
          Perl 6 has the worst case of second system effect I've ever seen. They said at the outset that Perl 6 was going to be a major rewrite, but I never expected to still be using Perl 5 in 2013. It's a shame too because Perl has some definite rough edges, especially with complex data types and writing object oriented code. The complex data type thing is a big one, most programmers really struggle with how to define a hash of references to arrays or anything like that, and the syntax for accessing or updating
          • Re:libraries first (Score:4, Insightful)

            by FacePlant (19134) on Tuesday December 18, 2012 @07:34PM (#42331733)

            Are you using 5.16.2?
            Are you using Moose/Mouse/Moo for complex data types and/or object oriented programming.?

            Perl is alive and well.

            If you think of 5 as being a syntax identifier, then you might be pleased to see all of the development that's gone on since Perl 4 gave way to Perl 5.

            It sounds a little bit like you're complaining that Perl's development has not followed your idea of semantic version numbering.

      • CPAN is great but it's not always wise to be too dependant on it for everything. Especially if you provide scripts to others to use and want minimal hassle.
    • Re: (Score:3, Interesting)

      It's a great language actually. Instead of people moaning that people write shit perl (like any other language), why no learn to do it right and enjoy it. CPAN of course is a tremendous resource but even on it's own it's not hard at all to write or understand and on the off chance you see something you don't understand, perldoc will almost certainly cover and well because that's another thing that Perl has (along with Python) that many languages lack and that is exceptional documentation.
  • then Perl will be for a while too. Happy Birthday Perl. Your prime was memorable, and now you can just ask those kids to get off your lawn.
    • Unix is still very dependant on Perl. People can sit there and say no one uses it anymore but they don't realise how many things depend on it. Hell even popular OS X programs use perl which is why Apple's version of Perl can be out of date. In some instances language changes would break the scripts the particular version of OS X.
  • Perl Turns 25... (Score:5, Insightful)

    by Frosty Piss (770223) * on Tuesday December 18, 2012 @03:33PM (#42328905)

    ...And is sexier than ever.

  • I used it. Once. (Score:5, Interesting)

    by Tsingi (870990) <graham.rick@[ ]il.com ['gma' in gap]> on Tuesday December 18, 2012 @03:38PM (#42328979)

    I wrote an app in Perl once. It was the only language that I could get to reliably connect to MSSQL from Linux.

    It was fun to write, but I go back and look at the code now and it looks like Greek.

    On the upside it's been running for over 5 years and having no problems at all.

    • Re: (Score:3, Interesting)

      by Hatta (162192)

      Sounds like Perl. Powerful, accessible to a complete beginner, reliable, and practically unmodifiable once written.

      • Some people say Perl is a write-only language that is slowly losing importance in comparison to Python. [tiobe.com] It seems that it is the CPAN library that is important, not the Perl language.
      • practically unmodifiable once written

        Come on, it's not that bad if you split everything up appropriately into well named subroutines and such like.

        • by CaptSlaq (1491233)

          practically unmodifiable once written

          Come on, it's not that bad if you split everything up appropriately into well named subroutines and such like.

          This is one of the most important things anyone approaching perl needs to grok. Perl gives you enough rope to hang yourself, that's why I use it. Lack of awareness of that has bitten me in the backside enough that I've learned this lesson.

      • by readin (838620) on Tuesday December 18, 2012 @05:02PM (#42330139)
        What I found in using Perl was that no two Perl programmers could read each others code. Much of the expressiveness and versatility that people talk about comes at the expense of a huge amount of syntax and the ability of the language to assume values (like $_ instead of requiring them to be explicit). What happens in practice is people learn a subset of syntax which is large enough to do what they need to do and it often isn't the same subset that someone else learned. And when reading someone else's code, it can be very difficult to look things up because it often isn't even clear what the syntax is (in part because so much gets assumed).

        When the boss hands me a flat text file with 50,000 lines in some random format that needs to be parsed and loaded into the database, I dust off my Perl book and write a short application to read each line and spit out SQL. I don't need the safety of Java or the byte processing of C. I don't need to handle every possible exception that could be thrown when opening a file. I don't need a GUI. I just need to open a file, read a line of text, use some regular expressions, do some tokenizing, and spit out more text into a separate file. Perl is fantastic for that. But I don't find much other use for Perl.
        • by bill_mcgonigle (4333) * on Tuesday December 18, 2012 @05:13PM (#42330269) Homepage Journal

          What I found in using Perl was that no two Perl programmers could read each others code.

          That's silly. I'm just a medium-grade Perl jockey and I read and understand other projects' code. I find bugs and submit patches.

          Perl doesn't force good style on you, but if you follow the guides of Perl Best Practices and check yourslelf with Perl Critic [cpan.org] you're going to produce code that most programmers can follow.

          Some people aren't comfortable with 'enough rope to hang yourself', which is fine. Others think that forced indentation is the answer to good code style (I think semantic analysis is better). There are lots of options.

    • by arielCo (995647)

      That's partly because it was your first (or one of your few) programs in Perl. You likely made things more complicated than needed for lack of knowledge and experience.
      I've always said that Perl is a good fit for programmers who can recall dozens of "idioms" (memes), and keep their understanding of its unique semantics fresh. Things like keys %{ {map {$_=>1} @list} } [perlmonks.org] (implementing unique(@list)) and internalizing that every expression is ultimately evaluated as a list. Some are silly, but there's littl

  • by Wansu (846) on Tuesday December 18, 2012 @03:39PM (#42328993)

    Perl where are you tonight
    how can I now run scripts on my own
    I searched the filesystem
    even looked in slash sbin
    They rm'd the sym link and pffft you wuz gone

  • by Runesabre (732910) on Tuesday December 18, 2012 @03:40PM (#42329009) Homepage

    I remember when Perl was the workhouse behind all custom web server development. One of the few times I had "fun" writing code. Such a cryptic looking language that made perfect sense the moments you are writing it and completely alien days later.

    • by Frequency Domain (601421) on Tuesday December 18, 2012 @03:42PM (#42329047)
      It always struck me as one of the poster children of "write-only" languages, right up there with APL.
      • by Anonymous Coward on Tuesday December 18, 2012 @03:48PM (#42329127)

        Perl is write-only in the hands of stupid hacks. Oh wait, that's any language.

      • That's the case with most object oriented languages these days. OO Perl is the worse. It's not just the language, it's the culture.

        Instead of a simple A() calls B() and C() to do work, where B() and C() do real work, I've seen code where B() and C() are almost empty, relying on strange language contructs known only to true believers and their IDEs.
        • relying on strange language contructs known only to true believers and their IDEs.

          Heathen. True Believers in perl don't use IDEs, regex generators, auto-intent, or syntax highlighters, and we don't receive our golden "@" medallions until we can determine the output of feeding our code through "perl -wt" in our heads.

           

          • by skids (119237)

            I think you're right on most of that but syntax highlighters. We use them because we like to try to break and improve them, since we know it's almost impossible to get them 100% right, given pragmas and whatnot.

      • by Kymermosst (33885)

        Bad coders can write bad code in any language.

        There is nothing that requires that Perl code be write-only.

        • by Coryoth (254751)

          There is nothing that requires that Perl code be write-only.

          No, there isn't ... but there's nothing that encourages it either. And perl has a elatively high congitive load in terms of all the many subtle features and idioms that you need to keep track of. If you're reading code that only uses a subset of idioms and features that you're comfortable with it's fine, but it is relatively easy to end up outside your comfort zone with other people's code unless you are deeply invested in the language. In this way it is much like C++.

          In practice however a lot of Perl's rep

  • Why perl? (Score:5, Interesting)

    by Frequency Domain (601421) on Tuesday December 18, 2012 @03:40PM (#42329015)

    What can perl do that newer languages such as python and ruby can't do, and do more readably/maintainably?

    I understand about path dependence and sunk costs, which is why we still have COBOL, I'm asking about language features that are unique to perl.

    • Re:Why perl? (Score:5, Interesting)

      by miletus (552448) on Tuesday December 18, 2012 @03:53PM (#42329205)

      How much of readability is the fault of the language vs the developer? Cut-n-paste coding is the bane of any language.

      As a perl programmer, I sometimes ask, what can python or ruby do that perl can't?

      MVC web framework like Rails or Django? Catalyst, Mojolicious, etc. PSGI has taken a lot of pain out of deployment of apps.

      Good, modern object system? Moose.

      GUI stuff? There's Wx and Qt interfaces.

      OK, embedding C looks much easier in python, but I've never needed that.

      If all the CPAN stuff would just work with other languages, I'd be more willing to switch. Javascript seems to be where all the web stuff is heading anyway.

      • Re:Why perl? (Score:4, Interesting)

        by preaction (1526109) on Tuesday December 18, 2012 @04:06PM (#42329395)

        Surprisingly, embedding C++ in Perl is easier than embedding C. Of course, that's just my opinion, there aren't a lot of docs on the C++ topic, and I am one of the few Perl programmers who actually enjoy C++.

        The Parrot VM http://www.parrot.org/ [parrot.org] is supposed to be for dynamic languages what the CLR and JVM are for Microsoft and Java respectively. If it ever makes it to prime time, then you could use your CPAN module with Ruby, or vice-versa.

      • by Hatta (162192)

        If all the CPAN stuff would just work with other languages

        Couldn't it? Would it be possible, at least in theory, to compile CPAN modules to a binary format that could be linked to other programming languages? Is there any reason that CPAN couldn't be turned into something more like a shared library?

        • Re:Why perl? (Score:4, Informative)

          by bill_mcgonigle (4333) * on Tuesday December 18, 2012 @05:03PM (#42330143) Homepage Journal

          Couldn't it? Would it be possible, at least in theory, to compile CPAN modules to a binary format that could be linked to other programming languages? Is there any reason that CPAN couldn't be turned into something more like a shared library?

          Yes, this is part of the perl6 effort. There are ports of all the other scripting languages to the ParrotVM being written for perl6. Once that's worked out you can write a module in Ruby, run it from Python - it doesn't matter. Use the best tool for the job (which is often the one you're most comfortable with).

      • Re: (Score:2, Informative)

        by Anonymous Coward

        How much of readability is the fault of the language vs the developer?

        When the language's answer to new features is to add a new operator instead of a library/function call, it's the fault of the the language. That Perl now has nearly 300 operators, that is a language smell.

        OK, embedding C looks much easier in python, but I've never needed that.

        Understatement of a lifetime. I've had to expose C++ apis to Perl, Python, Java & C#. Hands down the worst, by several orders of magnitude, was Perl. XS should be held in front of the world for judgement as the worst abomination and abuse of the C preprocessor known to development kind. That XS is he

        • by skids (119237)

          That Perl now has nearly 300 operators, that is a language smell.

          We'll have to agree to disagree there. It may take a while to learn them, especially their precedence, but once you do, leveraging that precedence gives you a lot more power and expressivity than functions.

          Which is why Perl6 is making it a one-liner to locally define new operators within a lexical scope.

      • Having written in perl for the past 20 years, I started out trying to find something that perl can do that ruby can't (ruby is the only comparable language I have in my toolbelt). After a few minutes, I decided that, for the work that I do, the single feature that perl has that ruby doesn't is that I'm very familiar with how to write perl.

        I've liked some of the things that I was able to do with Ruby on Rails, and could see how having a MVC framework in perl would be useful, but quite frankly, most of the co

    • by Trepidity (597)

      For script-type usages, where I might otherwise have used bash/awk or something, Perl feels like it retains more of the lightweight, quick-to-script aspect. I like autovivification, the implicit $_ variable, etc. They can be used to make unreadable code, but in idiomatic usage they're very nice and not particularly hard to understand.

      I don't really use Perl for "big" applications, though. Mostly for text processing and "glue" between other tools.

      • by gorzek (647352)

        I used to use perl as my "glue" language, too, until I got into python. Python works just as well in most cases, and usually leaves you with much more readable code. People who haven't used python before can usually figure out what some code is doing just by reading it. With perl? Good luck.

        • by Trepidity (597)

          I've used Python for some things, but somehow it just seems clunkier to me. For example, if you want to scan a text-file line-by-line and run some regexes on each line, it's much more explicit in Python: have to explicitly read each line into a variable, hoist some re.compile()s out of the loop if you don't want them being recompiled on each iteration, etc.

          • by gorzek (647352)

            Although it depends on what your memory restrictions are, if you know the file you're reading isn't enormous (that is, bigger than the memory you can spare), it's easier to just yank the whole thing into an array off the bat:

            lines = open('somefile.txt','r').readlines()
            # set up your regex and compile it here
            for l in lines:
            # do your re.search or whatever

            You only have to compile once if you aren't changing the regular expression from line to line.

            I agree that it's more explicit, bu

    • Mostly inertia and a great set of libraries in CPAN.

      There's even a Perl library that will hold your C code, compile it when needed, and make it easy to use.

      Perl just plain works and plays well with others. Compare and contrast that with Java or Smalltalk.
    • Perl's strength is that it's expressive. It's not a language which is easy to learn or which generates heavily optimized code.

      In the demo phase, you're not really worried about performance. The goal is to have something working as quickly as possible, and not worry too much about how fast it runs, or how much memory it takes. Overspec your demo system for the time being (ie - make it really fast and install lots of memory), and once you have a reasonable interface go back and recode it in a simpler language

      • OK, that last paragraphs should read:

        The following line:

        @Files = <c:/Windows/*.exe>

        can be implemented using one of over a dozen possible library calls in C++, but is builtin in perl. You don't have to look up the library call interface specific to your system.

      • by dotgain (630123)

        Languages which are simple to learn (c++, for example)

        WHAT?

        • by Okian Warrior (537106) on Tuesday December 18, 2012 @05:33PM (#42330531) Homepage Journal

          Languages which are simple to learn (c++, for example)

          WHAT?

          Ahem. "Languages which are simple to learn (c++, for example)".

          Perl has lots more reserved words than c++.
                  (Examples: "say", "not", "and", "open")

          Perl has lots more operators than c++
                  (Example: "//" is an operator in perl. So is "<=>", "+/*", "..", and "eq").
                  (See if you can understand the flip flop [wordpress.com] operator on first reading.)

          Perl has several contexts [perlmonks.org], and the meaning of an operator or function is context dependent.
                  (Example contexts: "scalar", "list", "null", "string")
                  (Example differences: Saying "$i = sort @array" has a completely different meaning from "@i = sort @array")

          Perl distinguishes a variable from its value.
                  (Example: $i = 12; followed by $i = "twelve". The same variable, points to one of two values in memory. C++ binds the variable to the memory location, perl does not. Programmers have trouble wrapping their mind around this.)

          Perl references are not pointers (but have some similarities). C++ programmers have a hard time with this also.

          Perl has all the overloading and class syntax found in c++.

          Perl doesn't have a precompiler.

    • by jgrahn (181062)

      What can perl do that newer languages such as python and ruby can't do, and do more readably/maintainably?

      Don't know Ruby, but Perl is distinctly better than Python for writing text filters with regexes and stuff -- the things you used to use sed and awk for. More readable code, faster execution.

      (On the other hand, some people still stick with awk.)

      • by gorzek (647352)

        I've not found python's mechanism for using regexes to be any less powerful than perl's. It is inherently object-oriented, so it works rather differently. I've used both facilities and have never been unable to do what I wanted in either language.

        Also note that perl is only faster with regexes if they are static (that is, known at compilation time.) Python does them faster if they aren't known until runtime.

    • Re:Why perl? (Score:5, Informative)

      by narcc (412956) on Tuesday December 18, 2012 @05:00PM (#42330097) Journal

      No one cares about ruby. It's a dying little niche language. It had a good run, but that's all in the past now. To me, ruby never really felt complete. (It didn't even get a step method to its range class until 1.8.7) There was always some absurd limitation you had to work around or some needlessly obscure feature or rule to learn before you can do something obvious in just about every other language (What's up with things like this? 10.times { |i| puts i } madness!)

      Python, well, python enjoys some popularity, but I just don't think it's likely to hang-on like perl. Probably because of the whitespace issue and the big 2.x 3.x split. Perl filled a particular niche really well, and was a good fill-in in a few others (remember when it powered your website's counter and guestbook?). Python never really found a home as there isn't any particular area where it really stands out -- or is even arguably a good fit. You'll find a lot of "it can be used for ..." but not a lot of "It's really great for ..."

      As for readability, well, I can't say that it's a terribly readable language. I get that everyone is forced to indent their code (apparently, the whole world forgot about pretty printers) but that's not all there is to readability. Neither is readability all there is to maintainability. (You could even argue that the whitespace rules actually hurt readability, as it takes away otherwise helpful cues.)

      Let's not forget that you don't have to write illegible perl code. Really, it's not required!

      COBOL's staying power was due to much more than "sunk costs". It was, and still remains [infosecisland.com], the best tool for the job. You'll find tons of failed COBOL to Java conversion projects from the late 1990's as a testament to that. It's really hard to beat COBOL on performance and even harder to find a language that's as easy to read and maintain. (Not that there isn't lots of room for improvement. It was designed to be readable, however, and it shows.) In short: It's easy to learn, easy to read and maintain, and lightning fast.

      Anyhow, to answer your question: Manipulating strings is a strength that is not shared by many other languages to any significant degree, and this makes it a great fit for a broad range of applications to which python and ruby just aren't as well suited. (Working with strings in python 2.x is terrible -- even just outputting them can be troublesome due to the bizarre default behavior of 'print'. This has improved, but not much, in 3.x) I would argue that PHP is popular due in no small part to that as well (I've always thought of it as a simpler version of perl. A related note: PHP was originally written in perl.)

    • There is more than one way to do it.

      Perl can pretty much integrate anything with anything. Hardware or Software.

      It is the Duct tape of the interwebs.

      It is a swiss army chainsaw.

      And yes,it can be nearly impossible to decipher what the code is doing, Oh, but the moment of enlightenment you have when you do figure out an obscure but elegant piece of code.

      That, my friend, is "Why Perl?".

      -Xanthos

    • by mcgrew (92797) *

      What can perl do that newer languages such as python and ruby can't do?

      Have a Texan beer named after it?

  • Let the obfuscated congratulations begin.
  • by perl6geek (1867146) on Tuesday December 18, 2012 @03:50PM (#42329151)
  • the rise in mobile devices will continue and Perl will need to evolve to work with that

    Does this mean Perl is considering to jump on to the tablet bandwagon? I cannot even imagine what that would mean for a programming language. All I do know is that we have lost many a great seamen to the sirens of tabletia. Shipwrecks, shipwrecks everywhere.

  • Perl 6? (Score:4, Insightful)

    by kriston (7886) on Tuesday December 18, 2012 @04:00PM (#42329305) Homepage Journal

    Okay, so let's have a roll call of those of us using Perl 6 in production.

    Hands?

    Anybody?

  • by Animats (122034) on Tuesday December 18, 2012 @04:14PM (#42329487) Homepage
    • Better syntax than Bourne shell scripts.
    • Preinstalled on most servers.
    • Programs from 1998 still run. (Unlike Python, where the Little Tin God keeps making incompatible changes.)
    • The CPAN library has some quality control and maintenance.
    • No vendor can make it go away.
    • Fast regular expression processing.
    • Closures! Although most Perl programmers don't know that.

    The syntax is unreadable, of course. And Perl 6 seems to have been rejected by the market. Still, it's a vast improvement over shell scripts.

    • That, I think is the key to why Perl is still around.

      Shell scripts are quick and easy, they work and play well with others, but they quickly get unmaintainable after a page or two.

      Perl has local variables, real functions, and it also works and plays well with others.

      You really can do 90+% of everything you might want to do in Perl. Add in C code if you need something to be very fast, and you're up to 95+%. Well written Perl is no less readable than any other computer language, and more readable

      • I ask this question in ignorance: what does the much-vaunted CPAN contain within it that has unit tests?

        It is my current belief that any code lacking some sort of proof of correctness is valueless. In many cases it is worse than having no code at all.

        I have strong feelings concerning the promotion of untested or untestable code, but will reserve them until I know whether they're warranted.

        • by chromatic (9471)

          ... what does the much-vaunted CPAN contain within it that has unit tests?

          Any serious distribution on the CPAN has at least a decent test suite in its t/ directory. Everything uploaded to the CPAN gets run through the CPAN Testers [cpantesters.org] service, often within minutes of the upload.

          search.cpan.org has over 3200 results for module names which contain the word "Test".

    • by jgrahn (181062)

      Better syntax than Bourne shell scripts.

      For the old Bourne shell I agree, but IME bash syntax can be distinctly better than Perl for certain tasks -- typically stuff that's rather heavy on glueing other stuff together. And bash is becoming universally available, too.

      • by dbIII (701233)
        I was going to dust off what little I knew about python to do some trivial selection boxes that would set environment variables, but then I just added "zenity" to bash and it did the job very well in a very short script.
    • Re: (Score:3, Insightful)

      by greg1104 (461138)

      Programs from 1998 still run because the language has been stagnant ever since. Python breaks because it actually improves sometimes. "The main power of Perl has always been its ability to quickly adapt"...seriously? Perl 6 has been stuck in R&D hell for a dozen years now [slashdot.org]. Even the Duke Nukem Forever team is starting to feel awkward about how long it's taking.

      • by Mjlner (609829)

        Programs from 1998 still run because the language has been stagnant ever since.

        You really have don't know anything about Perl, do you? To suggest that Perl has been stagnant from 1998 (v. 5.005) until now (v. 5.16.2) is ridiculuous. The difference is immense. That doesn't mean that backwards compatibility needs to break. You just don't know Perl or its evolution.

        Python breaks because it actually improves sometimes. "The main power of Perl has always been its ability to quickly adapt"...seriously? Perl 6 has been stuck in R&D hell for a dozen years now [slashdot.org]. Even the Duke Nukem Forever team is starting to feel awkward about how long it's taking.

        Lessee.... Python 3.0 came out 4 years ago. Still, 2.7 is the one installed by default across the board. Some distros (e.g. latest Red Hat) are still stuck on 2.6. Apparently, most people can do without the improvements in Pyt

  • Personally, I exclusively use Perl to re-factor C++ code with regular expressions.
    It's like a better sed.

  • I like Perl. My company sells software that's primarily written in Perl. It's readable and maintainable because we follow strict coding guidelines, use proper modularization, and have unit tests that make sure our POD documentation is complete and up-to-date.

    That said, a few things about Perl worry me. I think Perl 6 is a distraction; someone should take it out and shoot it. I predict it will eventually be abandoned the way PHP 6 was.

    Also, while CPAN is awesome, inter-module dependencies are insane.

    • That's why there's Mouse [cpan.org]. And if that's still too large for you, there's Moo [cpan.org]. And when even that's still to large, there's Mo [cpan.org]

      And you can select which one has the features you need, without the bits you don't care about ... but they've all got basically the same general API, so you can change it up as needed.

      • And you can select which one has the features you need, without the bits you don't care about

        In theory, yes. In practice, no, because sometimes a CPAN module will insist on one specific module. And woe betide you if you want to mix modules that use different OO bases.

        The mere existence of Moose, Mouse, Moo and Mo that purport to solve the same problem is an indication of a deeper underlying problem.

  • Great plans are great, but how about decent Unicode/utf-8 support first??

    And by decent I mean a single global flip switch to tell the Perl that the script runs in Unicode/utf-8 only environment, all regexes should be Unicode aware, all file and directory names are Unicode, all text files are Unicode and so on and so forth. Well, you know, a switch to tell Perl interpreter that it runs on a system made in 21st century.

    Otherwise, Perl is a great thing. But the bastard Unicode (and locale) support already

In any formula, constants (especially those obtained from handbooks) are to be treated as variables.

Working...