Forgot your password?
typodupeerror
Christmas Cheer Perl Programming

The Perl 6 Advent Calendar 160

Posted by timothy
from the possibly-recognizable-tune dept.
An anonymous reader writes "Larry Wall wasn't joking when he said that Perl 6 would be ready by Christmas. Perhaps not this Christmas, but that hasn't stopped a group of people (including head Rakudo developers Patrick Michaud and Jonathan Worthington) from putting together an Advent Calendar, featuring one cool Perl 6 feature every day until Christmas. Topics currently covered include how to get and build Rakudo (the most actively developed and progressed implementation of Perl 6) and the new Metaoperators. For those wondering when Perl 6 will be finished: Rakudo will be having its official 'production release' (dubbed Rakudo Star) April 2010."
This discussion has been archived. No new comments can be posted.

The Perl 6 Advent Calendar

Comments Filter:
  • Re:still relevant? (Score:4, Interesting)

    by bsDaemon (87307) on Sunday December 06, 2009 @04:08PM (#30345442)
    Perl 6 is NOT Perl 5. Perl 5 has been under active development, introducing several new features. CPAN is constantly getting new libraries and whatnot, which and its possible to throw together quick hacks and elegant solutions in Perl, depending on what you want to do.

    Maybe Perl is more for a systems administration language (it started out that way) than a software development language, but that's what I need, and that's why I like it. Perl combines the features of awk, sed and shell scripting with those of other languages as well, wraps them up in a C-like syntax, but removes all the hard syntactic bits of C that make it harder for processing strings, or just generally cumbersome.

    For me, Perl 5 is perfect. It's pretty much the language that I would have designed if I designed programming languages -- it i well suited to the tasks I do, the problems I tackle, and is expressive in the same way that I think about writing code. That said, I don't give a flying fuck about Perl 6 at all and really have no interest in it at all.
  • by bcrowell (177657) on Sunday December 06, 2009 @04:12PM (#30345484) Homepage

    I do most of my coding in perl 5. Perl 5's implementation is rock-solid, and CPAN has an absolutely fantastic selection of useful modules for perl 5.

    If I was going to change to something other than perl 5, I would need some motivation. The clearest motivation I can see is that OOP in perl 5 is ugly and bolted on.

    With that motivation, I have dabbled in ruby enough to write one nontrivial app. The thing is, perl 5 still beats the heck out of ruby in terms of implementation and libraries. As an example of this, in my ruby app I wanted to use some regex features that were not available in ruby 1.8, so I ended up using ruby 1.9. But ruby 1.9, and its regex engine, are relatively raw and buggy, and I ended up having serious problems that I had to work around. (Yes, I submitted a bug report. No, it hasn't been fixed yet.)

    AFAICT, the main advantage of perl 6 over perl 5 is the same as ruby's main advantage over perl 5: OOP is implemented in a nicer way. The thing is, the disadvantages are even more magnified, because it's so raw and incomplete.

    My current reaction to the situation is to plan on continuing to code in perl 5 until, say, 2015, and then check back to see how much ruby and perl 6 have improved by then.

  • Re:still relevant? (Score:5, Interesting)

    by jepaton (662235) on Sunday December 06, 2009 @04:50PM (#30345736)

    Yes, Perl is still relevant to a number of software developers and systems administrators.

    It is an ideal language for software developers who want to use metaprogramming techniques (code generation; domain specific languages), text processing or data conversion, or automation of software development process. Perl 6 will have a full grammar engine (for parsing - like having YACC/BISON built in) which will make text processing even easier than before. The use of a scripting language for these tasks leaves the source code more accessible than compiled languages, which is an advantage to software developers who can adapt the code more readily than a compiled project.

    Whether Perl 6 will be used much for primary software development I don't know. My day job is C programming for embedded systems where Perl is not suitable. Desktop programming is more likely to be in C++ or C# where the standard libraries are huge and the software development ecosystem is more developed.

    The primary audience for new Perl, in my opinion, is expert software developers who need a powerful/succinct language to implement solutions to problems in the manner they think. Perl 6 therefore supports just about every programming paradigm known to mankind. What makes Perl great for software gurus is what makes it an awful language for programming newbies.

    I will be learning Perl 6, not because I will use it much, but because I will discover new ways to think about problems. Oh, and it'll be fun.

    Jonathan Paton

  • by ThePhilips (752041) on Sunday December 06, 2009 @06:13PM (#30346390) Homepage Journal

    It's not going away, certainly, but its relevance to the future of computing may be somewhat limited despite its technical merit.

    That's silly. Programming languages always were and will always be transient.

    Compare Perl1 to Perl5 (that actually easy since change logs are delivered with every Perl version) and see how language have changed over the time. Like-wise PHP or even C.

    Languages evolve along with tasks they are used to solve. Sometimes obviously a branch of evolution falls off and language becomes a thing of past. And that can happen to any language, because we still can't predict with certainty problems of tomorrow.

    Corollary, niche languages have staying power coming from the niche they occupy. Because niches evolve at much slower pace compared to mainstream technologies, thus has lower risk of being forgotten fast.

    And I personally do not think that Perl has its own strong niche. Probably only a "*NIX shell on steroids" - that's how I use it. As long as *NIX shell would exist, I would use Perl to automate large chunks of logic and information analysis which are hard/impossible to do in shell, but do not justify writing/maintaining a C/C++ program for.

  • by wayland (165119) <wayland@w3.14159ayland.id.au minus pi> on Sunday December 06, 2009 @06:24PM (#30346506) Homepage
    To me, the things that keeps me coming back to Perl 6 is that it will have built-in grammars.  That may just be because of the kind of apps I try to write, though. 
  • by RDW (41497) on Sunday December 06, 2009 @06:54PM (#30346762)

    Well, the first line of the first Google hit for 'Perl 6':

    http://dev.perl.org/perl6/ [perl.org]

    says:

    "Perl 6 is a new language. Perl 5 and Perl 6 are two languages in the Perl family, but of different lineages. There is no current release schedule for Perl 6."

    Some people, of course, may still find this confusing. These people should use Python :-)

    A longer answer (together with several chapters of new Perl 6 book written by some of the developers) is here:

    http://cloud.github.com/downloads/perl6/book/book-2009-11.pdf [github.com]

    "Some might ask, 'Why call it Perl if it's a different language?' Perl is more than just the vagaries of syntax. Perl is philosophy (there's more than one way to do it; easy things easy, hard things possible); Perl is custom (unit testing); Perl is architectual edifice (Comprehensive Perl Archive Network); Perl is community (perl5porters, perl6-language). These are things that both Perl 5 and Perl 6 will share to varying degrees. Also, due to Perl's habit of stealing good ideas, Perl 5 and Perl 6 will converge in some areas as Perl 5 borrows ideas from Perl 6 and vice versa."

  • Re:Still not APL (Score:1, Interesting)

    by Anonymous Coward on Sunday December 06, 2009 @07:15PM (#30346940)

    Actually, it's because he correctly assumes that it's easy for two different perl programmers to use different styles and subsets of the language. Perl makes it easy to write code that's hard to understand unless you're the original author (a similar thing can happen with C++), and when that happens you'd better hope the documentation is ok.

  • by Anonymous Coward on Sunday December 06, 2009 @08:24PM (#30347500)

    Uhm, go to http://search.cpan.org/ and find anything you want. With a demonstration in the synopsis, and everything is installable with a robust command line tool that (sometimes is too) verbosely states any problems. It also has built-in error reporting on test failures, so you can interact with module authors very easily.

    I can't respond to Ruby in any way that isn't flamebait. I really, really hate gems -- when it works, it works great. When it fails, I can never figure it out. I will leave it as that.

    As far of higher quality, that could be it. Perl has had a long history, and with an open door philosophy a lot of really terrible code ends up on the CPAN. However, if you take a quick look at some of the Perl efforts to describe the high quality modules (Enlightened Perl Organization's Task::Kensho) it's all hand picked and vetted by hardcore perl hackers.

    Here's some things in Perl that I'm genuinely surprised more people haven't jumped on:

    Moose (Class::MOP) giving you an entire meta-object protocol to get closer to functional programming
    DBIx::Class - a relational ORM that truly understands SQL, with some really amazing features.

  • by Anonymous Coward on Sunday December 06, 2009 @10:49PM (#30348618)
    There is a huge difference between languages like Lisp and Haskell, and languages like Perl, Python, and Ruby. The former are languages that allow for high order functions that manipulate the language, and allow full abstraction without arbitrary limits.

    For example, when object-oriented programming became a new and exciting thing, Lisp programmers immediately started making their own object system. To do this, they did not need to change the language in any way, they could simply create it within the language because Lisp has such powerful abstraction and metaprogramming abilities.

    Today Lisp is one of the two languages that the creator of OO programming (Alan Kay) will acknowledge as fully embodying proper OO programming. He also says that it's the single most important programming language ever created.

    Compare that to languages like C++, Perl, Python, etc. who no one with any respectability will even acknowledge as having a well-designed object system. Their object systems are incomplete, hacky, and ridiculous. However, in Lisp, building such things does not even involve changing even a little bit of the core language, and the syntax fits perfectly with the rest of the language.
  • Perl is Elegant (Score:5, Interesting)

    by tjwhaynes (114792) on Monday December 07, 2009 @11:51AM (#30353684)

    Perl is one of those languages that most people meet in passing because someone else has hacked up a script to get something out of some file. Which is sad, because understanding what makes Perl different from other languages and why it is often a better choice for wrangling data isn't going to be obvious in one lousy foreach search-and-replace hack. And most people exposed to perl scripts in this manner fall over on the difference between scalar and list context and never discover why perl expressions like $lookup{$term}++ will save them years of work, while making their analysis scripts go faster.

    I write Perl modules day in, day out to cope with processing DB2 internals in an attempt to model and improve them. Object-oriented Perl makes this easy, fast and effective. Closures (which I'm sure aren't understood by 90% of the Slashdot community) back this up being able to create anonymous subroutines with data attached which can be processed later. Perl is also effective for parallel task analysis - I have modules for jobserving many tasks across multiple machines and Perl threads make it easy to fire a task off while something else is done.

    Perl is an essential part of data analysis for any serious volume of unstructured data. However, I'm not unhappy that it is little understood. Perl makes in the impossible merely hard. If everyone knew how to leverage Perl, I wouldn't have so much fun.

    Cheers,
    Toby Haynes

Are we running light with overbyte?

Working...