Larry Wall Unveils Perl 6.0.0 | Hacker News Reader

Larry Wall Unveils Perl 6.0.0

pigdog.org

809 pointsMilnerRoute319 comments

I honestly did not expect to see the day Perl 6 gets finished. This must have been one of the most difficult - if not the most difficult - births in the history of programming languages.

At work, I have been using Perl 5 increasingly often over the past two years, mainly because handling unicode in Python 2 is not a lot of fun (and I still haven't come around to learning Python 3), and I have rediscovered why I used to like it so much.

So far I have not looked into Perl 6 seriously, because I did not see the point to do so before it was finished. Guess I know now what I'll be doing this Christmas. :)

Also, you gotta love Larry for quotes like this one: "This is why we say all languages are religious dialects of Perl 6..."

I share the same sentiment. I am so glad to see it finally formally launched. Now, to dig in to Perl 6!

Oh, it didn't get finished. Perl 6 is just getting started!

> I still haven't come around to learning Python 3

I'm not using it everyday yet either, but it's not a whole new language. More like just a few cleanups to sensitive portions of the API.

I would love to see a concise document with the differences.

https://docs.python.org/3/whatsnew/3.0.html

http://sebastianraschka.com/Articles/2014_python_2_3_key_dif...

same here, had to do a double take when i saw the headline in my email. it's been so long perl 6 has become somewhat of a running joke.

What is there to learn about Python 3? It's just a relatively small, but backwards-compatibility breaking, update.

This: https://docs.python.org/3/whatsnew/3.0.html

Doesn't look small and I already saw several things I was using that have changed behaviour. Someday I might even learn how to use them. :)

"At work, I have been using Perl 5 increasingly often over the past two years, mainly because handling unicode in Python 2 is not a lot of fun (and I still haven't come around to learning Python 3),"

Why?

From what he's saying, it's because of Perl 5's excellent Unicode support.

You can build Perl6 and try it right now if you want, see my [early Perl 6](http://g14n.info/2015/03/early-perl6/) article for detailed building instructions.

Or use rakudobrew. http://codeselfstudy.com/wiki/Perl_6

I don't know Perl, but I saw the presentation and was blown away. Installed it today, and definitely will try building something with it soon.

These instructions show how to build the Rakudo 2015.03 release, 2015.09 is the current one.

The link I posted should install the latest version. http://codeselfstudy.com/wiki/Perl_6

Tiny correction: I heard it as "all languages are really just dialects of Perl 6," which makes a bit more sense in context. Either way it's a cute Wall witticism, of which there were many that night. Word has it that there will be a video in a couple of weeks, at which point you can judge for yourself!

If you haven't had the time to learn the transition from Python 2 to 3, don't expect to find time to transition from Perl 5 to 6. Perl 6 is orders of magnitude more different from Perl 5 than Python 3 is from Python 2.

Perl 6 is not different, its a new language. You don't transition from Perl 5 to Perl 6. You learn Perl 6 as a new language and use it.

That's completely different compared to the case of Python, where Python 3 is a continuation from Python 2. But breaks backwards compatibility with the entire ecosystem. Bulk of the language remains same, you are migrating non backwards compatible parts.

What's this deal with people having to learn Python 3? For most of the things you do there is literally no practical difference.

Exactly! The only real reason I was not using Python 3 was library support, but now things have changed: https://python3wos.appspot.com/

Unfortunately unicode in Python 3 is not necessarily better. See http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/.

Both Perl 5 and Python 3 are built with the assumption that a "character" is what the Unicode standard generally refers to as a "character".

This is a serious problem and will I suspect one day be understood to be the biggest long-term mistake made when designing Python 3.

I wrote a comment about this a few months back at https://news.ycombinator.com/item?id=9791211 (see second half of the initial comment and then the followups).

If you are anal about getting every edge case correct, Unicode is a straight up nightmare to support.

Even in Perl's supposedly superior support has issues. See how deep the rabbit hole goes by reading the first response to the question here:

https://stackoverflow.com/questions/6162484/why-does-modern-...

There is really no way for a simple program to account for all of those possible edge cases. Something as simple as a print of a string can be a minefield depending on what is in those characters. And it's not like the old days where you could safely filter out all non-printable characters to avoid most problems. Have you considered how your formatting is going to look when people intersperse Right to Left words in your output for example?

> There is really no way for a simple program to account for all of those possible edge cases.

The post to linked you contained a piece of boiler-plate code which accounts for said cases.

> Have you considered how your formatting is going to look when people intersperse Right to Left words in your output for example?

There are modules to handle this. It of course means that you have to stop using non-Unicode-aware functions like `sprintf`.

The boilerplate on there is only a start. Any time you read or write a Unicode string, or do any manipulation of the string, you need to consider possible edge cases, and they can be nightmarish.

Consider something as simple as outputting zero padded numbers (so they form a nice column in the output), except that the numbers might not be Arabic, zero might not be 0, they might not be written in the direction you expect, and padding might not even make sense. This is how you go crazy.

> One of the most impressive things Larry demonstrated was the sequence operator, and Perl 6's ability to intuit sequences.

    say 1, 2, 4 ... 2**32

> This correctly produced a nice tidy list of just 32 values -- rather than the 4,294,967,296 you might expect.

Someone with more time than me needs to find an IQ test that is based around sequence questions like this and plug them all into Perl 6. So we can find out what Perl 6's IQ is and whether it has achieved AI.

Try putting two spaces at the beginning of a line to stop HN from eating the asterisks.

  > say 1, 2, 4, 2**32

Thank you. I spent far too long trying to figure out what sequence would start "1, 2, 4" and then have 232 be the 32nd item.

Oops, sorry! Fixed it.

Don't be ashamed. http://oeis.org/search?q=1%2C2%2C4%2C_%2C_%2C_%2C_%2C_%2C_%2... does not know it, either, it gives me http://oeis.org/A115346

That has 46 terms before hitting the right pattern.

It also gives http://oeis.org/A188668 which has only four terms before hitting 1, -2, 4, ..., -232.

I guess one could try and tweak either to get a matching sequence, but I don't see a trivial way to do it that is mathematically 'nice'.

It is easier to start with http://oeis.org/search?q=0%2C0%2C1%2C_%2C_%2C_%2C_%2C_%2C_%2..., though.

It gives me http://oeis.org/A242067 "Number of triangular numbers between n^2 and n^3 (excluding the bounds)."

So, this sequence 'must' be "n plus number of triangular numbers between n^2 and n^3 (excluding the bounds)."

And therein lies the problem with Perl.

> This correctly produced a nice tidy list of just 32 values

33, not 32, right? (20 through 232, inclusive)

Yes, 33 (although HN ate your double asterisk, like it did the original comment's initially).

    # perl6 -e 'say +(1, 2, 4 ... 2**32).elems;'
    33

This is cool but I still don't get how it is able to distinguish between linear, power, exponential, etc. sequences so easily. Would be incredibly interested in reading about the technology they're using for this and how complex it can get.

Linear and geometric sequences are auto-detected, for anything else you'll need to provide a function to compute the next element:

  2, 4 ... *        # linear
  2, 4, 8 ... *     # exponential
  1, 1 ... *        # constant
  1, 1, * + * ... * # Fibonacci

The last expression is equivalent to the more verbose variant

  1, 1, -> $a, $b { $a + $b } ... *

that makes use of an 'pointy block' (ie lambda function) instead of the Whatever-*.

Ah so it's similar to the haskell list comprehension syntax, converted to a point-free form (and with added guessing/defaulting due to the ambiguities therein).

    [x*2 | x <- [1..10]] -- linear
    [2^x | x <- [1..10]] -- exponential
    [1 | x <- [1..10]]   -- constant

IIRC haskell list comprehensions can't do fib without naming the list so it can refer to itself. OTOH, these perl list comprehensions seems unable to express things that combine values from several lists, eg:

    [ x*y | x <- [2,4..8], y <- [-1,0,1] ] -- [-2,0,2,-4,0,4,-6,0,6,-8,0,8]

Course, haskell also has a weak form of [x1,x2..xn] syntax for a linear sequence, as in [2,4..8]. That's always felt a bit of an unnecessary wart in haskell to me, although the simpler [x..y] and [x..] are very handy syntaxes.

TBH, I almost never use list comprehensions either, preferring regular functions, and the list monad or applicative.

    (*2) [1..10] -- linear
    (2^) [1..10] -- exponential
    repeat 1     -- constant
    fibs = 0 : 1 : zipWith (+) fibs (tail fibs) -- fibonacci obvs
    (*) <$> [2,4..8] <*> [-1,0,1] -- same as [ x*y | x <- [2,4..8], y <- [-1,0,1] ]

Fwiw, the Haskell:

  [ x*y | x <- [2,4..8], y <- [-1,0,1] ]
  -- [-2,0,2,-4,0,4,-6, 0,6,-8,0,8]

could be translated to the Perl 6:

  [2,4...8] X* [-1,0,1]
  # (-2 0 2 -4 0 4 -6 0 6 -8 0 8)

Alternate pointfree Haskell syntax:

    (*) <$> [2,4..8] <*> [-1, 0, 1]

    liftA2 (*) [2, 4..8] [-1, 0, 1]

Sure, but that perl is not using the ... list comprehension syntax to combine the lists.

This is so very Perl. I guess this is Perls answer to list comprehensions.

I would assume that it has those too. Due to the main implementation being Pugs for a while, the language absorbed a lot of Haskellisms (chiefly laziness).

That's interesting, I always figured Python's list comprehensions where their answer to Perl's map and grep.

But in direct answer to your question, no, but it's part of the answer[1].

1: https://en.wikipedia.org/wiki/List_comprehension#Perl_6

gather/take is more the general Perl 6 take on list comprehensions.

This would probably be useful.

http://oeis.org/

Douglas Hofstadter proposed something like this long ago, only the task was to find analogies in sequences. For example, what number in the sequence

    1 2 3 4 5 4 5 4 3 2 1

corresponds to the second 3 in this one?

    1 2 3 2 3 2 1

If that seemed too easy, what's the corresponding number in this one?

    5 4 3 2 1 2 1 2 3 4 5

How about this?

    1 2 3 4 5 6 7 6 5 4 5 4 3 2 1

With things like this, it makes me glad I write C++ (and that gets bashed enough!). I do not miss the days of maintaining a Perl codebase (and trying to decipher what on earth code was doing). This is insane.

Perl is a language sufficiently different from the main bulk of languages that one must make an earnest effort to learn it before one can read it. Your complaint is similar to someone declaring Japanese insane just because of the way its writing system looks like gigantic and erratic complexity to the inexperienced.

Ah yes but it is mainly because many languages borrow C-style syntax so you can understand it without many brain gymnastics.

You are correct, however. I did try learning Japanese and was just as unsuccessful at that as with Perl; I did maintain an old Perl codebase at one point and learned enough to get by but I would never jump at the opportunity to do it again!

How much of the reference docs and available books did you read? Or did you, like many, just read code and hunt for the bits that weren't obvious?

To be fair Japanese writing is insane and they know it. It's far too difficult.

You pretty clearly have an emotional attachment to Perl, which is sort of lovely to see, but it's causing you to be undeservedly condescending to people who don't have that attachment, which is not lovely.

> to be undeservedly condescending ... is not lovely.

It seems like you have just diagnosed someone's behavior without them asking for a diagnosis and your diagnosis is that they are being condescending. See the problem there?

And this followed what some might call undeserved condescension: "Pulling out my hair in frustration from trying to deal with Perl written by other people saved me all manner of haircut money in the 90s.".

If you think I'm being undeservedly condescending, and this isn't lovely, perhaps we can find another way to talk about Perl 6?

You can torture my words rhetorically to score emotional points, but I don't know what you think you prove by it.

If you find my jocular expression of my very real experiences with Perl to be condescension, I'm going to have to let you know that I don't believe Perl to be all that worried about it, incapable as it is of having an emotional state.

I'm sorry if my comment seemed condescending, but it is a sad fact that many people learned Perl only by reading code and looking up small bits and pieces they don't immediately grok (instead of turning towards and consuming, complete and well-written learning resources both in the perldoc references and books) and then walk away with completely skewed impressions and share them with the world at large.

I wish i had a more polite way of pointing this out when people make complaints, but i have not found one yet. Maybe you have a suggestion?

So what is the advantage of using a language that is hard to learn and hard to understand?

It's hard to learn, but not necessarily hard to understand. That hard learning experience theoretically pays dividends in productivity later as you and more succinctly and quickly express your intent.

It's not hard to learn, as evidenced by all the people writing functioning perl after reading only a few scripts. It just takes a long time to learn entirely. ;)

>and trying to decipher what on earth code was doing

I have the same feeling when gcc shit itself STL compiling errors.

I still have that, but thankfully get to use clang instead which has more helpful messages (although you do need to look about 5 errors deep in the error tree to get to the nub of the problem).

This is what comments and docstrings/doctests are for.

The range operator (..) is also pretty cool, since we're all lazy now. Here's an infinite lazy list of prime numbers in Perl 6 (declared as a constant because you presumably don't want to change 'em):

    constant primes = grep { .is-prime }, 1 .. *;

Congrats to the perl community. We should keep an open mind and learn from what they have accomplished.

If perl 6 turns out to be useful for the larger software engineering community (and is more widely adopted), this is wonderful. If not, then we still have another interesting language in the great river of interesting tech things.

Either way, the perl community will continue to do what it does best!

Some languages are for earning your daily bread (like Java, or Objective-C). Some, like Haskell, are for intellectual pursuits.

Perl is for poetry. For seeing the impossible and going back.

You Sir, have the heart of a Poet!

One of the best summaries of Perl I've seen. Thanks!

Code is executable poetry. It moves the hearts of computers.

> ++; # An anonymous state variable, for very fast loops

Perl, never stop being you

If I'm not mistaken, that probaby should have read $++;

This. This thread right here is the magic of Perl.

I also attended the unveiling yesterday; If I remember correctly, I'm about 95% sure your assumption is correct.

Correct. $ is an anonymous scalar (which autovivifies to 0 and increments in $++). There's also anonymous array @ and anon hash %. The hash form you can see in action here, in the one-liner mad-libs code: http://rosettacode.org/wiki/Mad_Libs#Perl_6

Also:

  react { whenever }	# Code runs when a condition is met.

I can only think this must be a generic https://en.wikipedia.org/wiki/COMEFROM. It is sure going to create some viciously subtle bugs.

Cf http://www.jnthn.net/papers/2015-spw-concurrency.pdf

From pages 56 and 57:

> Perl 6 has an asynchronous looping construct called whenever ... runs whenever a value arrives ... can live in a ... react block (works like entering an event loop)

  my $code = supply {
    whenever IO::Notification.watch-path($src-dir) {
      emit .path if .path ~~ /<.pm .p6> $/;
    }
  }

So now, whenever something in $src-dir changes and its path ends with '.pm' or '.p6' that path will be emitted -- which in this case means it'll be pushed to any construct pulling from $code. Such as:

  react {
    whenever $code -> $path {
      say "Code file $path changed!";
    }
  }

This is probably the most interesting link in this entire thread.

The "react" keyword is just a channel subscription, and inside it has a pattern matcher. Channels are first-class citizens, and you're encouraged to chain channels rather than falling into callback hell. It's like Go and Ruby had a child.

If anything piqued my interest in Perl 6, it was this.

INTERCAL finally weeps for joy at being able to claim Perl 6 as a spiritual descendant.

Nice to know I'm not the only one who thought that. Now they just need the PLEASE keyword.

That construct reminds me most of callbacks: you define some code, and register it to be called in certain circumstances.

One of my favorite new features is phasers[1] (loop flow control shortcuts), and as a subcomponent of that, how CATCH[2] is implemented as a phaser so it's within the block that had the error still has access to the variables in the same scope.

1: http://design.perl6.org/S04.html#Phasers

2: http://design.perl6.org/S04.html#Exception_handlers

Perl 6 appears to be the SNOBOL of our times, with grammars being a first-class lex, plenty of functional idioms, APL influences and a reasonable object system.

Given how much of contemporary programming is munging, I can see it really picking up steam.

Given how long it took to replace Perl 6, and the fact that I (and most others I know) have moved onto other languages, I can't decide if I'm more (a) surprised, (b) impressed, or (c) indifferent.

Kudos to Larry for sticking with it, and for (I'm sure) introducing interesting ideas into the world of programming languages. That said, I have to wonder how many people will really use Perl 6 in their day-to-day work, and how many will look at it as a curiosity.

For me, I'm afraid that Python and Ruby have replaced Perl, despite more than 10 years in which Perl was my go-to language. Maybe I'll return to it, but I sorta doubt it.

I don't know, there's something to be said for a language that isn't a moving target. You learn it really well inside and out and your effort isn't wasted as it is thrown away for some hot new fad language in a couple of years or find that everything you learned is now deprecated because the authors decided that functional programming is the bees knees.

I've found these resources helpful for learning Perl 6:

http://learnxinyminutes.com/docs/perl6/ is a pretty good intro to Perl 6 if you just want to jump into things.

http://www.jnthn.net/papers/2015-spw-perl6-course.pdf is more slowly paced but provides greater detail.

Also, the people in #perl6 on Freenode are all awesome and are usually quick to help beginners unless they are in the middle of fixing some crazy bug.

Empty string, array, and hash are falsey? Ruination! This is terrible! Also, types are falsey? What sense does that make?

Perl 6 has slides, IRC, a skim-through (learnxinyminutes), reference docs, examples, but alas no solid tutorial. This, IMO, will be a major problem if it persists until Christmas.

I'm really surprised this site is the source y'all chose to upvote. Not only was the second-newest article published in 2012, they also have an assortment of other questionable content[0][1]. Advertising from rotten.com and a category named "Jonny Jihad" are also professional touches.

I mean, whatever floats your boat, but HN, is this really one of your go-to trusted news sources?

[0] http://www.pigdog.org/in_the_pink/html/interview_with_a_stri... [1] http://www.pigdog.org/pooniedog/

What source would you recommend?

Here are the official words from Larry. There will be 2 beta releases and the major one in December. Larry goes by the handle TimToady http://imgur.com/1Vrpl2G

That source is nowhere near as informative.

Its a snap of today's perl6 IRC log . http://irclog.perlgeek.de/perl6/2015-10-07#i_11330785

If you doubt the legitimacy of the post, I can confirm there was an event[0]. I was also there, and the blog post syncs up to what I remember from the event. I am surprised there isn't some official post event write up from the event organizers, though.

http://perl6releasetalk.ticketleap.com/perl-tech-talk/detail...

When I first started reading this I thought the site was satire, though the article itself (ignoring the site) certainly didn't feel that way.

I was delighted to see pigdog.org appear on the front page of HN; I thought it had died years ago (and I guess it mostly did). The Pigdog Journal was a Big Deal for a certain clique of nerds/technologists in the late 90s/early 00s. (You know, when Perl was also a Big Deal.) The web was a smaller, zanier place then; for those that remember that web, pigdog.org brings a wave of nostalgia.

I edited my snark, but I was going to ask if this was "just a Perl thing?"

I guess it's just a Perl thing...

It is neither go-to or trusted but it is one of the best places on the Web.

Another blog reporting from the event:

"The Night Larry Wall Unveiled Perl 6"

http://www.10zenmonkeys.com/2015/10/06/the-night-larry-wall-...

So is this a real thing? I've never seen this pigdog website before, it's second newest article was published in 2012, and there's no mention of this on the perl 6 home page or in the perl 6 announcements mailing list..

At FOSDEM earlier this year, Larry gave the presentation they describe, and said that they were expecting a beta release at Christmas this year. So the general concept is legit, regardless of the site.

I don't see how that makes this look any more legitimate. The FOSDEM website says they had over 5000 people attending, so it's not like Larry's talk was a big secret. And Perl 6 has been right around the corner forever, so a fake "Perl 6 is released" page could seem timely and legit in concept at almost any time in the last 10 years.

Even if it's true, if they want anybody to pay attention they should announce it on perl6.org or at least a more professional looking page. If I were at work and opened a page with rotten.com banner ads, and "software jihad" all over the place, I'd close it immediately and hope nobody saw it.

Not being privy to the talk, my assumption was that the final shipping feature list was solidified, and that's what was being announced. It's still due at Christmas, and that was already known. I think the article's meaning was somewhat ambiguous with the title, and HN just ran with it. Nothing has been released (but apparently there's two beta's officially planned now, the first of which is in a week or so).

I don't mean that it makes the site legit. I just mean "Perl 6 is indeed coming this year."

"craigslist is pleased to host Larry Wall Presents: Perl 6! Perl 6 has been a long time coming—some might say too long—but now here it is..."

http://perl6releasetalk.ticketleap.com/perl-tech-talk/detail...

> if they want anybody to pay attention they should announce it on perl6.org or at least a more professional looking page.

Right. I think that's the intent -- this christmas.

But Larry can't stop someone posting an article that incorrectly suggests that 6.0.0 has been launched and then someone else posting an HN article/thread that you and lots of others (me too) decide to participate in.

Hey, even Peaches is wearing a Camelia suit on stage!

https://twitter.com/MarguerinLDN/status/651675808122060800

Congratulations Larry and the Perl 6 community!

From what little I've played around with the language in the past, I really like it, and I'm glad the community can put the "still in development" talking point behind it.

Also, one of my favorite things about Perl 6 is that the Rakudo interpreter prints some of the nicest error messages I've ever seen. It actually offers suggested solutions, and it points out Perl 5->6 migration gotchas.

As far as I understand, Rakudo is a compiler, not an interpreter. It compiles perl 6 source files into bytecode that is executed by a VM.

Yeah, you're right. Total brainfart there.

Perl was the first programming language I ever used, and i think 6 was being worked on even then. I've moved on to ruby as my goto, but my (limited) memories of perl are fond, and I'm happy to see its still moving forward.

Every time I try and write ruby I end up giving up because the OO is boilerplate heavy and restrictive compared to Moo/Moose.

Basically "No method modifiers and I have to write my own constructors? Really?" always drives me away within a few hours.

Method modification is trivially done through "alias" and then just redefining the method in Ruby, if you re-open the same class. If you subclass, then "super" is sufficient. I'm curious what you actually mean here.

As for writing your own constructors, you only need to do so if you actually need to initialize something, and since instance variables can be used without having initialized them in a constructor (they'll just default to nil), I'm curious what you mean here too.

> Method modification is trivially done through "alias" and then just redefining the method in Ruby

I don't know how to convert this into ruby then without needing to manually gensym a bunch of names:

    use Class::Method::Modifiers;
    
    sub foo { 2 }
    
    before foo => sub { warn "before foo 1" };
    
    around foo => sub {
        my ($orig, $self) = (shift, shift);
        warn "around foo";
        (1, $orig->$self(@_), 3);
    };
    
    before foo => sub { warn "before foo 2" };

> As for writing your own constructors, you only need to do so if you actually need to initialize something

Which is required if you're going to use value objects as much as possible rather than spraying mutable state everywhere.

> I don't know how to convert this into ruby then without needing to manually gensym a bunch of names

Sounds like you want something like: https://github.com/nicknovitski/modifiers

> Which is required if you're going to use value objects as much as possible rather than spraying mutable state everywhere.

Using Ruby's Struct class for this often avoids needing explicit constructors.

Except that package doesn't provide before/after/around.

What I really want is CLOS. But the closest in perl/python/ruby/javascript is Moose/Moo.

There's also, btw, a moosex gem where some rubyists are trying to port the perl stuff - but Moose/Moo are pervasive in modern OO perl whereas most existing ruby code is done the ugly, boilerplate-y way.

You can do this. I tried to draw up a quick gist, but I am late, and I've been writing too much Rust...

The basic idea is this:

  module Mst
    def self.included(base)
      # define a method on base using define_method named :before, which takes an
      # argument and a block
        # in that method, you grab the method with that name, using .method()
        # you then define a new method, named method, which calls the block and
        # then calls the original method
    end
  end

  class Foo
    include Mst

    def test
      puts "test"
    end

    before :test do
      puts "before"
    end
  end

Module named after you. You can see how the logic only changes a bit for after and around. You could then wrap this up as a library, and all you'd need to do is the include.

http://api.rubyonrails.org/classes/ActiveSupport/Callbacks/F... has an example, I think.

That's really cute.

I hope, however, that you can understand from the POV of somebody who keeps being driven off ruby by ruby being too much work, that "you could make it less work by first porting all the perl5 libraries that make perl5 OO more pleasant" isn't really a convincing solution :)

One of my Twitter followers posted a gist: https://gist.github.com/paulodiniz/39698ac1fe5f62e3180e

Sure, I was just addressing the "I don't know how to do that." Rails offer this for models in certain circumstances, for example.

That's very cute.

Yeah, I was responding to a post that claimed it was trivial; that's cute but not trivial - although it does demonstrate that using 'alias' to rename isn't necessary, which is nice to know.

I can absolutely see how I'd turn this into a full Class::Method::Modifiers re-implementation, so I'll totally stipulate to 'trivial if' :D

I'm not interested in being condescended to, so

mst might speak for himself at another time, but i have a personal reason to post, so i will say this:

Please do not take this conversation as an affront and throw away what has so far come of it. It has shown you, and Ruby at large, an API that has been proven to be good and useful, and the Ruby community has come up with a way to implement it in a generalized way. I hope to someday be able to learn Ruby and use its OO with similar ease and pleasure as i can use the OO system in Perl 5. So please, do not throw this away. It is a valuable chance to do the same thing Perl has done so many times: Recognize something useful and make it your own.

Steve and I had a previous similar conversation; this one got further subject wise, but the original was also a fair few posts deep and we didn't accidentally piss each other off that time.

Pretty sure we'll manage to resolve the confusion shortly.

Wut? I just complimented the code you posted, and changed my mind from "the unconstructive guy upthread said trivial, which it isn't, but steve's been kind enough to give me enough information to see it's trivial if I write a port of CMM, and said port is basically identical rather than requiring the crappy alias approach".

I've genuinely no idea why you think I was being condescending.

I don't know where steveklabnik hails from, but in the US "cute" is sometimes meant with a condescending overtone. I seem to recall you are from the UK (Scotland?) from the last YAPC I was at, so I suspect this is a dialect difference causing a misunderstanding.

Oooh. Yes. In the above comment, "very cute" should be read as being said genuinely in an approving voice with a big grin, and exactly zero sarcasm.

This may be the first time (yeah, English, but do wear a kilt a fair bit) I've ever run into a problem with an American overdetecting sarcasm.

For what it's worth, I completely agree with the "crappy alias" thing, and wrote a lot about this topic back when I was working on Rails full time (example: http://yehudakatz.com/2009/03/06/alias_method_chain-in-model...).

Ruby eventually added `prepend`, which I demonstrated upthread, and is a genuinely generic, in-language solution to the problem you're talking about.

I dug up my original proposal from 2009, which eventually landed in Ruby 2.0: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/...

Hey! Just woke up to this. Sorry, it seems as someone else mentioned,

  That's cute, but $FOO.

is seen as really condescending here. It's literally diminutive, suggesting that something might be small and pretty, but not worth adult consideration for Real Stuff.

Anyway, if that's not how you meant it, I completely understand. Text is hard. No harm, no foul. Sorry for misunderstanding.

Ok, so, on the one hand, I wasn't trying to be condescending, which is why I didn't say 'but' after 'cute' - the 'cute' was a genuine compliment.

On the other hand, the thread started off with "I've already got stuff in perl that does X and it looks like I'd have to write it myself in ruby", then somebody replied with "this already works in ruby, just use alias" then when I provided an example that wouldn't you showed me how to write a library to support said example in ruby.

So I now know much better 'how to write it myself in ruby', and I am genuinely grateful for that, but it still wasn't an answer to the original question so 'cute' seemed like the appropriate compliment.

The actual answer I was looking for seems to be "people who're bad at ruby will always suggest alias, prepend will handle some cases, and then you can write not that much code if you want the other cases, but there's no perl5+Moo quality experience to be had without implementing at least part of it yourself".

Which is totally fine by me, I just need to talk somebody better than me at ruby into implementing it and then try and convince everybody to upgrade :D

(also, if you have a suggestion for a word other than cute that would express "really pretty even though it doesn't answer the question" while seeming positive rather than negative about this fact I'm all ears)

I sat on it for another evening, but I'm not sure of the best word for you, to be honest.

"Neat"?

For what it's worth, the `prepend` API in Ruby, which I advocated for back when I was working on Rails, works pretty nicely:

https://gist.github.com/wycats/0a354a96d00d47fa4e04

Oh, that's even better. Is there an around/after equivalent or are those still best implemented with Steve's thing?

"before", "after", and "around" method modifiers are pretty common in Ruby Aspect-Oriented Programming libraries (AOP has pretty much fallen out of favor for Ruby, but I'm pretty sure at least some of these are still maintained.)

It was not my first language but the memories are fond. It just sat so well on my head by making things you thought of possible with little resistance. Impedance mismatch was minimized. Hard to explain. Became a master text wrangling language by making regex a first class citizen.

My sense, playing with Perl 6, is that it could become a "pro tool" -- very deep and powerful. It needs to mature some (though it is very solid already) and to grow its ecosystem (though it can run much of CPAN via Inline::Perl5).

Those who want to play can install from http://rakudo.org/how-to-get-rakudo/

Larry's talk was a lot of fun, especially the way he zipped around between vi and terminal windows -- no need for presentation software.

A couple of other things that haven't been much highlighted:

- Perl 6 right now runs very well on two back ends: a custom VM and the JVM. It is spinning up a Javascript back end, I think primarily for NodeJS.

- Concrete representations are carefully separated from core semantics, so Perl 6 currently supports native values from C, Perl 5, Python, etc. It should be able to support native arrays as required for high performance scientific computing etc.

Whatever happened to the ParrotVM? I always thought that it was somehow intrinsically tied up with Perl6.

http://www.modernperlbooks.com/mt/2013/02/goodnight-parrot.h...

https://www.ohloh.net/p/parrot (contributor graph at the bottom)

They switched to MoarVM, which was a simplier and much faster rebooted variant of Parrot to get a timely Perl6 release. But it is still open to use any VM as backend.

Currently there are two in rakudo, in parrot can be re-added trivially, e.g. to support other architectures and a better threading model

Junctions and autothreading seem to be importing the core of APL/J: http://doc.perl6.org/type/Junction

(I'm randomly scanning http://faq.perl6.org)

Perl 6 basically hoovered every good programming concept they could think of (and some that ended up being not so good, which have hopefully been shaken out over the last decade). If you want a small language, this is not it. If you want an amazingly powerful language that just allows you to do what you want with a minimum of fuss, pull up a seat.

Whereas Go has gone the other route and jettisoned everything. Not having a ternary operator is a real pain.

One thing Go does well is provide the gofmt tool. There is only one way to format code properly.

Does Perl 6 have something like this?

No, but Perl 5 has Perl::Critic[1], which is a configurable opinionated code and style analyzer. It defaults to using the Perl Best Practices book by Damian Conway, with configurable levels of exactness. You can modify the rules to suit your particular needs/team.

I imagine something on this front will materialize for Perl 6 sooner than later.

1: https://metacpan.org/pod/Perl::Critic

Probably soon.

Perl 5 has a Tidy'ing tool[0], as well as a Lint[1] tool. Both are based on rules created from (originally) Best Practices [2]. These rules of course can be modified to taste, so you can set your own rules/filters before checking in your changes to a repo (or, whatever)

[0] https://metacpan.org/pod/distribution/Perl-Tidy/lib/Perl/Tid...

[1] https://metacpan.org/pod/Perl::Critic

[2] http://shop.oreilly.com/product/9780596001735.do

Perltidy predates PBP by a long time. Perltidy is a bit of a huge mess, and it has its own parsing code and is nearly impossible to hack on. We really need a PPI-based re-implementation.

There was a very interesting submission to HN on why code formatting utilities aren't easy things to write, [0] called, The Hardest Program I've Ever Written [1]

The code of Perl Tidy at least looks pretty good! [2]. Perhaps there's a reason why PPI isn't used, that I'm not famliar with, other than - as you say, it predates it. Perl::Critic uses PPI, yes?

[0] https://news.ycombinator.com/item?id=10195091

[1] http://journal.stuffwithstuff.com/2015/09/08/the-hardest-pro...

[2] https://metacpan.org/source/SHANCOCK/Perl-Tidy-20150815/lib/...

Thanks for the links.

As the current de-facto maintainer of PPI, the answer is rather simple:

P::T predates PPI by almost two years: https://metacpan.org/source/SHANCOCK/Perl-Tidy-20021130/CHAN... https://metacpan.org/source/ADAMK/PPI-0.1/Changes

and:

For the longest time Perl was considered unparsable, primarily due to the two features of function parens being optional, and the argument-slurpiness of function calls being unknowable without introspecting the function reference that ends up being the final one, at runtime. In the most famous example this can lead to a / after a function call being considered either the division operator or the start of a regex; with both interpretations resulting in valid Perl code. It took a while for anyone to come up with a schema in which Perl could be parsed while also being round-trippable. It took PPI a while to get there and be stable, and meanwhile P::T had already become stable itself.

> Finally, there's a way to stop non-identical strings from matching just because they have the same numerical value.

Um, this has been there for decades:

    $a = '123';
    $b = '123.0';
    print $a == $b ? 'y' : 'n';  # prints y
    print $a eq $b ? 'y' : 'n';  # prints n

I read it that way at first, and was going to comment on it, then I figured the point was smart match being able to distinguish, not being able to do your own test.

'eq' does the test you are asking for.

Yes, I'm aware, but when using smart matching (that is, the given/when pair which has had it's fair share of trouble, and is currently experimental after having not been), you sometimes want to be able to distinguish between those types of tests when doing a smart match[1].

I believe the article was referencing this, and so while yes, anyone who knows how to use Perl will use the appropriate operator for the appropriate type of type operation, there are reasons to still want to distinguish what type of match is done by the smart match operator, '~~'.

1: http://perldoc.perl.org/perlop.html#Smartmatch-Operator

Sounds like a v2.0 with feature bloat.

""Any infix operator can be replaced by itself in square brackets..." Later someone asked, "In a world of user-defined operators everywhere, how do you define precedence?" And Larry pulled out is tighter() and is looser(), noting that Perl 6 even has customizable precedence levels. "You can add an infinite number...""

It's been said that most of programming is about managing complexity. I'm unhappy with Perl in general because it makes it really easy to hide complexity. Perl 6 looks like it makes it even worse.

Yes, it looks like an amazingly powerful and sophisticated language, and an amazing and respectable accomplishment, but my gut feeling is I'll hate seeing some in production...

A nice feature is that imports honor scope, so you can use a module and import functions or operators within a scope and not worry about it causing problems elsewhere.

Haskell has custom operators too along with custom precedence, not too problematic.

Perl was the first high-level language I learned and I've used it many times during interviews. I still think I can solve most non language-specific interview questions extremely efficiently with Perl. Go Perl!

Long ago, Perl as a coding Leatherman, along with C/C++/Java.

Python took Perl's place on my belt. I'm using Python2, because all the reasons everyone else gives, and because it's Python2 at work. I've been wondering when I'd finally decide/be able to move to Python3.

And now I'm rubbing that faint Leatherman imprint on my belt, and wondering if I'll just skip Python3 for Perl6.

I would never want to use Perl at my day job, but I also wouldn't want to live in a programming universe where Perl didn't exist. Perl is a place where the pure joy of coding thrives.

I always found it obtuse and overly terse to the point of non-maintainability or readability, far worse than even C++. But that could be due to my lack of understanding, or being used to C-style languages and syntax.

Good to see it still has a dedicated following.

Hence the first 11 words of my comment.

Seems too little too late. Is Perl still relevant in 2015? What would you build in Perl today that you wouldn't build in another language instead?

I used to be a big fan of Perl but it seems to have fallen behind the times, I doubt Perl 6 is enough to catch up.

The typing and grammar mechanism aren't common, it may influence other languages. Also, Perl managed to survive even without mainstream relevance so the community will probably keep enjoying it.

ps: I found this talk pretty convincing about pragmatism https://www.youtube.com/watch?v=lpu-3UF_b48

also: https://www.youtube.com/watch?v=JpqnNCx7wVY

There is nothing stopping a resurgence of Perl, if it's an order of magnitude better than competitors. If the combination of modern Perl techniques and the language make it a good enough fit for a new interesting framework or tool, then we might all be writing Perl again in a few years.

Just needs to get more jobs posted for it first. Going back to the original comment:

>What would you build in Perl today that you wouldn't build in another language instead?

You could turn it around too: what could you build in another language that you couldn't build in Perl? Well, nothing really. It's a matter of taste, and I think what continues to set Perl apart is its syntax, which could be really good and readable when you don't try to do code golf.

I didn't say could or couldn't, we're talking about turing equivalent languages of course so that question is meaningless, I said would. You can code anything you want in native assembly, or in brainfuck even. But why would you? If you have some impressionable new college grad just getting into the industry how would you convince them to use Perl to build things instead of any other option?

Here's something that's normally not too fun to deal with in Python and Ruby: asynchronous operations. Perl 6 has promises, C#-style async/await, Go-style channels, and Reactive Extensions-style Supplies built in as first-class ways to deal with asynchrony, concurrency, and parallelism. It can also take advantage of as many threads as you'll give it. Since I deal with web services a lot, this is a huge boon for me.

But I don't really want to give a laundry list of features, because that alone is not a compelling enough reason to pick a language (P6 obviously needs to develop an ecosystem). As someone who appreciates both OO and FP, both static and dynamic typing, P6 really hits a sweet spot. I encourage you to look at Perl 6 as a new language with the feel of Perl but which solves many modern problems.

Are you talking about Clojure ;)

As a fan / dilettante of Clojure, I'd say no. The JVM is many nice things, some nasty things, but definitely not lightweight in terms of things like startup speed that I'd expect of Perl 6.

"The JVM is many nice things, some nasty things, but definitely not lightweight in terms of things like startup speed"

The jvm startup speed is actually surprisingly good these days. We were experimenting with writing several commandline tools with Scala, and didn't think they would work because of this "well-known" issue. Turns out it was fast enough even to enable letting Scala handle things like the code completion and still have it feel very snappy.

I'd agree that the JVM itself isn't so bad in terms of startup time. However, the last time I compared Clojure and Scala, Clojure took significantly longer to start up (even though what I was doing in Clojure was nothing compared to all the libraries I was pulling in with Scala!)

Edit: I should add that there's a Perl 6 JVM backend. While it's not as up-to-date as the default MoarVM, it could also be ready "for Christmas" :)

Yeah, I remember seeing The (Clojure) "JVM Slow Startup Time" Myth [1] in HN comments last week.

[1]: http://blog.ndk.io/2014/02/11/jvm-slow-startup.html

I actually like Clojure quite a bit and used Racket (with How to Design Programs) when I first began my foray into becoming a programmer. Here are a few reasons why I'm more excited about Perl 6 now than I am about Clojure (although I still think Clojure is great):

1) Async. While I was initially enamored of core.async, I've found promise combinators and supplies to be a more useful and higher level abstraction for the type of work I do. I also had huge problems debugging generated core.async code, but maybe that's changed over time. I suppose I could use RxJava with Clojure for supplies, but I have a feeling that it's not really seen as being in the same style. This is also why I'm not as big of a fan of Go as I once was, too.

2) As peatmoss mentioned, startup time. I work at a web hosting company and as you can imagine we write lots of small scripts. Clojure really can't compete in this area.

3) Gradual typing. Perl 6 supports gradual typing, with functions being checked at compile time and methods being checked at run time (the latter was a decision to allow both a powerful metaobject protocol and also easy interop with other languages using things like Inline::Python). I know that Clojure has core.typed, but that's not really what I'm looking for, although I do think it's an excellent project.

A final quality of life difference: Perl 6 has invested a lot of effort into awesome error messages, including things like suggesting a close lexical variable if you mistyped one. While every Clojurist learns to deal with the stack trace o' doom, there's something good to be said about this. :)

The latest version of Python (3.5) has both async/await syntax (albeit still tied to a single core) and type hinting.

I find asynchronous programming in Python (especially 3) tons of fun. Before 3, Tornado wasn't half bad either!

"too late" for what? Perl 6 is a super modern programming language with all the flexibility and fun of Perl 5. If you are looking for a multi-paradigm scripting language with an hybrid typing system then it's very relevant, just go and read its specs: I think you will find tons of interesting features that will make you want to use it some day.

This was something that was tangentially addressed yesterday - the idea was that Perl 6 isn't meant to be a flavor of the week language, but something that could conceivably last for decades.

One interesting thing Larry mentioned related to that long term view was that due to Perl 6 being a multi paradigm language, it could potentially become the defacto teaching language in academia, because it fulfills the roles of OO, functional, procedural, and logic programming in a single package. Eventually, that new generation of Perl 6 learners would go on to form startups and create bigger and better things. I'm not sure if this will come to fruition, but I think it's certainly worth keeping an eye on.

Too late for what? There is a difference between relevant and trendy. Perl, in many cases, is extremely modern. The Unicode support of Perl 5 is nothing short of state-of-the-art. CPAN is still an amazing resource. The web and OO frameworks for Perl are fresh as ever.

I mean, yeah. We're all going to be using Node.js in another year or two. But that's because our industry is bloody ridiculous. Not because Perl is ill-equipped for the "modern" age (People raving about MVC, the actor model, and promises in 2015 is tiring)

There are quite a few Perl shops in LA writing new code and more than a few maintaining apps that have been around for a while. Lacking the sex appeal of Node and Go (or whatever the next hotness will be) doesn't mean something isn't relevant.

Why build something in Perl? The same reasons you'd write something in Python, Ruby, C#, Java, etc:

- Mature tooling - Excellent library support - Code samples written for relevant projects by vendors for their libraries [0] - Experts available

Given the fact that there are a lot of good options, it's probably best to factor in, "Do I like it?" and/or "Would someone pay me for it?". For all the above the answer is yes.

Additionally, Perl 6 is more or less a new language. If it scratches enough developer's itches, it'll likely take off on its own. It's mostly getting flack due to taking forever and Perl 5's perceived lack of sex appeal. I think if you frame your question with languages like Lua, Haskel, Schema, etc you'll find a good set of answers from users in each community.

[0] https://www.elastic.co/guide/en/elasticsearch/guide/current/...

    > There are quite a few Perl shops in LA writing new code

These include Broadbean (in Irvine) and ZipRecruiter in central LA.

Minor quibble... ZipRecruiter is in Santa Monica.

Yup and Connectivity in Burbank, Rubicon in Playa del Rey, and a few others in Thousand Oaks that run ad networks.

TicketMaster used to have a Perl codebase but I think the murmurings I've heard point to them having switched everything to Java.

I find that anything involving a lot of regular expressions is easier to write in Perl than in Python. Perl and JavaScript are the only two mainstream languages I know of where regular expressions are first-class citizens (compared to Python, where you need to do `re.compile(r'...')` and store that somewhere).

Regexes are really easy in Ruby as well (which cribbed a lot from Perl). There's an OO syntax, but also support for the Perl built-ins so this works fine in Ruby:

print "match" if something =~ /thing/i

Captures with $1 etc. are there as are named captures using the same syntax in the regex.

The regex sublanguages and engines in Ruby and Python are knockoffs of the equivalents in earlier Perls.

But this thread really ought to be focused on Perl 6.

In Perl 6 one can write:

  print "match" if something ~~ /<thing>/

It looks superficially similar. But it's a scalable parsing feature, not a mere regex. That line of code will work when `something` is ten thousand lines of complex Perl 6 code and `thing` is the top rule in a grammar for parsing Perl 6 code.

Perl 6 is not Perl 5.

I was showing Ruby code to show how its regex handling is much like Perl 5 - Perl 5 would use a sigil on 'something'. Ruby is less like Perl 6 regex-wise due to the smart match (among many other things).

> Ruby is less like Perl 6 regex-wise due to the smart match (among many other things).

In both Perl 5 and Perl 6, smart match (`~~`) with a regex on the right hand side is just an alternate spelling (Perl 5) or correct spelling (Perl 6) for `=~`. It's a tiny, trivial difference.

But a Perl 6 "regex" can be an arbitrary full blown parser or compiler. And it assumes character=grapheme. In these two regards, as in several others, Perl 6 is quite unlike Perl 5 and other langs that adopted Perl 5 regexes and/or that adopted Unicode codepoints (or worse) rather than graphemes as their fundamental "character" unit.

You don't have to compile and store regexes in python. re.match(pattern, string) can be used right away and it will internally cache the compiled version of your most recently used patterns.

I'm also curious in which type of application regex is so important that it will be a deciding factor of language choice. I mean, if you have a regex in one out of 100 files, does it really matter if you have to write 2 lines instead of one.

processing text files is still quite easy in perl. Also perl one line regexs are much nicer (imo).

>What would you build in Perl today that you wouldn't build in another language instead?

By that logic we should just stick to assembler or C. You can built anything in C, if you really wanted to.

Perl or any other language, remains relevant as long as there are system depending on it and developers who use it. I view Perl a little like Cobol, you and I might not see it every day, but for a rather large, and perhaps a little obscure, subset of people it's still the tool they use every day.

If you have 10 Perl developers employed already, it might be a wasted of effort to retrain to Python, Node, C# or what ever, and just do you next project in Perl 6.

The biggest threat to Perl 6 might be Perl 5 though.

You launch Perl 6 without updating the fucking home page? So Perl. So perl.

Launchdate is still Christmas.

Accordingly, the official 6.0 release is also known as 6.Christmas. Right now, we're only at 6.Birthday.

According to http://rakudo.org/how-to-get-rakudo/ , Perl 6 is just a specification. What changes do you see in the specification between now and Christmas?

Note that the 'Synopsis' has been demoted to be closer to a set of design docs than a formal specification - it's more about the test suite these days (cf first two paragraphs of http://design.perl6.org/).

Jnthn made a list of things that are supposed to be fixed by Christmas [1] as well as a list of things that probably won't make it into the 6.0 release [2].

[1] https://rt.perl.org/Public/Bug/Display.html?id=123766

[2] https://gist.github.com/jnthn/040f4502899d39b2cbb4

    $ brew install rakudo-star
    <.... snip ....>

    $ perl6
    > say "hello world, sorry for the wait"
    hello world, sorry for the wait
    >

I've been waiting on the sidelines for 20 years but this release makes me think its finally time to jump in.

I'm pretty excited about the release of perl6. perl6 has a number of interesting use cases and features. I'll be happy to watch it evolve as more people pick it up and find new/interesting uses.

Here are the official words from Larry. There will be 2 beta releases and the major one in December.

Larry goes by the handle TimToady

http://imgur.com/1Vrpl2G

I had to look up GLR: the "Great List Refactor".

http://pmthium.com/2014/10/apw2014/

"What exactly is the “Great List Refactor” (GLR)? For several years Rakudo developers and users have identified a number of problems with the existing implementation of list types — most notably performance. But we’ve also observed the need for user-facing changes in the design, especially in generating and flattening lists. So the term GLR now encompasses all of the list-related changes that seem to want to be made."

I may not write a bunch of Perl 6, but the planet is better for having Perl 6. That says a lot about the person who guided Perl 6 to completion, he's a gem of a guy. Thank you Larry!

"If that's what it takes to make Ruby programmers happy..."

Completely brilliant.

It's unnecessarily condescending, especially given that Ruby got `?` and `!` suffixes from Lisp, which far predates Ruby, and that Ruby itself is in many ways a descendent of Perl.

The goal of Ruby is to make programmers happy. I started out to make a programming language that would make me happy, and as a side effect it’s made many, many programmers happy. Especially Web developers. But Ruby hasn’t reached developers who work on embedded devices, mobile devices, controllers, things like that. I hope to make them happy too. -- Matz [1]

Larry Wall's comment recognizes Ruby culture and acknowledges that it is a good thing. Not surprising given that Perl 6, like Ruby is an everything-is-an-object language with a lineage from Smalltalk. Programmer productivity/happiness was one of its goals as well.

[1]: http://siliconangle.com/blog/2011/08/31/qa-with-yukihiro-mat...

Well, Ruby also has quite a bit of lineage in Perl, so there's another layer to that as well. I think a lot of Ruby programmers that are unfamiliar with Perl would be surprised with how similar they are in some respects.

It would not surprise me that parts of Perl made Matz happy.

I really don't think Larry meant that to be condescending.

The "worst" I could imagine is that he was poking a little fun at Ruby programmers. I'm sure he was just trying to be funny, but sometimes it's easy to misinterpret what people mean when you don't actually hear them say it, but only read it in print.

I'd be very surprised if the comment was at all malicious.

Things that won't make it in to 6.christmas (the non-beta release): https://gist.github.com/jnthn/040f4502899d39b2cbb4

When talking about Perl never forget to mention CPAN. Heck this library ecosystem is still great and running..

CPAN installs are the reason I personally avoid perl like the plague today.

Why?

So do I, for the same reasons.

At a previous job perl was used everywhere. As a language, it's quite nice. CPAN is horrible, though. No staging/stable/whatever versioning, new modules requires updating versions of existing modules which frequently broke - it's just not something that's enterprise friendly.

I tried but failed to find a company that would support and curate a subset of CPAN modules properly. Does one exist now?

There are multiple tools to do this on your own, with CPAN::Mini and friends, or Carton.

I also don't know how long it's been since you last tried, but cpantesters and the other odds and ends of the ecosystem have helped tremendously in reducing published bugs. ( http://matrix.cpantesters.org/?dist=System-Command%201.115 )

Checkout Pinto, http://perlmaven.com/pinto-tutorial, which allows you to host your own CPAN mirror and have stacks. So you could have a "development" stack and a "production" stack, or a "perl-5.8" stack and a "perl-5.16" stack. Whenever you add or upgrade a module, it only affects one stack.

For Perl 5 only deployments see https://stratopan.com/

The Perl 6 `use` statement supports :auth, :api and :ver adverbs for explicit control. See http://design.perl6.org/S11.html#Versioning for some detailed discussion.

If you have perl code to maintain and dependcies break, its not easy to use or at all intuitive. You run cpan, it tries to set itself up, 40 minutes later its trying to autoselect the same broken mirror. Is this going to go on forever? Run again. Select repo, it kind of works.

Get 6 pages of build output and a broken install.

Its one of the first repos, a great idea, its just frustratingly obtuse.

> 40 minutes later its trying to autoselect the same broken mirror

Sounds like you're in a network with particularly misbehaved firewalls. The initial phase of the auto-setup is very fast, since it only checks file paths. The network part might be slow if some part of your network infrastructure messes with connections and cuts them without properly resetting, resulting in super long timeouts.

Not sure what you expect in such a situation.

> a broken install.

No you don't, unless it's an extremely old or shitty library you chose to dep on, since things build, run their tests, and only install when those pass. The 6 pages of output help you identify which tests failed and maybe why. Also, often test failures are simply because you have a system the author didn't write for, which hurts just as much with the other packaging systems.

Broken install = it didn't install. I had no idea why. I did get there after some hours of struggle . Part of the problem is the libraries on our system are everywhere.

Sorry I sounded cranky, truthfully I'm probbly just unfamiliar. I'm a developer not an admin, just want to install packages. We developers love the package systems and cpan pioneered a lot of it.

A great package manager goes a long was to helping a languages success.

I'm comparing to Gems, composer, npm, rpm which for what I've done with them work pretty flawlessly and easily.

See cpanminus [0].

From [1]:

    cpanminus (cpanm) is an attempt to make a zero-configuration client
    that automatically does the right thing for most users. It's also
    designed to run well on systems with limited resources (e.g. a VPS).
    It doesn't come with Perl, but it's easy to install.
    It integrates easily with local::lib.

[0] https://metacpan.org/pod/distribution/App-cpanminus/bin/cpan...

[1] http://stackoverflow.com/a/5862539

> Broken install = it didn't install.

Ah, that wasn't clear.

I have to say though:

> I had no idea why. ... Sorry I sounded cranky, truthfully I'm probbly just unfamiliar.

Yes. CPAN does a lot to help the user and gives a lot of information, but all that information truly does contain 99% of what you need.

It progresses in phases (prep, make, test, install) just like most other make-based software (99% of the stuff installed on your linux boxes) and after each phase it will say "<phase> OK"/"<phase> NOT OK", so you only have to read for that, then scan upwards to see what errors you got from gcc or whatever. In other words, and i'm not trying to be mean, but: You only have to read what is on your screen.

As for "Gems, composer, npm, rpm", i know that the three non-npm ones don't run tests on install (npm probably doesn't either), so you might be conflating "flawless and easily" with "system incompatibilities are found at runtime, instead of install time". I.e. it's highly likely that what you like of them isn't that they've progressed beyond CPAN.pm, but that they've yet to catch up to it.

Is Duke Nukem Forever out yet?

Yes, all we're waiting for now is GNU Hurd, and software will be complete.

I hate to indulge this thread, but feel obligated to note that Half-Life 3 is still naught but a name.

Half-Life 3 is not even vaporware. It was never announced, was it?

The ending of the last-released HL2 episode had a very “to be continued” feel to it, but more importantly, Valve has made statements about future releases moving away from “the episodic format” to “smaller releases” and possibly returning “to genuinely scaring the player,” but it all seems rather dead now. This section in Wikipedia has some relevant sources: https://en.wikipedia.org/wiki/Half-Life_(series)#cite_ref-37

Probably the funniest / saddest / most hopeful part of the whole saga is that at some point, a group of fans organized a sit-in at Valve HQ to plead for a commitment to HL3 :)

