Slashdot Mirror

← Back to Stories (view on slashdot.org)

Perl 5.14 Released

Posted by timothy on from the before-swine-and-with-the-rest dept.

chromatic writes "Pumpking Jesse Vincent has just released Perl 5.14, the latest stable version of the venerable Perl 5 programming language. The list of changes in Perl 5.14 includes several enhancements, including performance tuning, Unicode improvements, and updates to the core libraries and documentation. Perl 5.16 is on track for a release next April."

145 of 187 comments (clear)

  1. Re:What about Perl 6? by nysus · · Score: 4, Funny

    I was just going to say that back in about 2001 someone gave me advice not to learn Perl 5 because a Perl 6 release was imminent.

    --

    ---Technology will liberate us if it doesn't enslave us first.

  2. Re:What about Perl 6? by goombah99 · · Score: 4, Informative

    Perl 6 is out. But it's a diffent language in the same way that python 3 is not like py 2.7

    The thing I really like about perl is it's the shortest oreily pocket reference. it's even shorter than c++. Yet you can do vastly more than python without importing a single lib. that is to say it's surprisingly concise for encompassing such a lot of capabilities in the core language.

    --
    Some drink at the fountain of knowledge. Others just gargle.
  3. The question nobody wants to ask.... by cowboy76Spain · · Score: 3, Funny

    .... does it have any new operator? :-P

    And before you tell, it was just a joke, I know you should now add operators in a minor release.

    --
    Why can't /. have a rich-text editor? Editing your own HTML is so XXth century.
    1. Re:The question nobody wants to ask.... by gman003 · · Score: 3, Interesting

      Actually, I've always thought there should be one more common operator - "===". In floating-point context, it would be "approximately equal to", returning true if the arguments are within 10 times the smallest representable value. That would reduce problems with floating-point comparison. Hell, make it work for integers too - it might be useful in PLCs and stuff.

      In a string context (in Perl, it would have to be something besides ===, but we'll get to that later), it would be "visually equal to" - any characters that are visually equal would be considered equal (useful mainly when using Unicode). So the Cyrillic "e" (0435) would be considered equal to Roman "e" (0065). I'm not sure how to handle complexities like "is the single character 'small a with macron' equal to the sequence 'small a' and 'combining diacritic macron'". We'll need a committee for that, probably. And since Perl uses different operators to determine context, we'd need something else for that. "veq", maybe?

      This would, ideally, not just be a Perl construct. I can think of a lot of higher-level languages that could use that. Python. Ruby. Lua. Stuff like that. Lower-level languages probably would be better off without it - C does not need such an operator.

      Just something I've always felt could be useful to have. Sure, there's probably some library that can do those things, but it would be nice to make things simpler.

    2. Re:The question nobody wants to ask.... by dorward · · Score: 2

      This is version 14 of Perl 5. It is a major release. (Perl 6 is a new language)

    3. Re:The question nobody wants to ask.... by gman003 · · Score: 1

      Huh. Cool. I never played with Ruby much, never saw that.

    4. Re:The question nobody wants to ask.... by elfprince13 · · Score: 2

      This would conflict with "equality without type coercion" in Javascript and PHP.

    5. Re:The question nobody wants to ask.... by formfeed · · Score: 1

      .... does it have any new operator? :-P

      Of course. Not every possible key combination has been used yet.

      With previous versions of perl, a cat could walk over the keyboard and accidentally create valid perl code.
      Now a cat walking over the keyboard will for sure create valid perl code.

    6. Re:The question nobody wants to ask.... by gman003 · · Score: 3, Informative
      That reminded me of "Black Perl":

      BEFOREHAND: close door, each window & exit; wait until time.

      open spellbook, study, read (scan, select, tell us);

      write it, print the hex while each watches,

      reverse its length, write again;

      kill spiders, pop them, chop, split, kill them.

      unlink arms, shift, wait & listen (listening, wait),

      sort the flock (then, warn the "goats" & kill the "sheep");

      kill them, dump qualms, shift moralities,

      values aside, each one;

      die sheep! die to reverse the system

      you accept (reject, respect);

      next step,

      kill the next sacrifice, each sacrifice,

      wait, redo ritual until "all the spirits are pleased";

      do it ("as they say").

      do it(*everyone***must***participate***in***forbidden**s*e*x*).

      return last victim; package body;

      exit crypt (time, times & "half a time") & close it,

      select (quickly) & warn your next victim;

      AFTERWORDS: tell nobody.

      wait, wait until time;

      wait until next year, next decade;

      sleep, sleep, die yourself,

      die at last

      That's actually valid Perl (only Perl 3, though - it breaks in later versions). And yes, I'm aware most of you have already seen it.

    7. Re:The question nobody wants to ask.... by Nutria · · Score: 1, Interesting

      it means you probably shouldn't be writing software that uses floating point.

      Since I'm not a scientist or graphics programmer Floats are as damned useless and destructive as needing pointers to do string manipulations in C.

      BCD should be the default data type for decimal arithmetic.

      --
      "I don't know, therefore Aliens" Wafflebox1
    8. Re:The question nobody wants to ask.... by Eil · · Score: 2

      Er, no it wouldn't because Perl is neither Javascript or Python.

    9. Re:The question nobody wants to ask.... by petermgreen · · Score: 3, Insightful

      The big problem with an approximately equals for floats operator is that it provides no way for the user to specify the acceptable margin of error. So the language designer has to guess a value that they thing is "big enough" to avoid (possibly heavily compounded) rounding errors while not being so big as to cause unwanted matches. IMO that kind of judgement call should be something consciously made by the programmer (and they should be having the releated thought of "should I really be using a floating point type here at all" not something hardcoded into the language.

      Similarly for strings "approximately equals" sounds like a nice idea but it's very hard to define in a robust way. Again probablly not something that should be in the core of a langauge but something provided by a library that can give options on what exactly constitutes approximately equals.

      Finally using === to signify approximately equals seems like a bad idea given that many dynamic languages are using it for something closer to "exactly equals".

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    10. Re:The question nobody wants to ask.... by goombah99 · · Score: 1

      bite_me() if abs($x-$y)> $epsilon;

      $t =~ tr/e/e/;
      eat_me_raw() if $t eq $s;

      --
      Some drink at the fountain of knowledge. Others just gargle.
    11. Re:The question nobody wants to ask.... by VortexCortex · · Score: 3, Interesting

      I somewhat agree, however the floating point implementations SUCK at powers of ten -- you should specify epsilon in terms of powers of two. Hell, even my correct decimal text to float/double parsing function is 8 times more complex than the same in hex Why, even C has a hex float/double literal that goes something like this:
      /[+-]?0x[0-9a-f]+\.?[0-9a-f]*p?[+-]?[0-9a-f]*/i )

      The "p" in there stands for "times Nth power of two" similar to the "e" in decimal floats meaning "times Nth power of ten". eg: 0x123p-8 == 0x1.23

      Note, hex decimal places act like decimal's do eg:
      0x1.23 == (dec) 1 + 35 / 256 == 1.13671875 or (hex) 0x1 + 0x23 / 0x100 == 0x1.23

      Specifying floats in the language of the computer's math (binary representable fractions) allows you to actually use equality properly ;-)

      Some of my languages have the === operator already, similar to JS's exact match, perhaps ~=~ or =~= or "approx" would be better?
      I've thought of adding an "approximate" operator -- esp. for physics simulation & game DSLs.

      Although, what's wrong with specifying your required precision? Define your own epsilon (error factor).

      print "$a is approx $b\n" if ( $a > ($b - $epsilon) && $a < ($b + $epsilon) );

      # Compared to:
      print "$a is approx $b\n" if ( $a approx $b );

      # Oh, great, now we need another obscure magic special variable to contain epsilon...
      # Perhaps       $ë would do? Our English users won't mind using character map...

    12. Re:The question nobody wants to ask.... by kiddygrinder · · Score: 2

      true, but fucking around with that kind of thing between languages is really annoying when you work in both regularly

      --
      This is a joke. I am joking. Joke joke joke.
    13. Re:The question nobody wants to ask.... by Hognoxious · · Score: 1

      Thus exposing your ignorance of how to use floating point numbers.

      Ignorance would be simply testing for equality and wondering why your code sometimes doesn't work. Clearly he's aware of the issue, or he wouldn't have raised it.

      Hardcoding an operator to perform this specific test (which is one particular way to compare for equivalency) is idiotic, and would encourage even more "programming by guessing" than we already have.

      I don't like his idea of having a fixed limit, but why couldn't it be done with a ternary operator?

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    14. Re:The question nobody wants to ask.... by Hognoxious · · Score: 1

      The big problem with an approximately equals for floats operator is that it provides no way for the user to specify the acceptable margin of error.

      Not without using a ternary operator, anyway. If you don't like that idea you could set something akin to an environment variable.

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    15. Re:The question nobody wants to ask.... by sqldr · · Score: 1

      Actually, I've always thought there should be one more common operator - "===". In floating-point context, it would be "approximately equal to", returning true if the arguments are within 10 times the smallest representable value.

      You can already do that in the language. More to the point, why 10 times? That's a bit decimalist isn't it? Shouldn't that be configurable, and if so, surely you would do so via a function. So now we have a function controlling the behaviour of an operator.. yuck! As for unicode, that's just getting speculative about its meaning. Is perl supposed to understand the shape of glyphs now?

      You've probably gathered by now that I'm one of those crazy new-age freaks who dropped perl in 2003 for all but the odd 6-line sed/awk replacement (which is how it started out and did very well at it) for python precisely because of stuff like this that just makes it more and more confusing. Any suggestion like this on the python mailing list would be shot down by the language-nazis long before somebody made a terrible mistake which would have been an awful legacy. They spent 3 years arguing about how to implement ternary operators, and after much debate came to the following conclusion: just use 'if'.

      What you want is a CPAN module. if (wavy($x, $y)) { do something }. OK, so you have to type 5 more characters, but do you honestly spend more time typing than thinking when you're programming? You can be thinking about what you're going to do next whilst you're typing w..a..v..y..

      --
      I wrote my first program at the age of six, and I still can't work out how this website works.
    16. Re:The question nobody wants to ask.... by internettoughguy · · Score: 1

      What about ~ ellipsis =, eg: (1.01 ~0.1= 1.00) == True?

    17. Re:The question nobody wants to ask.... by internettoughguy · · Score: 1

      oops, epsilon not ellipsis.

    18. Re:The question nobody wants to ask.... by maxwell+demon · · Score: 1

      What about a =[ eps ]= b?

      --
      The Tao of math: The numbers you can count are not the real numbers.
    19. Re:The question nobody wants to ask.... by petermgreen · · Score: 1

      why couldn't it be done with a ternary operator?

      It could but imo that wouldn't be all that much of an improvement over writing abs(a-b) tolerance (especially if your language makes abs an operator rather than a function).

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    20. Re:The question nobody wants to ask.... by devent · · Score: 1

      if ( isApproximatelyEqual(10.356, 10.356) ) { }
      if ( isVisuallyEqual('a', 'a') ) { }

      Wow that was easy. Do you have any other brilliant ideas for new operators?

      --
      http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
    21. Re:The question nobody wants to ask.... by mikechant · · Score: 1

      # Compared to:
      print "$a is approx $b\n" if ( $a approx $b );

      # Oh, great, now we need another obscure magic special variable to contain epsilon...
      # Perhaps $Ã would do? Our English users won't mind using character map...

      But why not have something like
      print "$a is approx $b\n" if ( $a approx $b by $epsilon );
      as a pretty intuitive abbreviation of
      print "$a is approx $b\n" if ( $a > ($b - $epsilon) && $a ($b + $epsilon) );

    22. Re:The question nobody wants to ask.... by Saint+Stephen · · Score: 1

      Maybe they could use that juicy GPU to do super fast BCD fast enough!

    23. Re:The question nobody wants to ask.... by Hognoxious · · Score: 1

      I assume eps is the threshold difference. That's "red cunt hair" in which language?

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    24. Re:The question nobody wants to ask.... by maxwell+demon · · Score: 1

      I assume eps is the threshold difference. That's "red cunt hair" in which language?

      "eps" is short for "epsilon", the Greek letter commonly used in mathematics, especially in calculus, to represent a small positive quantity. Therefore I'd say it's "red cunt hair" in the language of mathematics.

      --
      The Tao of math: The numbers you can count are not the real numbers.
    25. Re:The question nobody wants to ask.... by tokul · · Score: 1

      In a string context (in Perl, it would have to be something besides ===, but we'll get to that later), it would be "visually equal to"

      So you want whole database of homonims and database of letters with diacritical marks to be stored inside program execution space. Do you imagine what kind of impact it will have on performance?

    26. Re:The question nobody wants to ask.... by Tom+Christiansen · · Score: 1

      In a string context (in Perl, it would have to be something besides ===, but we'll get to that later), it would be "visually equal to" - any characters that are visually equal would be considered equal (useful mainly when using Unicode). So the Cyrillic "e" (0435) would be considered equal to Roman "e" (0065). I'm not sure how to handle complexities like "is the single character 'small a with macron' equal to the sequence 'small a' and 'combining diacritic macron'". We'll need a committee for that, probably. And since Perl uses different operators to determine context, we'd need something else for that. "veq", maybe?

      You cannot use visual similarities between glyphs that may or may not look similar in one font or another, because there exists no standard that spells out their correspondence.

      In contrast, there does exist a standard that says whether two code points should be considered the same basic character. This is what you get when you compare two strings at the primary collation strength using the Unicode Collation Algorithm. This is perfectly easy to do in Perl, and is extensible to locale tailoring as well.

      To do more than that is to ask to translate 133t$p3@k into normal text. It may have some applications, but it is not as useful as you think.

    27. Re:The question nobody wants to ask.... by petermgreen · · Score: 1

      the thing is it's not that much shorter than

      abs(a-b) < eps

      Is it really worth adding another trinary operator to knock about three characters off an "approximately equals" operation?

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    28. Re:The question nobody wants to ask.... by mr_mischief · · Score: 1

      They have libraries for strings now. There are also arbitrary precision mathematics libraries.

  4. Re:Meh. by Anonymous Coward · · Score: 2, Funny

    Where do I sign up?

  5. Re:What about Perl 6? by Anonymous Coward · · Score: 2, Informative

    No, Perl 6 is not "out". I can't use it on my production servers, because there's no good implementation yet, even after ten years.

    I know there have been a few attempts, but none of them are seriously usable like Perl 5, Python, Ruby, Tcl, or Lua are.

    At least when developing Python 3, the Pythonistas built a production-grade implementation. Even if its adoption hasn't been as fast as was initially hoped, at least those of us who do want to use it can actually use it, and we can do so for serious uses. The same can't be said about Perl 6.

  6. Re:What about Perl 6? by Tacvek · · Score: 4, Informative

    Perl 6 has 140+ different operators! That is absolutely insane. While I support being concise, Perl has far more complexity in the language core than any other language I have ever seen.

    --
    Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
  7. Re:Perl - the COBOL of scripting languages by Anonymous Coward · · Score: 1

    I still see perl getting used a lot - esp. in the financial services industry.

  8. Re:Perl - the COBOL of scripting languages by Anonymous Coward · · Score: 1

    I think the problem is that Larry didn't know what he wanted Perl to be, so he tried to make it everything. But now we have C#/Java for strong type enforcement (for large projects with inexperienced people), Haskell and friends for academics and functional purists, python/javascript/lua/etc. for scripting...Perl just doesn't have a niche anymore.

  9. Re:What about Perl 6? by Anonymous Coward · · Score: 1

    Perl 6 is so damn complex that nobody can actually implement it.

  10. Re:What about Perl 6? by symbolset · · Score: 3, Insightful

    The more mature a programming language is, the harder it is to extend it. Mature languages have vast codebases that must be supported, and substantive changes break legacy support. That's why it's best to get it right early on.

    --
    Help stamp out iliturcy.
  11. Re:Perl - the COBOL of scripting languages by rubycodez · · Score: 1

    I don't, there is huge financial services industry in Chicago area, hot languages are dot-NET family, j2ee, objective C, c/c++, php5 , but haven't seen Perl for ages.

  12. Re:Perl - the COBOL of scripting languages by gman003 · · Score: 5, Insightful

    Perl makes a GREAT "general-administration" tool. I use it as basically bash++ - it's the best way,bar none, to write programs on the command-line. There's a reason even the ultra-minimalist OpenBSD includes Perl in the default install.

  13. Re:Perl - the COBOL of scripting languages by MightyMartian · · Score: 1

    Neither should Cobol, and yet, as with Perl, sometimes there is a thing called historical momentum. Perl is still used in a lot of places, and there is a helluva lot of Perl code out there.

    --
    The world's burning. Moped Jesus spotted on I50. Details at 11.
  14. Re:What about Perl 6? by larry+bagina · · Score: 1

    He was right, but for the wrong reason :)

    --
    Do you even lift?

    These aren't the 'roids you're looking for.

  15. Re:What about Perl 6? by bunratty · · Score: 4, Insightful

    Python 3 is barely different from Python 2. It is not backwards compatible, but I've ported Python 3 programs to Python 2 (when I realized I had to use SciPy or run the code on a system with only Python 2), and nearly the only changes I had to make were changes for // for integer division and required () for print -- and these changes were trivial if I could simply import from __future__. In contrast, Perl 6 is very different from Perl 5.

    --
    What a fool believes, he sees, no wise man has the power to reason away.
  16. Re:What about Perl 6? by Anonymous Coward · · Score: 1, Insightful

    Perl Nukem Forever?

  17. Re:What about Perl 6? by Anonymous Coward · · Score: 1

    That's true. However, it has also been over TEN YEARS since it was first announced, yet there's still no good Perl 6 implementation.

    It's pointless to worry about retaining compatibility when nobody is actually able to use your software in the first place, even a decade after it was announced.

  18. Perl is alive! by fragermk · · Score: 2

    Perl is alive!

    Last time I checked Slashdot still runs on perl...

    My company does too.

    Now that ActiveState is providing Perl for Cloudfoundry, it's going to be good times in Perl land.

    1. Re:Perl is alive! by rubycodez · · Score: 2, Insightful

      last time I checked the UI of Slashdot was becoming ever more bloated, ugly and less functional. They should ditch the Perl for a modern language while rewriting the whole ball of shit.

    2. Re:Perl is alive! by PhrstBrn · · Score: 1

      What does UI have have to do with the backend implementation? The UI goes in a bunch of template files, which could theoretically be language agnostic.

      Any task (with regards to web apps) a modern language can do, Perl can do (and visa versa). One may be easier than the other for certain things, but Perl isn't a choice. Maybe not the best choice, but certainly far from unusable.

    3. Re:Perl is alive! by rubycodez · · Score: 1

      not the point, the point is that the whole thing needs a rewrite anyway, so why not choose a living rather than dying language before doing it?

      I do much coding as part of my job, haven't seen anyone choosing Perl for project in last decade, and my clients are huge municipal, state, and county IT operations with budget from millions to over a billion dollars. Perl is dying, it is undead.

    4. Re:Perl is alive! by palegray.net · · Score: 1

      I'm sitting here writing a Perl 5 application right now. In fact, it's comprised of several daemons that work cooperatively to handle various tasks, all written in Perl. The user side is delivered via a pool of FastCGI daemons (served by nginx, fwiw), written in Perl. My "day job" employer uses Perl. I've got friends working as programmers in the public sector in a variety of areas of state and federal government and education, and they write Perl code frequently. I've got other friends in the financial services industry, and they're still writing new Perl code. In the not too distant past, I served in the Navy. Perl is alive and well there, too. These all add up to billions of dollars worth of budgets.

      In short, the fact that you haven't seen it either means your exposure is more limited than you're claiming, or you're simply not paying enough attention.

      --
      512 MB RAM, 20 GB disk, 200 GB transfer, five datacenters. $19.95/month.
  19. Re:Perl - the COBOL of scripting languages by rubycodez · · Score: 2

    I love OpenBSD. But aside from scripts for mucking with perl itself, the reason perl is in the base install is to run the following (mostly brain dead simple) things:

    in /usr/sbin:
    add_user and rm_user scripts
    apxs (apache extension DSO builder / installer)
    pkg_chk, pkg_delete, pkg_info, pkg_create, pkg_merge (our simple and crude package manager)


    in /usr/bin:
    afmtodit font file creator for groff
    c2ph/pstruct dump c structure with offsets from debugger stabs
    find2perl convert find command with args to perl program
    piconv character encoding converter
    sed2p sed to perl converter


    Nothing that couldn't be done better as a side effect to a rewrite to more modern and alive language, the apxs, package manager and add/delete user is probably the only things most people use beside some that might use the apache extension handler. That package manager is especially aching for better features anyway.

  20. Re:Perl - the COBOL of scripting languages by dskoll · · Score: 3, Interesting

    We still use Perl to develop our products (commercial and open-source.) Perl may be maligned, but it's still a good tool for a lot of purposes and if you pick and choose carefully, CPAN is an awesome resource. Perl has modern frameworks (eg, Catalyst) for Web development that are competitive with anything out there, and DBI is superior to most alternative languages' database libraries.

    While I'm bullish on Perl 5, I'm not so optimistic about Perl 6. I think it's suffring horribly from second system syndrome and may never see the light of day as a useful production tool.

  21. Re:Perl - the COBOL of scripting languages by rubycodez · · Score: 2

    but, as with COBOL, that momentum is running down while with other scripting languages things are heating up. I like a language where the attention of the found and key developers are focusing on what will be used in the near future, not flying off into lala land for a decade speaking to each other in isolation.

  22. Re:Perl - the COBOL of scripting languages by jimmydigital · · Score: 4, Insightful

    Excellent troll... really first rate. Did you get federal funding from the Ministry of Trolling for that gem? I've been working professionally in unix/linux environments for about 12 years and believe me perl is still quite alive and well doing real work in lots of different kinds of companies. Php is somewhat painful to code in by comparison but both have their place. Except for java.. it has no sane place but you still find it in use everywhere which just goes to show anything can succeed in this world with enough marketing dollars behind it.

    --
    Every normal man must be tempted, at times, to spit on his hands, hoist the black flag, and begin slitting throats. -HLM
  23. Re:What about Perl 6? by arth1 · · Score: 2

    With Duke Nukem Forever being released next month, I think we shouldn't lose faith in Perl 6 either.

    It's taken 10 years, yes, but sooner or later they'll realize that what people are waiting for is a _native_ perl 6, not one on top of parrot, haskell, perl 5 or any other external engine. Cause if you virtualize, you might as well use the underlying langauge - it has to be at least as powerful as perl 6.

  24. For me Perl is alive and well. by EEPS · · Score: 4, Informative

    Despite what many are saying, Perl is still used extensively even for new projects. I use it daily, and while I really like ruby and python, for a variety of reasons, I have not switch away from Perl for most projects. My only question is when will Strawberry Perl 5.14 be released?

    1. Re:For me Perl is alive and well. by aixylinux · · Score: 4, Interesting

      I agree completely. As a UNIX sysadmin I frequently write scripts. For short and simple things, shell is preferred. But if I anticipate any complexity, I reach for Perl. I've had the experience of getting deeply into a shell script and thinking "I should have used Perl". Perl has never let me down, although I confess at times the programs have that write-only, line-noise appearance. But that's just because I've learned to use the idioms, and I comment on the complex stuff for the benefit of those who follow me--which could include myself six months later.

      I'd write Ruby if I could. The syntax is cleaner, and objects are built-in, not bolted on. But Ruby is just not available where I need it. Does anybody know of an AIX LPP package for Ruby?

      Also, I've been deeply disappointed at the progress of Perl 6--but Perl 5 does everything I need, so I really don't miss it. Of all sad words of tongue or pen, the saddest are these--it might have been.

    2. Re:For me Perl is alive and well. by PhrstBrn · · Score: 1

      I agree. I can always find Perl installed (most of the *nixes come with this by default due to dependencies), but python is less frequently installed, and ruby is almost never installed. Perl works fine for those hack-type scripts, so I don't see a pressing need to go start installing ruby or python everywhere. If ease of use is the deciding factor for choosing the language, then Perl is certainly the easiest to deploy of the full fledged scripting languages.

    3. Re:For me Perl is alive and well. by chromatic · · Score: 1

      My only question is when will Strawberry Perl 5.14 be released?

      Strawberry Perl 5.14 may wait for 5.14.1 in a month.

      --
      how to invest, a novice's guide
  25. Re:Perl - the COBOL of scripting languages by gman003 · · Score: 1

    Are you sure all that's in the base install? I can't see why apxs is there, since (last I checked) Apache isn't in the default install. And I think c2ph is only in the compiler "package", which is technically optional.

    Although I do agree that most of that could be rewritten in sh or even in C, rather easily. And the package manager does suck.

  26. but the power by Anonymous Coward · · Score: 3, Insightful

    With Perl, that complexity gives you power. If one does lots of programming, and their mind is in good shape, Perl can be used to rapidly dispatch programming problems.

    1. Re:but the power by Galactic+Dominator · · Score: 1, Funny

      Nobody's mind is in a good shape after coding in Perl. Even reading it can cause mild permanent brain damage. Someone who writes a reasonably complex app in Perl has a very good chance of developing an uncontrollable homicidal rage and other social problems. For example, I hear the Unibomber, Timothy McVeigh, Dieter Simader, and bin Laden are all accomplished Perl grey beards.

      --
      brandelf -t FreeBSD /brain
    2. Re:but the power by kiddygrinder · · Score: 4, Insightful

      unless your problem is "what the hell does this code do that i wrote 6 months ago".

      --
      This is a joke. I am joking. Joke joke joke.
    3. Re:but the power by Nimey · · Score: 1

      You should really document your code, then.

      --
      Hail Eris, full of mischief...

      E pluribus sanguinem
    4. Re:but the power by kiddygrinder · · Score: 1

      who said i didn't?

      --
      This is a joke. I am joking. Joke joke joke.
    5. Re:but the power by Nimey · · Score: 2

      You should document your code in a non-shitty way. Seriously, if you can't figure out what you did six months later, your doco sucks.

      --
      Hail Eris, full of mischief...

      E pluribus sanguinem
    6. Re:but the power by kiddygrinder · · Score: 1

      seems to work ok for python, c# and javascript. python i barely even have to bother.

      --
      This is a joke. I am joking. Joke joke joke.
  27. Re:Perl - the COBOL of scripting languages by rubycodez · · Score: 1

    forgot in /usr/libexec has vi.recover and makewhatis in perl

    had to check, but the c2ph/pstruct is in the base49.tgz

    heavily audited chrooted 1.3 apache is in the default install,

    ,
    It's sour grapes, I used Perl in development as was and fanboy over a decade ago. Major disappointment for me the way things went.

  28. bash not perl by highacnumber · · Score: 1

    I don't like Perl so I wish the catchy put-down of the summary title was accurate, but its not quite right. I think shell scripts are the COBOL of scripting. Perl might be more like B, although I'm not sure there is a great analogy there.

  29. Re:Perl - the COBOL of scripting languages by rubycodez · · Score: 2

    well, all the other languages jacked Perl's DBI (and many, many other things) for their libraries.

    Your company has history with Perl, but I don't think it will be chosen for new things now, PHP alone is mostly eating its lunch. Web serving the stats are something like 75% PHP5.x and 20% dot-NET but only 1% Perl with J2EE 5% (some overlap as sites run multiple langauges, but still....). Compare that to over ten years ago (when I was developing in Perl), it's really fallen.

  30. Re:Perl - the COBOL of scripting languages by rubycodez · · Score: 1

    Troll? You mention java, there are five times the web sites using server-side j2ee (bloated crap that sells hardware) compared to Perl. Sure, it's everywhere doing legacy crap like the (spartan) OpenBSD package management system I mentioned elsewhere in this thread , but essentially no one is choosing it for new projects, i anything BUT Perl is the norm. Face it man, it's a 90s language and it is dying. Netcraft and other web stat sites help confirm it. And Larry is killing it.

  31. Re:Perl - the COBOL of scripting languages by jimmydigital · · Score: 5, Insightful

    All I'll say to that is that the entire computing world does not revolve around websites... or programming certification mills. =] Perl is the duct tape that holds the networked world together... and it's not dying any more than actual duct tape is. It's a refined tool used by professionals to do the jobs that have always needed done in a minimum of time and that don't cater to the latest buzz word laden development methodology.

    --
    Every normal man must be tempted, at times, to spit on his hands, hoist the black flag, and begin slitting throats. -HLM
  32. Re:Perl - the COBOL of scripting languages by rubycodez · · Score: 2

    In default installs, Python is eating Perl's lunch on the command line, I can confirm by greping through my distro's /usr/bin and /usr/sbin. More python scripts to admin the system than Perl! That argument (in the default install) doesn't hold as much weight anymore, Python is also default in most major linux distros (and the new admin stuff is using that, while the crufty Perl admin scripts linger because no one cares to rewrite them).

  33. Re:Perl 5-something? by rubycodez · · Score: 1

    I had the same thought when someone mentioned Perl 6 would be out soon

  34. Re:Meh. by Runaway1956 · · Score: 1

    Indians using proper Microsoft Certified development tools.

    Did you write that with a straight face? Enjoy spending Microsoft's money, you pathetic shill!

    --
    "Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
  35. Re:Perl - the COBOL of scripting languages by jimmydigital · · Score: 1

    no, that would be C, which also holds your Perl together. I can run and admin a server without perl installed, but not without C

    I guess you missed the part about 'in a minimum of time'.

    --
    Every normal man must be tempted, at times, to spit on his hands, hoist the black flag, and begin slitting throats. -HLM
  36. I see dead languages by iggymanz · · Score: 1

    I see dead languages, languishing in the default installs of OS mostly as wrappers for menial tasks, taking command line arguments and making output in some cron and admin jobs, and they don't even know that they're dead! 8o

    1. Re:I see dead languages by FreakyGreenLeaky · · Score: 1

      I see 19 year old "professionals" with a "programming" certificate purchased off the web. They're everywhere, fucking things up, creating work for the real professionals.

      Gotta love them.

  37. Re:Perl - the COBOL of scripting languages by plopez · · Score: 1

    COBOL is still alive and kicking. It still does some things better than any other language. As Scotty once said "Use the right tool for the job, laddie"!

    Besides, COBOLScript is the COBOL of scripting languages:

    http://www.computer.org/portal/web/csdl/doi/10.1109/EDOC.2000.882363

    You should really do a bit more language evaluation. I don't know if you are ready to leave your parents' basement yet.

    --
    putting the 'B' in LGBTQ+
  38. Re:What about Perl 6? by goombah99 · · Score: 1

    have you ever seen a program that did not have a "print" statement in it? well those don't exist. And ignoring that whopper, I can tell you that it's not the big ones that really screw up legacy programs, it is the tiny tweaks that only go wrong one in a million times. Perl5.6 to 5.8 had some really really subtle changes to regrular expressions that broke programs in almost impossible to detect ways. Python 3 is death for legacy python.

    --
    Some drink at the fountain of knowledge. Others just gargle.
  39. Re:Perl - the COBOL of scripting languages by Eil · · Score: 1

    Php is somewhat painful to code in by comparison but both have their place.

    I respect your opinion, but my experience has been different. I forced myself to learn Perl twice and never could quite get the hang of it. So much of the language is context sensitive (e.g., this arbitrary symbol means a certain thing, except in some cases where it means something completely different) and there are so many features that I always felt overwhelmed. Sure, I always managed to get the code working but it felt hackish and thanks to "there's more than one way to do it," I was never sure if the way I implemented was the right way.

    PHP is far simpler. It's the only language that I've learned solely by reading code. Yeah, PHP has its warts (I'm looking at you, zillions of global functions) but I never find myself staring at a line of PHP wondering what it's doing.

    I don't agree with you about Java either, but that's a rant for another day.

  40. Re:Perl - the COBOL of scripting languages by iggymanz · · Score: 2

    that "minimum of time" is only until the next poor SOB has to modify some code. Then it's time to go a-wadin' through the whale guts.....

  41. Re:What about Perl 6? by Anonymous Coward · · Score: 1

    Maybe, just maybe, the more mature a programming language is, the less need there is to extend it. Particularly in the case of scripting languages. Write new programs and APIs with new features, not languages with more syntactic sugar. Boy am I glad to be free of the cult of that wierdo Larry Wall.

  42. Re:Perl - the COBOL of scripting languages by ducomputergeek · · Score: 3, Interesting

    Our entire API framework is Perl and has been for a few years now. Seemed like every time we needed to add a new format to return values in (originally was XML) like JSON, there always seems to be a perl module "for that".

    The best part of things is the fact that while we've added new functionality, we haven't had to do any maintenance work on the script in almost 5 years now.

    Biggest change we made from 5.8.x to 5.10 was rewrite some nasty els if statements and made them switch statements.

    The original web based management tool was originally written in PHP and that is what took all the time to maintain. It seemed like with each dot release of PHP some little thing broke and we were always fixing something every few weeks because of it.

    --
    "The problem with socialism is eventually you run out of other people's money" - Thatcher.
  43. A more readable changelog by shutdown+-p+now · · Score: 4, Informative

    A more readable changelog, with formatting, hyperlinks etc applied (rather than a raw pod file) can be seen here

  44. Re:headless camel by danbuter · · Score: 3, Informative

    I think the camel's head didn't fit. The pic probably needs resized. As for the camel, it's featured on "Programming Perl", which has been the main way to learn Perl for most programmers. BTW, "Programming Perl" is being updated for a maybe-December release. I was notified by O'Reilly after reviewing "Programming Perl" and saying it was old and out of date.

  45. Re:What about Perl 6? by Anonymous Coward · · Score: 1

    IMNSHO I tend to think that like Python 3, Perl 6 is a broken version of a once useful language. I'll stick with Python 2.x and Perl 5.x.y.

  46. Java has its uses by Billly+Gates · · Score: 1

    I decided to specialize in Java at college. Today, my business I want to start will be php based because I am 5x as productive with it, but Java is great for large scale programs.

    With Spring, Hibernate, and MVC you can make great million line code web sites that are more like applications than simple scripts frankensteined together ala PHP. This is great for advanced database access and business logic and intelligence. For 90% of sites out there ... tiny ... Java is overkill. However with Java I can develop the app, extend it, modify it, and change it little over a decade compared to PHP and can make it scale from a shared single server all the way to an IBM mainframe.

    I do admit I will only switch to Java after I have the revenue to hire someone to do it full time so it is not perfect. But if I were to grow my idea into a billion dollar company it would seem Java would fit my bill quite well. I know 10 years from now I can deploy the code and it will run securely with minimal issues.

    --
    http://saveie6.com/
    1. Re:Java has its uses by Greg+Lindahl · · Score: 1

      Perl has some nifty frameworks that can make you as productive as PHP for small web projects, and it also does large projects well.

      But hey, if you're comfortable with PHP and Java, and want to pay to have your app completely rewritten, then more power to you.

  47. Re:What about Perl 6? by bill_mcgonigle · · Score: 2, Interesting

    Perl 6 has 140+ different operators! That is absolutely insane. While I support being concise, Perl has far more complexity in the language core than any other language I have ever seen.

    I like this about English too. Can't tell that Larry is a linguist by training, can you?

    Come to think of it, I bet Python developers tend to be fond of Esperanto too. Some similarities there.

    --
    My God, it's Full of Source!
    OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
  48. Re:Perl - the COBOL of scripting languages by chromatic · · Score: 1

    I was never sure if the way I implemented was the right way.

    The free book Modern Perl explains how to use Perl 5 in an effective and maintainable fashion.

    --
    how to invest, a novice's guide
  49. It Lives! by Tumbleweed · · Score: 2

    Internet Yiddish LIVES!

  50. Re:What about Perl 6? by kiddygrinder · · Score: 2

    erm... i'm pretty sure there are a lot of gui programs that don't use print. ignoring that i think fixing brackets on print is pretty fucking trivial. do you have any better examples?

    --
    This is a joke. I am joking. Joke joke joke.
  51. Re:Perl - the COBOL of scripting languages by bill_mcgonigle · · Score: 1

    So many superior (e.g. python) ...if memory efficiency isn't on your requirements list...

    or just simpler (e.g. php5) ... if you can remember to use different string function calls depending on the encoding of your variable (you always know this ahead of time, right?)...

    while Larry vainly struggles on trying to turn Perl 6 into a swiss army knife

    Larry's not involved in the most likely successful implementation effort (Rakudo). Heck, I'm not even sure there have been any language specification updates of note in the last five years.

    --
    My God, it's Full of Source!
    OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
  52. Re:Perl - the COBOL of scripting languages by kiddygrinder · · Score: 1

    oh noes python is overblown! does that even mean anything? take your trolling elsewhere.

    --
    This is a joke. I am joking. Joke joke joke.
  53. Re:Perl - the COBOL of scripting languages by Greg+Lindahl · · Score: 3, Interesting

    The new search engine blekko is written in perl - wrote our own NoSQL database in it, too. We found CPAN to be an awesome resource; we use 600 distros from CPAN, and only found a couple of bugs in them.

    It's Java that's the new COBOL. (buh dum, ching!)

  54. Re:Perl - the COBOL of scripting languages by Greg+Lindahl · · Score: 1

    New startups using perl, courtesy of Quora:

    blekko
    nabbr
    selectablemedia.com
    goba.mobi
    socialflow.com
    duckduckgo

    Big companies writing lots of new perl, also courtesy of Quora:

    Lokku (makers of Nestoria), BBC, LJ, IMDB, Salon.com, Typepad, Zappos, Craigslist, FriendFinder, Ticketmaster, Slashdot

    I think you're really confused about the role Larry plays in the community. He's slowly creating a new language, which has little to do with perl 5. Perl 5 is actively maintained and has a large community of users.

  55. Re:Perl 5-something? by tempire · · Score: 1

    This is a clear example of folks not really knowing what they're talking about.
    Perl6 is a language spec, not a language implementation. Check out Rakudo if you want to see an implementation.

    Even so, Rakudo (and any other Perl6 implementation) is *not* the successor to Perl5. It's an unfortunate naming scheme that people don't understand, and although there are similar and borrowed elements between the two, they do not directly relate to each other.

    If you want to see activity, check out web frameworks like Mojolicious (http://mojolicio.us), or installation tools like Perlbrew (http://perlbrew.pl). There's also plenty of activity going on @ sites like: http://blogs.perl.org/, http://ironman.enlightenedperl.org/, http://perlbuzz.com/.

    Not to mention plenty of jobs always coming across the wire @ http://jobs.perl.org/. Which, interestingly enough, some rubyists copied - http://jobs.rubynow.com/

  56. Age Demographic by Anonymous Coward · · Score: 1

    Just reading the comments for and against perl and wondering about the age of the posters. How many new perl programmers are there? How many people are switching? It just sounds like some comments are from people with 10+ years of IT experience and bit stuck in their ways (just like I am with python!).

    Is this perl's destiny http://news.bbc.co.uk/2/hi/also_in_the_news/7097647.stm

    1. Re:Age Demographic by cin62 · · Score: 1

      I'm new to programming (2 years), using perl. My job description is not programming, but it is one of the key components of what I do. Based on how suitable perl is for our projects, I'm convinced I'll use it 5 years from now.

    2. Re:Age Demographic by improfane · · Score: 1

      'Stuck in their ways?'

      It's people like me who have to clean up the mess people like you make because you'd rather use the hyped up tool than the tool that is suited to the job.

      You are a prisoner of hype.

      --
      Slashdot needs Geekcode | Can anyone recommend any good SCIFI? My tastes: Foundation, Startide Rising, CITY, Ringworld,
  57. Python 3 is death to Python by mangu · · Score: 4, Informative

    Python 3 is barely different from Python 2

    It's different enough to break the language for legacy code.

    When you have code by the million lines, it's impossible to have a script that can reliably convert programs like Guido thinks it can. It's not just adding parentheses to print, there are some beastly things, like giving the division operator a different behavior. In Python 2.7, the result of (3 / 2) is 1, in Python 3 it's 1.5. I have absolutely no way to pore through those million lines and checking every division to see which operator should I use, keep the '/' or change it to '//'.

    Besides, the changes from Python 2 to 3 are *all* in the direction of making it a more verbose language. I couldn't find any example of code that would be shorter in Python 3 than in 2. That goes against the philosophy of a scripting language, the last thing we need is a new Java.

    I had gradually changed from Perl to Python over the years, but this P3k made me reconsider if this was wise. Apparently, there's no good-for-everything language left. So, in the scripting side, where quick results count, I've been considering switching back to Perl. Conciseness is king here, and nothing beats Perl at that.

    As for large projects, thank god C is still there, still running K&R style code almost unchanged. Looking back over the years, I find that, for big projects, no language has given me less trouble than C. Once you get it running, it runs forever.

    1. Re:Python 3 is death to Python by Waffle+Iron · · Score: 2

      In Python 2.7, the result of (3 / 2) is 1, in Python 3 it's 1.5. I have absolutely no way to pore through those million lines and checking every division to see which operator should I use, keep the '/' or change it to '//'.

      When the // operator was introduced - over 10 years ago - they warned you that this change was coming. Ever since then, it has been prudent to use // wherever you want the answer of 3 divided by 2 to be 1. So if you had been coding according to best practices, you wouldn't have to look through all your code for divisions.

    2. Re:Python 3 is death to Python by goombah99 · · Score: 1

      I think you are missing his point. So you create a syntax that is an error that will be accepted. Billions of programs have this error. Then one day the syntax changes and no error messages are generated.

      Consider is some language had = and == be the same thing, then they changed it so that = meant copy a pointer and == meant copy a value. your head would explode trying to track all that down.

      --
      Some drink at the fountain of knowledge. Others just gargle.
    3. Re:Python 3 is death to Python by Waffle+Iron · · Score: 1

      I think you are missing his point. So you create a syntax that is an error that will be accepted.

      Reasonable people should not have "accepted" the integer / operator, and they didn't have to. On integers, the operator didn't do what anybody would expect it to, and this was clearly just about the biggest flaw in Python 2.X. It's unfortunate that the flaw was there and needs to be fixed, but life isn't perfect.

      Seeing the mistake, 10 years ago the Python developers gave you the tools to avoid using integer '/', and they told you the planned fix. If you simply followed their advice, you'd be fine now. Personally, I've always cast at least one of the operands to "float()" if I used the / operator, otherwise I've always made integer division explicit by using the // operator.

      This is like when the C people tell you to not use the "gets()" function. That function was a mistake, even though it still compiles and runs. Competent coders just don't use gets(), and likewise, they don't use an unqualified '/' in Python 2.X.

    4. Re:Python 3 is death to Python by goombah99 · · Score: 1

      Y'know I never got the memo. Seriously I never heard of this before today. I don't think this is my fauly either. I own dozens of books on python and am well read. As a check to see if I'm the lone idiot, I just went through a bunch of random files in python libraries I've downloaded over the years. Only one of them had // in it. So apparently no one else got the memo either.

      --
      Some drink at the fountain of knowledge. Others just gargle.
    5. Re:Python 3 is death to Python by Waffle+Iron · · Score: 1

      Here's your memo: PEP 238. I believe that it's frequently referenced in the "what's new" section of various point releases of Python since the PEP was published.

    6. Re:Python 3 is death to Python by goombah99 · · Score: 1

      Shucks, I stopped reading them after the first 200 I guess. Who has time to keep up with mere proposals. This is a bewildering way to run a railroad.

      --
      Some drink at the fountain of knowledge. Others just gargle.
    7. Re:Python 3 is death to Python by c0lo · · Score: 1

      Looking back over the years, I find that, for big projects, no language has given me less trouble than C. Once you get it running, it runs forever.

      It is not with running that I have issues, it is actually with the results the run has. Pray, try compiling a code from 20 years ago on a 64 bits platform, code that that convert between an int and a pointer, and tell us how it went.

      --
      Questions raise, answers kill. Raise questions to stay alive.
  58. Re:Perl - the COBOL of scripting languages by FreakyGreenLeaky · · Score: 2

    Exfuckingactly. Whilst the buzz-word slavering IT managers and their Java sycophant underlings hype around in Brownian motion fiddling feverishly with websites, the rest of the professional world maintains the foundation and glue that really makes all the shit "just work."

    With the possible exception of Python, nothing else comes close in satisfying it's intended purpose (talking toolkit/scripting/etc). Perl bashing reminds me of kids with snot-shiny upper lips whining about the "complexity" or "shortcomings" of C while not hearing the whooshing sound as the mothership-sized point sails over their heads.

    Same with COBOL. Just because you don't encounter it in your little Javascript/PHP career does not mean it's not out their pumping major iron. You'd be amazed how many COBOL professionals there are laughing at the ignorance of these arrogant little dickheads talking out their anuses.

    All programming/scripting languages have their place. They were all designed (some less so) to solve a specific problem.

  59. Re:headless camel by pmontra · · Score: 1

    Yes, the artist made a mistake: the image http://a.fsdn.com/sd/topics/topicperl.gif is too wide to fit into the template. Hopefully it will be noticed now. By the way, how do we report bugs about Slashdot?

  60. Re:What about Perl 6? by TheLink · · Score: 1

    Actually I don't care whether it is native or not.

    I want it fast. If they can get javascript to run fast, why can't they make perl faster? Heck get perl5 to run fast now and I don't mind "waiting for perl6" for another 20 years ;).

    --
  61. Re:What about Perl 6? by sqldr · · Score: 1

    Yet you can do vastly more than python without importing a single lib

    Some would argue that this is a bad thing.. :-) It's not an accident that python without any libraries is completely useless.

    In answer to the comments a bit further down about how languages getting more mature makes them harder to extend - well python has about 30 keywords. Perl has about 600. Python usually just has to replace a few libs. Python 3000 mostly fixes some 10 year old issues which date back to the infancy of the language, which will hopefully be the last time for a very long time someone has to do it.

    --
    I wrote my first program at the age of six, and I still can't work out how this website works.
  62. Re:What about Perl 6? by internettoughguy · · Score: 1

    I think that Python needs a __past__ module for those nostalgic features like bracket-free print statements. Perhaps it could be a new PEP, and we could use a bizarre import statement like from __future__ import __past__ in Python 3.3.

  63. Re:Perl - the COBOL of scripting languages by Haeleth · · Score: 2

    superior (e.g. python)

    Python has some advantages over Perl -- cleaner syntax, a better REPL, none of the legacy shell-script-derived cruft that makes it so easy to write terrible code in Perl. It also has quite a few disadvantages that make it harder to write robust code, such as its lack of any equivalent to Perl's extremely useful "use strict" and its poorly designed scoping rules.

    I see a lot of new development taking place in both languages. I don't see much PHP, but that's a niche language restricted to web development, which isn't something I'm involved with.

  64. Re:What about Perl 6? by RDW · · Score: 5, Insightful

    "I was just going to say that back in about 2001 someone gave me advice not to learn Perl 5 because a Perl 6 release was imminent."

    It's a shame that this 'Osborne effect' has hung over Perl for the last decade. I wonder how Perl 5 would now be perceived if Perl 6 had been given a different name and announced as a research project into language development, rather than the next version of Perl? With better PR, Perl 5.10 could easily have been 'Perl 6'.

    All this tends to obscure the quet evolution of Perl 5 programming into what 'chromatic' and others are calling 'Modern Perl', using an idiomatic style that takes full advantage of recent language features (some borrowed from Perl 6) and CPAN to write efficient and maintainable code:

    http://www.modernperlbooks.com/
    http://onyxneon.com/books/modern_perl/

    As always, a lot of the most active development is happening outside the core language. Anyone interested in some of the directions Perl 5 is going in today ought to check out projects like these:

    http://www.iinteractive.com/moose/
    http://plackperl.org/
    http://www.catalystframework.org/
    http://mojolicio.us/

  65. Re:Perl - the COBOL of scripting languages by dskoll · · Score: 2

    PHP alone is mostly eating its lunch

    Interesting you say that... our product's Web interface is written in PHP and I rue the day I made that decision. For all of Perl's faults, PHP is about 100 times worse. No proper namespaces, completely wild-west wacky naming "conventions", no decent DBI-like library, crappy add-on modules (just try finding a decent YAML parser for PHP.)

    If I had to do something new, I'd probably look at Python. I have very little experience with it, but it seems quite easy to use and fairly readable. Nevertheless, CPAN still takes the crown for a useful repo of modules.

    There are still a lot of companies developing in Perl. They tend not to tout it or make much noise about it, though. It's not trendy any more.

  66. Re:Perl - the COBOL of scripting languages by mjwalshe · · Score: 1

    Quite you can see the same problem with kids that don't understand why FORTRAN is still used in a lot of high end technical programming

  67. Re:Perl - the COBOL of scripting languages by MightyMartian · · Score: 1

    If Perl's "wind down" is anything like Cobol's, then it's still got many years left.

    --
    The world's burning. Moped Jesus spotted on I50. Details at 11.
  68. Re:Perl - the COBOL of scripting languages by Mozai · · Score: 3, Funny

    php5 is simpler?  What planet do you live on?

    In Perl:
    curl -sL 'http://slashdot.org/index.rss' |perl -ne 'm/<title>(.+?)</ && print "- $1\n";'

    Same thing in PHP5:
    curl -sL 'http://slashdot.org/index.rss' |php5 -r '$h = fopen("php://stdin","r"); while(! feof($h)){$line=fgets($h); if(preg_match("/<title>(.+?)</",$line,$match)){echo "- ".$match[1]."\n";}}'

    ... and if you say "well, php5 is simpler for what *I* need," I'mma gonna poke you for thinking that everyone else has the same needs as you.

  69. Re:Perl 5-something? by rubycodez · · Score: 1

    So what? the point is that for over a decade, Larry and his cohorts have been farting around with Perl6 with no production implementation to show for it, just a bunch of endless mental masturbation

  70. Re:Perl - the COBOL of scripting languages by oiron · · Score: 1

    I often have people asking me why C is still getting used.

    C#/Java is all you need, right? Right?

  71. Re:What about Perl 6? by chromatic · · Score: 1

    With better PR, Perl 5.10 could easily have been 'Perl 6'.

    That would have been extremely silly.

    Modern Perl 5 is a good language with great libraries, but Perl 5 still has many, many flaws that only breaking backwards compatibility in a very dramatic way could fix. You can take the Perl 5.10 approach of deprecating a few of the worst offenders and considering removing them and eventually replacing them, but that process will take decades.

    Also, the Perl 5 core is very, very difficult to maintain.

    --
    how to invest, a novice's guide
  72. Re:Perl - the COBOL of scripting languages by bXTr · · Score: 2

    my $troll = $ubiquitous_BSD_is_dying_troll;
    $troll =~ s/BSD/Perl/g;
    print SLASHDOT $troll, "\n";

    --
    It's a very dark ride.
  73. Re:What about Perl 6? by jlarocco · · Score: 1

    So trivial that 2to3.py, which comes with Python 3, will do it automatically.

    --
    Maybe not
  74. Re:Perl - the COBOL of scripting languages by dogmatixpsych · · Score: 1

    That's why I am learning Perl instead of Python right now. I've done some Bash scripting but I'm trying to branch out a bit. My scripting needs are not huge, mostly neuroimaging-related stuff, but Perl seemed better as a bash++ environment (like you put it) than Python. I wanted to learn Python (I still will, just later) but I had two individuals independently recommend Perl for my needs rather than Python.

    Perl might be a bit antiquated and awkward but it's the right tool for a number of jobs.

  75. Re:What about Perl 6? by RDW · · Score: 1

    No, I didn't mean forget about re-designing the language (and its implementation) altogether and just carry on building on the old, flawed foundation. The goals of Perl 6 seem entirely laudable. I just think that the way this has all been presented to the wider community over the past decade hasn't done Perl any favours. Somehow a (false) impression has been created that Perl 5 is in some sense deprecated, while Perl 6 is not ready. If Perl 6 had been presented from the start as an experimental 'sister language' (perhaps with a different name), rather than being named as Perl 5's successor over a decade early, perhaps the perception would now be different.

    Far less significant changes than those that occurred between Perl 5.0 and 5.10 (or 5.14) have been honoured by major version bumps in other software packages, which at least serve to indicate that some new and exciting features are available (which is what I meant by 'better PR'). But this wasn't possible with Perl because a drastically changed language design had already been given the Perl 6 name. Isn't your term 'Modern Perl' itself a way of saying that things have changed a bit since 1993, even though we're still using 'Perl 5'?

  76. Syntax improvements are a huge step forward by lordlod · · Score: 1

    There are some really good changes going into 5.14. Worth highlighting for anyone with Perl experience.

    The Array/Hash reference mess has been greatly improved. You can now perform most builtin operations directly on array references. So no need to mess around with dereferencing things all over the place. This is a huge improvement in the syntax surrounding complex data structures.

    The eval exception handling mess has been cleaned up so that error handling modules such as autodie can function properly without strange corner cases.

    1. Re:Syntax improvements are a huge step forward by Corse32 · · Score: 1

      The hash ref thing will save me some intense headaches, an array of hashes of either hashes or arrays of hashes? I thought I was going nuts trying to update a value in that mess.

  77. Re:Perl - the COBOL of scripting languages by jsdcnet · · Score: 1

    PHP beats perl for web applications for one simple reason: it was designed from day one to work as an apache module. mod_perl was a hack, and it worked OK for a lot of people, but for me it was always more trouble than it was worth. Eventually you had heavy hitters like Yahoo putting their weight behind PHP for web code and that pretty much decided the race. Re your specific objections: namespaces - use classes DBI library - use PDO

    --
    no longer working for cnet
  78. Re:Perl - the COBOL of scripting languages by jsdcnet · · Score: 1

    So much of the language is context sensitive (e.g., this arbitrary symbol means a certain thing, except in some cases where it means something completely different) and there are so many features that I always felt overwhelmed. Sure, I always managed to get the code working but it felt hackish and thanks to "there's more than one way to do it," I was never sure if the way I implemented was the right way.

    I felt that way too until I read Effective Perl Programming. It goes over all the multiple ways to do things and explains why one is better than another in a particular situation. Great book. It gave me the Perl "aha moment" I needed.

    --
    no longer working for cnet
  79. Re:Perl - the COBOL of scripting languages by rrohbeck · · Score: 1

    If Larry really had pushed Perl6 it would have been ready a long time ago. He wanted Perl6 to be community designed; that's why it's taking forever.
    I had to work on a mediawiki installation a while ago and had my first time encounter with PHP. Verdict: Brain dead.
    Perl5 is still my first choice for anything that doesn't have to be efficient because it's only called every now and then. And the programs still start up faster than Java. By the time my vendor's Java code finally starts to run my Perl scripts are already finished. So much for byte code and JIT.

    --
    thegodmovie.com - watch it
  80. Re:What about Perl 6? by chromatic · · Score: 2

    If Perl 6 had been presented from the start as an experimental 'sister language' (perhaps with a different name), rather than being named as Perl 5's successor over a decade early, perhaps the perception would now be different.

    People express that sentiment often, but I've never found it realistic. Many of the philosophical goals of Perl 6 are the same philosophical goals Larry had when designing Perl 5. Many of the tactical approaches are far different, but there's where my disagreement with the "It deserved the label as an experiment at the time!" idea arises. No one really knew how far redesigning Perl needed to go to achieve those philosophical goals until the RFCs and Apocalypses started pulling at loose strings in the sweater.

    Isn't your term 'Modern Perl' itself a way of saying that things have changed a bit since 1993, even though we're still using 'Perl 5'?

    Certainly, though it's less about using new and exciting features because they're new and exciting than it is about understanding how the language and its features, both new and old do—and, in some cases, don't—work. The biggest and most important language change has been the gradual lexicalizing of features such as filehandles, pragmas, grammar modifications, and even packages. You may have to squint to see the latter, but it's there. Perl 6 takes that principle to another level.

    --
    how to invest, a novice's guide
  81. Re:Old by Corse32 · · Score: 1

    to? I find myself using it more and more, interfacing with all kinds of weird bug ridden SOAP APIs seems to be easiest with Perl...

  82. Re:What about Perl 6? by arth1 · · Score: 1

    Easy, flexible, fast -- pick any two.

    I've often found that I can do things quicker in perl than other langauges, not because perl itself is fast, but because it gives me the tools to implement faster algorithms without having to invent new spokes, ball bearings, tires and hubs. Just something as simple as caching database queries in a local hash can save ridiculous amount of time, with very little work. And sorting on a subset instead of entire tables? Priceless.

    I also strongly recommend the perlperf(1) man page, as well as the web links found at the end of that man page.

  83. Re:Perl - the COBOL of scripting languages by ToasterMonkey · · Score: 1

    Nothing that couldn't be done better as a side effect to a rewrite to more modern and alive language

    That just made me bang my head against my desk.

    How about 'redesign' (if needed)
    instead of 'rewrite in a newer language' (because)?

  84. Re:Perl vs Python, in OS scripts by rduke15 · · Score: 2

    A recently installed server in a small company (Debian Squeeze):

            $ find /bin /sbin /usr/bin /usr/sbin -type f -exec file "{}" \; | grep 'perl .*script' | wc -l
            196
            $ find /bin /sbin /usr/bin /usr/sbin -type f -exec file "{}" \; | grep 'python .*script' | wc -l
            46

    My notebook (Ubuntu 10.4):

            $ find /bin /sbin /usr/bin /usr/sbin -type f -exec file "{}" \; | grep 'perl .*script' | wc -l
            398
            $ find /bin /sbin /usr/bin /usr/sbin -type f -exec file "{}" \; | grep 'python .*script' | wc -l
            134

    Of course, some may prefer Perl to grep + wc (it's faster too):

            $ find /bin /sbin /usr/bin /usr/sbin -type f -exec file "{}" \; | perl -ne '/(perl|python) .*script/ && $$1++; END {print "$perl perl\n", "$python python\n"}'
            398 perl
            134 python

  85. Re:headless camel by damn_registrars · · Score: 1

    Yes, the artist made a mistake: the image http://a.fsdn.com/sd/topics/topicperl.gif is too wide to fit into the template. Hopefully it will be noticed now.

    Don't count on that. It's been that way for some time now, and nobody with the ability to fix it seems to care. One of the former slashdot programmers was a regular voice on use.perl and he never bothered to fix it; I highly doubt anyone still working for slashdot gives a damn about it.

    By the way, how do we report bugs about Slashdot?

    Carrier pigeon, sent to the ISS.

    Or at the very least, that would be just as useful as any other mechanism. Slashdot doesn't care about fixing bugs, just about implementing new ones. You can email rob malda directly (malda@slashdot.org) if you want, and he'll weasel his way around the problem in a reply to you. Or you can just do like the rest of us and bitch about the bugs openly here on slashdot instead. It also doesn't lead to them being fixed, but you can take credit for being the first to find a specific bug!

    --
    Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
  86. Re:headless camel by pmontra · · Score: 1

    Oh well, too bad for the camel. It's going to stay headless until the next major UI rewrite. Thanks anyway.

  87. Re:What about Perl 6? by RDW · · Score: 1

    "No one really knew how far redesigning Perl needed to go to achieve those philosophical goals until the RFCs and Apocalypses started pulling at loose strings in the sweater."

    It's certainly easy to criticise all this with the benefit of hindsight - I don't imagine anyone at the time imagined it would turn out to be be such a long, drawn-out process.

  88. Re:headless camel by damn_registrars · · Score: 1

    Oh well, too bad for the camel. It's going to stay headless until the next major UI rewrite. Thanks anyway.

    I'm pretty sure the last rewrite is responsible for the decapitation. I rather highly doubt that the next one will put the head back on.

    --
    Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
  89. Thanks for the info. Isn't Perl dying rapidly? by Futurepower(R) · · Score: 1

    Thanks for the excellent insight.

    However, isn't Perl dying rapidly? Isn't Python the new Perl?

    Remember all the jokes about Perl being a write-only language? The libraries are wonderful, but the language is discouraging.

  90. Re:Perl - the COBOL of scripting languages by mr_mischief · · Score: 1

    Perl 5 is the second system. Perl 1-3 built on earlier versions, and Perl 4 was a version bump to sell books which easily described the current state of the language (since 3 morphed a bit from start to end and they didn't want to specify an exact long version string for the book title).

    Perl 5 added lots of features, like bless(), the default object system, proper modules, etc. These are where many people find the language creaky and messy -- where things not designed with Perl 4 got bolted onto the side of a mostly Perl 4 compatible language. Modern Perl 5 code doesn't look like Perl 4, but you can feed the system Perl 3 and it will generally work.

    Perl 6 is the third system. It's designed by taking lessons from what worked and what didn't over the past 23 years.

  91. Re:Perl - the COBOL of scripting languages by mr_mischief · · Score: 1

    Using classes doesn't overcome the fact that there are functions like mysql_real_escape_string_yes_I_really_mean_it_and_URI_decode_too in the main namespace. Classes and compartmentalized namespaces came far too late to avoid the issues.

  92. Re:Perl 5-something? by mr_mischief · · Score: 1

    All the while Perl 5 has been updated and refined, you fucking troll.