Slashdot Mirror


Larry Wall Talks Perl, Culture, and Community

LostDiver writes "Computerworld Australia caught up recently with Larry Wall of Patch and Perl fame. He talks about the development of Perl as 'scratching an itch,' a release date for Perl 6 (Christmas day, year unknown) and beauty versus practicality. Computerworld also has some more information on the upcoming Perl 6. A while back they interviewed Bjarne Stroustrup of C++ fame as well." jamie pointed out a interesting, related video of a presentation by Clay Shirky from last year's Supernova conference in which he discusses why the Perl community (or any web community) drives progress and innovation.

36 of 123 comments (clear)

  1. Re:Dropping regex as a core lang feature by psy0rz · · Score: 5, Informative
    they wont be dropping regex completely. from tfa:

    Perl 6 promises to put the "regular" back into regular expression. "We have more powerful primitives in Perl 6," Wall said. "There's no more /x switch to enable extended syntax. No more mode switches like /s and "dot" (.) now means match any character. There's no /m modifier and we've regularised the brackets so {} always mean embedded code."

  2. Christmas? by MikeRT · · Score: 2, Interesting

    It sounds almost like they're hoping that Santa will drop it down the chimney on a flash drive for them. In the time it has taken Perl 6 to get where it is now--fairly close to release--Mono has gone from being scraps of C and C# code, to being a fairly complete and compatible .NET development environment that has a fairly active developer base on Linux. I'm not going to say that Perl 6 is irrelevant, but if it is not out, in a final release within 6 months to a year, it probably will be since even PHP will be grown up with 5.3 and 6.0 by then.

    1. Re:Christmas? by maxume · · Score: 2, Insightful

      Actually, it doesn't matter. In a world where millions of people are providing software for hundreds of millions of other people, being a niche player is perfectly viable.

      --
      Nerd rage is the funniest rage.
    2. Re:Christmas? by jheiss · · Score: 4, Interesting

      It appears within the system administration community that Ruby is well on its way to replacing Perl as the de facto language for major tools. Well over half of the new tools introduced at the LISA (Large Installation System Administration) conference this year were written in Ruby. I've been developing in Perl for about 15 years, but have recently switched nearly all of my development to Ruby. I know I'm tired of hearing about how great Perl 6 will be. I've been hearing that promise for half a decade now. The biggest drawback to Ruby right now is that the availability of 3rd party libraries is nowhere near the level of what's in CPAN.

      Apple is also putting a significant amount of effort into improving and integrating Ruby with Mac OS X. MacRuby and HotCocoa both look really interesting, particularly if you want to develop GUI apps.

    3. Re:Christmas? by r7 · · Score: 3, Interesting

      It appears within the system administration community that Ruby is well on its way to replacing Perl

      Interesting observation but not what I'm seeing here in Silicon Valley. Perl is far less popular than in years past, but Ruby is not that popular among systems admins either. Instead Python is all the rage. I believe this is because Ruby is better suited to those who spend a majority of their time writing code whereas Python can be learned and used more easily without such frequent use. So sysadmins here, who don't spend the majority of their time writing code, are using mainly Python (and shell).

      Not a statistic, just an observation across a dozen or so large and small Linux and Unix using organizations.

    4. Re:Christmas? by Kent+Recal · · Score: 2, Insightful

      Yup, python is more popular than ruby in the sysadmin arena in my area, too. I guess for the reasons that GP mentioned - it's easier to learn the basics and the syntax generally makes it harder to write stuff that you don't want to maintain later than that of Perl or Ruby.

      Unscientific sample from my box here:

      $ grep "/python" /usr/bin/* | wc -l
      114

      $ grep "/ruby" /usr/bin/* | wc -l
      28

      And from a fairly vanilla debian box:

      $ grep "/python" /usr/bin/* | wc -l
      34

      $ grep "/ruby" /usr/bin/* | wc -l
      17

    5. Re:Christmas? by BenLeeImp · · Score: 5, Informative

      You are hugely mistaken. http://dev.perl.org/perl6/faq.html

    6. Re:Christmas? by chromatic · · Score: 5, Informative

      I'm not sure how much of that applies to modules, though.

      All of it.

      Can Perl 6 code use a Perl 5 module?

      If you use a Perl 6 implementation which supports Perl 5, yes.

      Does the Perl 6 converter work on modules?

      Yes, if they're pure-Perl.

      Given that the object system is getting an overhaul in Perl 6, does that break OO-based modules?

      No.

      Is Perl 6 source-code compatible with the native code stubs that many modules, for example database drivers and GUI libraries, require?

      That depends on the Perl 6 implementation. The answer is probably no, but there's no reason someone couldn't write a converter for the basic XS uses.

    7. Re:Christmas? by bzipitidoo · · Score: 2, Insightful

      Modules have to be rewritten? No they won't. More like, abandoned as unnecessary. But still usable as is if you want. Many so-called modules are just wrappers for C libraries, where someone else has gone to all the pain of figuring out the XS. If I've understood it correctly, Perl 6 will be able to call library functions directly, without a lot of fuss. No more messing around with XS, or SWIG and the 100K extra verbose code it is wont to generate per function, or whatever, wondering if it's failing because you screwed up the stack or misunderstood a parameter, or the system's linker does something oddball with the parameter order. Or even, the coder used that long forgotten C keyword, "pascal". The Camel book itself said of this problem "here be dragons".

      For me, that's huge. I've been waiting for Perl 6 for this feature alone. Call any library function I want! Just call it, no more digging around CPAN to find that wrapper module that's half finished. No more dragons!

      --
      Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
    8. Re:Christmas? by chromatic · · Score: 3, Informative

      If I've understood it correctly, Perl 6 will be able to call library functions directly, without a lot of fuss.

      Rakudo (Perl 6 on Parrot) can do this now.

    9. Re:Christmas? by cxreg · · Score: 4, Informative

      Interesting omission:

      $ grep "/python" /usr/bin/* | wc -l
      168

      $ grep "/ruby" /usr/bin/* | wc -l
      23

      $ grep "/perl" /usr/bin/* | wc -l
      570

    10. Re:Christmas? by Kent+Recal · · Score: 2, Funny

      Well, I didn't bother to include Perl because everybody knows it's the 800 pound gorilla. 20 years of script hacking don't just go away, whereas python and ruby only started gaining traction in the last 5ish years.

    11. Re:Christmas? by chromatic · · Score: 2, Informative

      Perl 6 is supposedly coming out ...someday.

      The next stable release of Rakudo (Perl 6 in Parrot) comes out next Tuesday. This will be the 24th stable monthly release of Perl 6 on Parrot in a row. You can also see daily Rakudo spectest progress, if you like.

    12. Re:Christmas? by mewshi_nya · · Score: 2, Funny

      "I was either onto something, or on something."
                          -Larry Wall

    13. Re:Christmas? by PiSkyHi · · Score: 2, Insightful

      Ahh, the things I've hacked together with good old Perl - hacking Perl maybe unfashionable and considered unmaintainable by other - maybe even other Perl programmers.

      But to a hacker who believes most generic code has been written, that only tailored code remains to be written, Perl will remain to glue and re-use other code with ease.

      Replacing it is a fantasy by people who would like to re-invent the wheel with a different color-scheme annually.

      Re-usable code ? modules are easy to write, easy to understand and object oriented is only more practical when writing GUI apps.

      Grow your code, use other's code, write it in way to be re-usable, don't rely on someone elses syntax issues to take of it for you.

      I just don't care if Perl is fashionable or not, I like it, it works for me and as a hacker not a programmer, I just don't care if its not documented, when I read Perl, I think in Perl.

      The only reason I learned Python is to use others code who felt the need to switch.

  3. Re:Dropping regex as a core lang feature by modmans2ndcoming · · Score: 2, Insightful

    who the fuck thought they would be dropping Regex in any way shape or form?

  4. Re:Dropping regex as a core lang feature by Anonymous Coward · · Score: 4, Informative

    They didn't drop regexes at all. They've actually generalized them into context-free grammars, and these CFGs are a core part of the language.

    If anything, the problem with perl6 is they added way too much.

  5. Perl culture on public display by David+Gerard · · Score: 2, Funny

    The quality and intelligence of graffiti is inversely proportional to the difficulty in putting it wherever it is. Dangerous spots on train lines? Misspelt tags. Quiet abandoned swimming pools? Computer scientists with spray cans. Now, that's Perl in Popular Culture!

    --
    http://rocknerd.co.uk
  6. Re:Dropping regex as a core lang feature by mrvan · · Score: 4, Interesting

    Hmm that's interesting.

    I know quite a lot of scientists who use Finite State Automata for tasks and use custom libraries for that. If Perl 6 can provide an easier and efficient way of doing that it might even have a future :-)

  7. Re:Why should I use Perl instead of Python? by exploder · · Score: 2, Interesting

    Things you plan to write in under fifteen minutes are generally better done in Perl. Beyond that point, the verbosity and consistency of Python becomes a distinct advantage.

    --
    Yo dawg, I heard you like the Ackermann function, so OH GOD OH GOD OH GOD
  8. Holy typos, Batman! by Haeleth · · Score: 3, Insightful

    "Signals" for "sigils", describing ClearCase as a "rear-vision control system"... was this article dictated over a noisy phone line to someone who knows nothing about computers?

  9. Good reasons for the delay by burris · · Score: 4, Funny

    Some important changes had to be made to support the developers of Duke Nukem Forever, who are rewriting the project from scratch in Perl 6. The good news is that means Perl 6 is right around the corner!

  10. Re:Why should I use Perl instead of Python? by Haeleth · · Score: 4, Insightful

    "Perl or Python?" is like "awk or sed?". They solve different problems. They're suited to different tasks. For the parts where they overlap, though, there are various arguments either way. There's a reason why there are flamewars about this stuff. You get flamewars when the arguments on both sides are evenly matched, and the choice therefore becomes a religious issue.

    Perl has some advantages. It has anonymous functions that aren't crippled. It has predictable lexical scoping. It has (optional) variable declarations. It has more libraries, and a very convenient standard way of installing them. It's available on any Unix system, whereas Python programmers are frequently reduced to begging sysadmins to install their favourite language. (And sysadmins frequently prefer Perl...)

    Perl also has disadvantages: cryptic syntax, too much magic DWIM stuff, no standard way of doing OOP, etc. Note that these are all areas where Python is strong; if you care about consistency, Python is going to be a better choice for you personally.

    Neither is a clear winner on performance; Perl is faster for some things, Python for others.

  11. Who needs Perl 6 when we have Perl 5? by poet · · Score: 3, Insightful

    A talk on why Perl 5 is Alive was given at PostgreSQL Conference West 08. What I found most interesting is how vibrant the current perl 5 community is. There are even non profits popping up to support it and forgo worrying about 6...

    --
    Get your PostgreSQL here: http://www.commandprompt.com/
    1. Re:Who needs Perl 6 when we have Perl 5? by diegocgteleline.es · · Score: 3, Informative

      Take a look at the November 2008 TIOBE index top ten:

                  Position Position Programming Ratings Delta Nov
                  Nov 2008 Nov 2007 Language Nov 2008 2007
                  1 1 Java 20.299% -0.24%
                  2 2 C 15.276% +1.31%
                  3 4 C++ 10.357% +1.61%
                  4 3 (Visual) Basic 9.270% -0.96%
                  5 5 PHP 8.940% +0.25%
                  6 7 Python 5.140% +0.91%
                  7 8 C# 4.026% +0.11%
                  8 11 Delphi 4.006% +1.55%
                  9 6 Perl 3.876% -0.86%
                  10 10 JavaScript 2.925% 0.00%

      You can read the rest of the article here...

  12. Re:Why should I use Perl instead of Python? by berend+botje · · Score: 4, Insightful

    CPAN. 'nuff said.

  13. Re:Such low expectations... by maxume · · Score: 2, Insightful

    It depends on what you call a niche. "People looking for an improved Perl" is arguably a niche. I'm not trying to quibble, I see what you are saying, that the current Perl community is looking elsewhere (or entrenching on 5).

    I guess I was trying to point out that the base community will probably be big enough to sustain Perl 6, so the size relative to other communities isn't something to be concerned about (which is somewhat different than being concerned that the community won't be big enough to provide X).

    --
    Nerd rage is the funniest rage.
  14. Re:Dropping regex as a core lang feature by wootest · · Score: 2, Informative

    The version that brought LINQ was .NET 3.5, with C# 3.0. .NET 3.0 was just the Vista technologies ("WinFX": WF, CardSpace, WCF, WPF and arguably also WTF) and didn't affect any of the languages in any way - just a bunch of new namespaces. .NET 4.0 will deemphasize LINQ to SQL in favor of LINQ to Entities, which hooks LINQ up to Entity Framework, a more solid (but as of yet woefully "1.0") mapping framework on its own. As with everything Microsoft, it'll probably live on for ages.

    LINQ to SQL is more of a joy to use, but it's a joy to use because it has less syntax, and it has less syntax because it tries to abstract less. Entity Framework tries to abstract more (like abstract away most many-to-many junction tables where the connection itself doesn't have properties) to the point where it is intelligent enough to handle joins for you, and it demands you to be far more explicit about lazy-loading data across relationships (which is a good thing). But it's not entirely there yet unless every query *always* produces an instance of a known type from the database.

  15. Re:Why should I use Perl instead of Python? by Daniel+Dvorkin · · Score: 3, Insightful

    No, "Perl or Python?" is more like "C++ or Java?" In other words, they are indeed different languages with different strengths, but the area of overlap is pretty damned large -- you can write programs that do the exact same thing in either language and it really won't make any difference to the end result. Since I switched over from Perl to Python ~6 years ago, I've never found a task for which I would have used Perl that I couldn't do in Python. I'm not saying that there aren't any such tasks, you understand, but I honestly don't think there are many of them.

    --
    The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
  16. Re:Why should I use Perl instead of Python? by ThePhilips · · Score: 5, Insightful

    Besides CPAN, Perl was one of the first languages to integrate advanced data structures - lists and hashes - directly into language itself. And not some half-assed implementation - e.g. C++'s STL or Lisp' lists - but really really good implementation, supported by many standard functions and (most importantly) internal optimizer.

    Last, but not least, Perl is quite well performing. Compromise fitting most tasks: scripts are loaded relatively fast (e.g. compared to Python), yet if you use structures intelligently, it will run very fast.

    All that together, with Perl's pragmatical approach, you have a tool which easily scales from irreplaceable "perl -pe" one-liners to relatively huge projects. And in many cases, huge projects start as one liner scripts. That's where I'm addicted to Perl: if you know what you do, you can write short but powerful scripts in few seconds. And if you need, you can easily improve the one liner into some good tool, usable by other too.

    As noted by many Perl fans (like I am) you do not write in Perl - you think in Perl. It is language without any artificial barriers between you and resources you need to accomplish your task. That's why it is so hard to get off the Perl.

    P.S. Can't compare to Ruby, since I haven't used it. Few examples I have seen before hadn't stroke me as anything radically new or more useful/practical than Perl.

    --
    All hope abandon ye who enter here.
  17. Re:perl is irrelevant by chromatic · · Score: 5, Informative

    Why?

    It's also two keystrokes shorter. What's wrong about borrowing good ideas from other languages? (I'd tell you what's wrong about borrowing bad ideas from other languages, but you didn't ask.)

    You're also years out of date on the string concatenation operator. I leave it as an exercise for readers to form their own conclusions about the accuracy of the rest of your post.

  18. Perl by scsizor · · Score: 3, Insightful

    When they take perl out of slackware ill stop using it. Until then its real handy.

  19. Re:perl is irrelevant by theredshoes · · Score: 2, Interesting

    After reading over the comments on this article and figuring out what I should spend my time on studying is not going to be exactly easy.

    Maybe I should just continue on with OO programming and pick up where I left off and stick with interpreted languages and then onto OOP, instead of functional programming.

    I would think that some functional programming would be useful though. I am guessing if you are familiar with OO and functional it would make you a bit more marketable. Just a hunch.

    If Ruby, Python and PHP have overtaken Perl, it might be better to learn PHP. I will probably end up looking over both though as I go along.

  20. Parrot by DrYak · · Score: 2, Informative

    In addition to what the other /.ers have said, bear in mind that one of the main targets for Perl 6 to run on is Parrot a "one-VM to rule them all" multi language VM.

    Thus, not only will the binding be accessible to Perl, they would be accessible to any other language targeting Parrot VM.

    (Think of something remotely like JVM or Mono/.NET's CLR except that, unlike microsoft's CLR, Parrot is designed from the ground up with all the complexities of modern latest-gen dynamic languages in mind)

    Where the things get even more interesting is that the Ruby community is interested in using Parrot as their main VM.
    So Parrot would also cure Ruby's problem at the same time.

    Also, some of the python users are interested in creating yet another python implementation targeting parrot. And some fans are trying to create a PHP compiler for Parrot. Haskell coders are also involved a lot in the development of both Perl6 and Parrot. Thus Parrot has indeed serious chances of becoming the central interconnection point for lots of modern dynamic languages.

    --
    "Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
  21. Look at actual available jobs! by rubypossum · · Score: 2, Informative

    Look at actual available jobs. Not silly popularity contests. Do you honestly believe Delphi is more common than Javascript??

    --
    I have a theory that the truth is never told during the nine-to-five hours. - Hunter S. Thompson
  22. Perls sense of Community vs C++'s anti-community by CuteSteveJobs · · Score: 2, Insightful

    I'm a C++head and I've a friend who is a Perlhead. One thing I really envy about Perl is the sense of community; you get the feeling they're all in it together, and CSPAN gives them a massive library of contributor functions. Stuff I have to write in C+++, he can just reach into CSPAN and find a module, well documented, all ready to go.

    Now compare that with C++. We've finally got BOOST.ORG which is supposed to be C++'s answer to CSPAN, but its too little too late. Well, maybe not too little, but it's tiny. There's just too much function it doesn't have. So what can you do? If you need some function you can google around to find a library someone else has done, but since C++ never dictated things like geometry or template libraries (STL was an unpopular pig at first, so many codeshops rolled their own instead). Everything is different. The standard of documentation for open libraries isn't great; you're lucky if you get any doc at all, and usually you'll have a few poorly strung together test programs you need to reverse engineer. Despite POSIX, portability is still a problem. Microsoft C++ doesn't like GNU C++, and this affects packages which you wouldn't think would have any OS dependent code at all (e.g. NOVA).

    But worst of all, what C/C++ code there is out there was smithed in the days of "I will get rich off this hundred line program ha ha royalty holidays forever". Nearly everything has a non-commercial clause. Even the most piddling things or everyday stuff like triangulation. Where does that leave you? Well you can get a payware library like Alan Murthra's Polygon Clipper library for which he charges a whopping $2K a license. Prices most of us out of the market (an educational, no-profit exemption is useless). ie. GTFO. So in C++, almost always, you'll find yourself rolling your own code. And when people roll libraries, they're seldom open-sourced. There are a few honourable exceptions; LIBPNG, LIBJPEG, LIBZIP, FFTW. But these are few and far between.

    I truly envy Perl. I'd like to blame the C++ Community for not doing an equivalent of CSPAN sooner, but there is no community to blame. I welcome Boost, but it has such a long way to go. Really what C++ misses is community.