Some of the code examples suffer from a failure to escape angle brackets...

So, for someone who has never read or written Perl code, where should I start? Perl 5 or 6? I get that they're different languages, but I want to see what "Perl" is like.

> but I want to see what "Perl" is like

> get that they're different languages

I'm not sure you do get it, unless you are talking about the "feel" of using it, in which case use either. They aren't just different languages because there's some things that break backwards compatibility, they are vastly different in many ways.

If you want to know what current deployed Perl is like, look at Perl 5. If you want to look at what the "Perl" future is, look at both Perl 5 and Perl 6, since they'll both be around. If you want to see something new and different, look at Perl 6.

I was talking about the "feel", indeed. So for example, if someone wanted to experience what a Lisp is like, I could point them to Scheme.

I want to know what "Perl" is like, but the fact that Perl 5 and 6 share the same name is a tad confusing for a newcomer. Precisely because I have no idea what "standard" Perl is.

I guess Perl 5 it is, since it's already on my machine.

The Modern Perl book[1] is highly recommended.

For web development, check out Mojolicious[2] or Dancer2[3]

And Task::Kensho[4] lists recommended modules for various tasks.

[1] http://modernperlbooks.com/books/modern_perl_2014/

[2] https://metacpan.org/release/Mojolicious

[3] https://metacpan.org/release/Dancer2

[4] https://metacpan.org/pod/Task::Kensho

Then I recommend perlbrew[1] for Perl 5, and rakudobrew[2] for Perl 6 if you decide you want to take a look there as well. They will let you quickly build and install any particular version of Perl you like, and allow switching between versions if you have the need. The Version of Perl included in most distros is rather old as, Perl 5 sees regular releases with new features.

The one main hint I have for you (beyond reviewing the Modern Perl book, as my sibling comment recommends) is to understand context and what that means in Perl. Perl can look deceptively similar to C and other procedural languages, but there are some somewhat (still) radical ideas underneath that will leave you either scratching your head or grumbling in frustration if you don't understand context (list or scalar), and how it's relevant in almost everything Perl does.

1: http://perlbrew.pl/

2: https://github.com/tadzik/rakudobrew

Perl 5. Lots of good code out there to learn from, which will take a while for Perl 6 to be written.

And then you have a well documented mental migration path to Perl 6 since it tends to be explained in terms of deltas to Perl 5.

Someone should implement a Duke Nukem Forever clone in Perl 6.

Pretty excited about Perl 6. Haven't used Perl in a long time but there seems to be quite a bit of cool stuff and I'm very excited to see what a language where Larry had more free reign will be like. Xmas reading/coding here we go (how fitting)

Oh my. I expect the next version of Perl to read my thoughts and to not require any source code from fallible mortals. The jury is still out whether this will produce more bugs than it abolishes. The answer is expected in time for the end of the universe.

sidenote: why does a barracuda device consider pigdog.org "Porn"?

Coder porn?

well they have certain ... associations ... with dog urls so they decided that dog* was a good ban pattern.

In a perl article, you give a non-matching pattern?

Its just one of those little things we don't think of often, but a lot of folks buy these devices and its a weird form of censorship beyond what's normally intended.

Same issue here.

Just to remind you that it's working and has your best interests in mind.

The site has a lot of commentary on the subject of pornography, in addition to hosting porn.

Congrats! But shouldn't some kind of official announcement be made on perl6.org?

There will be, when a stable version is released for christmas.

I don't think I'll ever use it again, but I'm glad that it exists.

quetion for the early adopters: if i develop an end-user app in perl6 on linux, how easy is it for me to deliver it to a non-technical windows and/or mac osx user?

Since Rakudo also targets the JVM, not just MoarVM (the dedicated VM), I imagine it's not terribly too much work to get to the point where the app, included modules, and Rakudo/Perl 6 itself can be bundled together for delivery.

oddly enough, a coworker and i were joking about how perl 6 would come out in the next 100 years on monday and just a few days later larry wall made us look foolish.

Perl 6 needs a good tutorial.

I haven't looked, but I really hope Perl 6 held on to the 50 different ways to do any one thing. Pulling out my hair in frustration from trying to deal with Perl written by other people saved me all manner of haircut money in the 90s.

If you had tried to invest a little time to actually learn Perl, you might still have a beautiful mane on your head.

I suspect a lot of people didn't take the time to actually learn Perl which is why there's so much "there's-more-than-one-way-to-do-it" Perl code in the wild.

For whatever reason, I went the PHP route and I can say from nearly 20 years experience that PHP has the same problem even if it doesn't have the same philosophical approaches as Perl. Too many people who never actually learned the language producing near unmaintainable code.

Yep, it is absolutely a problem. I even made http://perl-tutorial.org to battle it somewhat.

The worst part is that people who believe they learned Perl by doing, instead of reading the reference docs and structured introductory texts, believe themselves to know Perl and speak publicly in the belief that the knowledge gained that way represents universal fact.

If you have globals, nulls, gotos, or whatever dangerous (but sometimes useful) features (e.g. states); surprise surprise people will end up using them at one time or another.

Perl is not the first nor will it be the last (imperative) programming language helps people fail too easy.

Double check me on this, but Perl 6 doesn't yet have a goto statement, nor does it have globals.

> Double check me on this, but Perl 6 doesn't yet have a goto statement, nor does it have globals.

AFAIK, Perl 6 has a goto statement in the spec (one big change is that Perl 6 is a spec), it just isn't yet implemented in any of the implementations. But presumably the target is to have the whole spec implemented for the release this Christmas. (EDIT: Actually, no, goto won't be in "6.Christmas" [0])

For globals, its has global scope ("our") but variables with global scope are still namespaced based on where they are declared, so while they are globally visible, they lack some of the more problematic features associated with globals.

[0] https://gist.github.com/jnthn/040f4502899d39b2cbb4

I guess I didn't make it clear enough but I was speaking in general terms and I wasn't just talking about Perl. i.e. I'm defending the people who weren't experienced enough not to realize that you shouldn't use a language's features just because they exist. Even when you have experience, people get tempted to just get things done regardless of how spaghetti the solution is

I suspect if anything, there will actually be more ways to do it in Perl 6. It can be used entirely from an object-oriented point of view, or entirely from a functional programming point of view. This is construed to be a feature of the language.

Flexibility is Perl's greatest strength and weakness. Perl forces you into dealing with other people's thought processes as a consequence of allowing your own code to be expressive and better reflect your thought processes. If this is not a tradeoff you're willing to make, Perl is most likely not for you. But I find it to be educational to see the variety in well-written Perl code (i.e. not from from Matt's Script Archive).

Looks like now you'll have 65 ways.

I love Perl [I have been to perl monger meetings and I had to look up how to 'unshift' in python today].

But Python3 is mostly just Python2 with a print function instead of a print keyword. It is occasionally non-trivial to port large existing code bases from Python2 to Python3, but it is practically always trivial for a Python2 programmer to write new code in Python3.

I hope Perl 6 will get its own camel book!

I remember buying the camel book ten years ago, and there was a slim Perl 6 volume next to it - http://shop.oreilly.com/product/9780596007379.do

I imagine its relevance to the Perl 6 that was announced today is next to nil.

The Perl 6 camel book will probably be published like TAOCP. /s?

If it's ever published :)

> it is practically always trivial for a Python2 programmer to write new code in Python3.

Until you need to use some library that doesn't support python3. I think I've made the transition from python3 to python2 more than I have the other way around.

I've been writing forward compatible py2 code for years using the __future__ imports to ensure proper semantics are preserved. When all my external dependencies have py3 support it becomes a breeze to upgrade using 2to3 and the rare occasional manual fixup.

And your tests will validate nothing was broken, right? You have thorough tests?

Not sure why this was downvoted. I'm currently still in Python2 and looking to upgrade to Python3. Having solid automated tests is vital for us to do it confidently.

Probably the snark

But do you have tests for your tests? Assuming tests are written in Python2, gotta make sure they don't start testing the wrong things when you upgrade them...

The way I think of it, the code tests the tests. It's the the same way keys and locks verify each other.

Is there some sort of failure mode you're thinking of where I'd still see all the tests run but the test framework would give false success for something?

Or until you trip over the API differences between str and bytes in Python 3 that do not exist in Python 2 (because str == bytes in Python 2). Chiefly, printf-style formatting...

  >>> b"%u" % 5
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: unsupported operand type(s) for %: 'bytes' and 'int'

Why are you using % at all? It should have been deprecated years ago.

Why? Maybe it suits his use case better than .format() or whatever.

It's not deprecated, though.

Why? What are the benefits? % can have as much information about the string and the arguments as .format, can't it?

If I remember right, % used to be deprecated in Python 3, but was undeprecated again by popular demand.

Fixed as of a month ago.

https://www.python.org/dev/peps/pep-0461/

There's plenty of times it still matters. E.g. data coming in on webserver ->

json.loads(foo) blahblahException foo is bytes not text.

That said I still endorse py3 for new things

That argument is becoming a good way to tell who hasn't actually tried Python 3 lately, or is using out of date libraries.

More and more of the bigger libraries are ported already, and a lot of the others have been replaced by newer libraries that work with Python 3. If the library you're trying to use doesn't support Python 3, it's probably a good indication most people have moved on to something better...

I'd love it if there was, I'd love to kick a couple bucks to Randal after hearing he lost his house.

He lost his house? That sucks. Was that related to his felony charges? Like many others here I feel quite an affinity to the Perl community, sad to hear about that.

Nope.

http://web.archive.org/web/2011/http://merlyn.posterous.com/...

And stuff like map returning an iterator (instead of a list). Print being a function is the one everybody knows, but this one is the one that is more common for me. That and bytes/Unicode subtleties. Code rarely is much different in substance however.

learning Python 3 is easier than reading any Perl...

If you learn both by learning from a well-written book, then they are equally easy, though Perl, by its depth, might require a slightly bigger time investment.

Learning atomic parts of anything is very easy. Its using those atomic parts to build complex systems that is hard.

If there is a operator in Perl 6, which you don't have in Python- Your options are to rewrite those semantics in Python most of them pretty large, and they won't be easy to read either.

Ease of learning is a irrelevant metric. You can't use a needle to replace a saw, if you do you are only going to end up doing more work.

> Learning atomic parts of anything is very easy. Its using those atomic parts to build complex systems that is hard.

> Ease of learning is a irrelevant metric. You can't use a needle to replace a saw, if you do you are only going to end up doing more work.

I adore the elegance of your wording.

We detached this comment from https://news.ycombinator.com/item?id=10342663 and marked it off-topic.

The mods are drunk with power!

: )

I commented because I didn't want the top comment to devolve into a Perl v. Python argument because I love both.

Looking at my comment now, it doesn't read as on topic.

Thank you for moderating. HN is my favorite place to read the news!

Thanks for being so nice about it!

What ends up becoming off-topic on HN, btw, is as much about upvotes and replies as it is about the original comment.

Not quite. I recently ported a script from Perl (which I can barely read) to Python (I used to know 2 pretty well) and took the opportunity to see what the differences between 2 and 3 are.

There's a pretty big page of changes, rules for maintaining compatibility and suggestions and it pretty much killed all my enthusiasm.

I'm speaking from memory and might be wrong, but one annoying thing was that I couldn't detect the Python version and print an error message, instead the P2 interpreter would throw an error at runtime when encountering a P3 construct.

There are many nice P3 books and libraries, but 2 vs 3 is still a PITA.

Way too late

Give 10 guys the same programming task in Perl, watch 10 completely different syntactically built innovations come from them.

Perhaps it was better veiled :)

Larry Wall Unveils Perl 6 and no comments on hacker news an hour later.

That's the new headline that sums up Perl: an anachronistic programming language that may never recover from the perl 5->6 decade long 'freeze'. Also the language is crazy to write substantial programs in!

Yeah, the freeze killed momentum and left the community to wither. Python's transition was much better but is still not quite complete, and consumed a lot of time and effort.

Making a backwards-incompatible change to a programming language == making and launching a new language, with all its difficulties.

If Python's transition actually was much better, that says quite a bit about how awful the Perl transition is gonna be - since the Python 2->3 transition seems pretty widely acknowledged to be a disaster.

There is not and will not be a transition. It is a completely new and different language.

Which is exactly what Python should have done. Call Python3 a new language and not try to kill/degrade Python2 but have both live on... which they will anyway regardless.

> Also the language is crazy to write substantial programs in!

I would not want to write anything big in Perl 5. But for small-ish scripts (say, less than a thousand lines) it is pretty hard to beat.

Perl is awesome for writing big programs in. One of the things that people find frustrating about Perl is its expressiveness -- that is, there are many different ways of doing the same thing. The result is sometimes that you get 100 different people doing things 100 different ways.

This is not so much a problem with the language as it is with programmers not learning to agree on a set of idioms that they will use for a project. They are not reading each others code and having discussions about what they want to see.

Languages that impose "the one true way" cut down on the apparent problems, but you are still going to have massive issues down the road if you build large projects because nobody is paying attention to what the other people are doing. Especially on large projects, it is vital that people read and comment usefully about design issues. In such large projects, removing the choice of idioms available though language design is a bit like deciding not to carry a canary down the mine with you because it keeps getting killed by poisonous gas.

The expressiveness of Perl allows you to choose the idioms that will work best for your team/project. It is true that it requires more discipline and communication, but these are the things that are necessary for success on a big project anyway.

I haven't written any Perl code for years now, but I have always been fond of it. I find that I can write better code in Perl than in many of the more restrictive languages that I've used.

> Perl is awesome for writing big programs in.

This isn't even remotely true. No static types, no thank you. Runtime errors due to misspelled methods? Missing hash keys? Hilarious.

Boy, I hope this scalar isn't undefined!

Then you might be pleasantly surprised to learn that Perl 6 has a type system and compile time errors functions (but methods are runtime errors - on purpose).

As for missing hash keys... It sounds like you are using a hash when you really want an object. There are cases where that's preferable, but part of that trade-off is that you need to make sure the data is as you expect it. Perl 6 supports tightly packed (C struct equivalent) objects if you choose.

You don't write a lot of tests, do you?

Compile time checks are not a replacement for a good test suite.

And a good test suite is no replacement for being able to express invariants in your code. They are complementary tools.

Who said they were?

"I wouldn't write anything big in <insert language>" is pretty much always a true statement. What changes it is the framework.

I can write a web application in some homebrew <insert language> and it can grow to 40 developers, 1000 db tables and thousands of files. But it would be terrible to work on (I know I've seen it). Or i can write the same thing with a framework, and have it much more manageable.

Realistically, when was the last time you say down and wrote a big application in vanilla <insert language>?

Don't worry, within 24 hours there will be hundreds of comments all explaining how Perl 6 is of no interest to anyone.

It does need to find an audience. People using Perl 5.x are probably working in conservative companies that stuck with what worked. Perl 6 will need 2-3 years to bake. Python 3.x is just gaining some tractions 7 years after its release.

Perl 6 needs to find a problem that it can solve well. Perhaps a great web framework?

The companies I know using Perl are generally not so conservative - many of them also have Go code bases, heavy focus on DevOps, and so on. They tend to keep using Perl because they have developers who love programming in Perl...

There was discussion about it yesterday: https://news.ycombinator.com/item?id=10331008

Is it so crazy though? With frameworks like Mojolicious and Dancer, you can set up a whole website using syntax familiar to someone coming from Sinatra on Ruby or Express on NodeJS.

I've spent a year now using Perl exclusively at my job, and I love it. It's incredibly powerful, expressive, concise, and well-documented. It's a lot like js where the language has some cruft but as long as you're not working with any cowboys you can build some really elegant software.

And nobody cares.

Finally.

What's Perl?

Larry Wall is a great guy. Unfortunately, I don't really like Perl. Maybe the new version will change my mind.

> say [+] <3, 1, 4> x 2

It's like the perl developers saw the comments about perl being indistinguishable from line noise and decided to make it even more so. WTF?

This rant made me laugh one day: http://www.schnada.de/grapt/eriknaggum-perlrant.html

Disclaimer: I don't know Perl and I have no opinion if this rant is deserved or not yet it's an enjoyable read.

He admits freely that he is ignorant about Perl, so i am unclear why you would bother to subject anyone else to such childish insults borne from nothing but fear and hate of the unknown.

I'm not sure what do you mean? I didn't write this rant. I find it amusing because it has some food for thought – for instance side note about rewarding idiotic behaviour.

AFAIK Erik Naggum used Perl for a fair amount of time so I wouldn't call it a "fear and hate of the unknown" and it is about Perl hence also on topic.

So your point is? Did you even bother reading it?

> I didn't write this rant.

You bothered to link to it.

> side note about rewarding idiotic behaviour

The raw and naked idea is not entirely incorrect. Literally everything else in the sentences making up that section is.

> Erik Naggum used Perl for a fair amount of time

> Did you even bother reading it?

Did you? I quote from the screed:

    I once studied perl enough to read perl code and spot bugs in other
    people's programs [...], but I don't write in it and I don't ever
    plan to use it for anything

I don't know about you, but i find that unambiguous.

I'm a born LISP programmer who also happens to know too much about perl. Eric has some points, but not too many.

Javascript would fare much worse than perl with these arguments. It is far more dynamic, far more unregular and produces even worse code than perl5. See e.g. http://archive.oreilly.com/pub/a/javascript/excerpts/javascr...

perl is kind of a lisp - much more than javascript - with some clojure like features, like shorter hash and array syntax.

Reply on news.ycombinator.com