Why Perl 6 is Different (2010) | Hacker News Reader

Why Perl 6 is Different (2010)

blogs.perl.org

52 pointsbrudgers50 comments

> Perl 6 is Lisp with a perly syntax

Lisp syntax is super simple. But this simple syntax can hide an enormous complexity. Metaprogramming is complex. Lisp is so powerful, but it's not so widely used as other languages because of this complexity.

Now, Perl 6 claims to have the same power as lisp, only that instead of using a simple syntax, it is using a complex one, and a complex way of modifying that syntax. This is complexity wrapped in more complexity.

I'm sorry but I don't think Perl 6 will ever be a very widely used programming language as its predecessor was. It might however amuse a small group of hackers who want to test new ideas in programming languages.

Did you use more than logic to arrive at your conclusion, e.g. did you spend a while having fun, or at least trying to have fun, coding with Perl 6 before you reluctantly concluded it wasn't going to work out or did it never really appeal in that way to you in the first place?

I've in fact been playing with Perl 6. First a year ago, and then again when it was released. I've found and reported bugs. And I do think it has very powerful features. But hell it's hard to learn and very complex in my opinion.

Thanks. It's good to hear that you've tried to enjoy it and drawn conclusions from that experience.

Imo Perl 6 has some easy on ramps and then a long and winding learning road that can be tiring to navigate due to pot holes, inadequate doc and tools, and lots of yak shaving. I wonder if you agree that bugs, weak doc, and an immature ecosystem and tooling are a significant contributor to the toll exacted by the long (endless?) learning curve?

Also, if you've used and liked Perl 5 I'd be interested in your opinions about how you think the relationship of the two Perls will evolve.

Larry Wall talks about Perl 6 chasing Paul Graham's idea of a 100 year language (though he'd be happy with 30 or 40). [1] So I think it might be fair to say he takes a longer term view of programming languages and learning them than some other people...if 15 years of incubation wasn't enough evidence in itself.

[1]: https://www.linuxvoice.com/interview-larry-wall/

The problem of Lisp is the side-effecting nature of it. There's nothing complex in metaprogramming, if you do it in pure setting. The problems arise when you combine two differently side-effecting pieces of software and Lisp does nothing to prevent that or help there.

I won't stop repeat that mantra that side effects and program state are an implicit information channel in a program. This channel is shared by many parts (or parties) inside program and it has some specific implicitly specified protocol of use. Add a piece of software that uses the channel with slightly different protocol as assumption, get ready for all sorts of problems.

Of course there are side-effects. This is the whole point of a dynamic _system_ where (almost) everything can be redefined at runtime.

One of Perl 6's original design goals was that it should "still be Perl". In that sense, I think it's a failure. Aside from a superficial syntactical resemblance, it really doesn't feel much like my beloved Perl 5 at all. Its semantics are very different.

It also seems to suffer from an advanced (possibly fatal) symbolpasta diarrhoea. Perl 5 was not pretty, but Perl 6 at times can be downright hideous.

If Perl 6 is a Lisp, that's great! You know, I am deeply and madly in love with Clojure at the moment. But that manages to be a Lisp without falling even deeper into the line noise trap than P5 did. But, you know, syntax is just syntax.

I like P6 syntax and semantic more them P5.

My only one problem about P6 is the fact they dropped the effort of having the specification so others can implement the language too. Looks like they prefer a conformance test instead of a formal/complete specification.

While that is perfect fine, I would say having both the test and the spec is even better, for those trying to learn and implement the language.

A good, formal and complete specification will make my learning process much better, IMHO.

I've recently been implementing a language based on a conformance test instead of a spec, and it's really hard. I often have two tests that do different things with seemingly similar inputs, and I struggle to find the underlying reason behind what is going on and what the cause of the difference in output is.

There are still the design docs (http://design.perl6.org/) which are essentially spec documents. They are what implementors have been using over the years. Don't forget the tests came from Pugs and now Rakudo is using the same test suite, so it's more portable than you perhaps imagine. The tests are the stamp of approval for a version number conformance. If you can pass all the versioned tests then you are that version of the language. I think that's a lot stronger statement than the engineers think they understood a spec document, even if formally specified. What are your thoughts on why that isn't ok or worse than relying on pure docs?

I think you've misunderstood the original intent as expressed by Larry Wall in 2000, the current situation, and the future intent and practical realities.

For the original intent I'll quote Larry from the day he announced Perl 6 in 2000[1]:

"I don't know how strict a spec it will be from the language design point of view. I'm not really big on that sort of spec and there is some value to using the reference implementation approach and what we currently have is a reference implementation [with] no second implementation, well, unless you count the JVM work, but, obviously there are benefits to having things justified well enough that you could implement another one even if you didn't want to, so we'll definitely be working in that direction and - do you have something? And there was something else I was going to say - what we particularly want to stress in terms of - is not perhaps so much the spec as developing our current regression test. Well, we call them regression tests, but they're almost more acceptance tests, but, we developed our acceptance into real regression tests then you'd further develop the real regression tests into a validation test of what the language actually means and actually go out and explore all the nooks and crannies and say, "This is Perl, this is not Perl," and then we actually have a machine-readable spec. And to me that's actually a lot more important than what the verbiage on the human readable thing says."

I think the 6.Christmas release corresponds fairly directly to this original intent.

In the meantime the spec docs (as against the spec test suite), which are currently referred to as either "speculations" or "design docs" to better emphasize their contemporary role, are currently well behind the test suite and implementation. This is presumably what caught your attention.

The current thinking is that Perl 6 will follow the pattern adopted by many other mainstream languages in terms of the timing of development and publication of a relatively formal and debugged prose specification.[2]

This thinking in turn suggests it would be best if the spec docs caught up with the spec test suite and Rakudo and were then polished and formally published in a frozen form, some years from now.

At that point making a significant effort to provide practical support for alternate compiler implementations ought once again become compelling.

[1] http://www.perl.com/pub/2000/10/23/soto2000.html

[2] http://pmichaud.com/2015/pres/fosdem-specs/fosdem-specs-1.pd...

> Perl 5 was not pretty

Beauty is in the eye of the beholder. I won't bore you with the details, but rest assured that there are many others like me, who appreciate Perl 5 both for its aesthetics, and are able to use the technical consequences of said aesthetics for productivity.

You're right that it's subjective, but I think it's true to say that the most commonly appreciated programming language aesthetic has shifted since Perl 6 started to when it delivered. Back then many programmers appreciated the whimsical, pseudo natural-language nature of Perl. These days I don't think that style is as fashionable amongst most programmers and purity and straight-forwardness is more appreciated. Perl 6 is going to lose out because of that.

This post sounds a bit like trolling :D

However, I believe the real power of Perl, besides the obviously awesome regex handling, is the "huffmann" principle of making common things super-quick. Sure this is the major cause of read-only code, but it's also the reason why I use perl every time I just need things to be done.

In Perl6 they kept this principle in mind, and this is the important part IMHO.

>>Sure this is the major cause of read-only code

Did you mean "write-only" code? Read-only code would be a much touted language feature and cause for celebration!

(But productivity would suffer.)

It is still... A language for the quick hack, but not for the reader (or author) to understand a day or even an hour after the writing.

That's the number one reason I don't code in Perl, I can't even read my own code 6 months later... Perl is not a programming language, it's closer to real languages and you can sort of invent stuff and it works...

Then you're doing it wrong. Do you write in the same manner in other languages, too?

I can write readable Perl by writing it as if it were Python, adding extra braces where required, a couple of use declarations at the top, and wrapping some system functions with clearer names. But if that's what you want then it's easier to just write Python. Perl's USPs like regex literals and $_ rely on you writing in an unreadable style.

Got some examples of your Perl?

Afraid not - I only ever wrote Perl for employers, for my personal projects I used Python.

So, Python regexps are suddenly more readable, even though they need additional layer of backslashes?

$_ does not rely on unreadable style. First, it's a common idiom, so it's in no way less comprehensible than list comprehension in Python. You just need to understand what it means. Second, it's not an obligation to use $_. I often avoid it if it doesn't make my code reflecting my intentions better. Funny thing, I do the same in Python, C, and Erlang.

And I hear about $_ and regexp literals as unique selling points (if I read your acronym correctly) only from people that don't really write in Perl.

> So, Python regexps are suddenly more readable, even though they need additional layer of backslashes?

Python encourages a style that makes less use of regexps. (And you don't need extra backslashes, you can use r'...').

> And I hear about $_ and regexp literals as unique selling points (if I read your acronym correctly) only from people that don't really write in Perl.

Nice ad hominem. Go on then - what's your USP for Perl? Why should one use it over Python/Ruby/...?

> Python encourages a style that makes less use of regexps.

Yes, even in the places where regexp would help very much. And even if you'll insist on using regexps, Python makes them highly inefficient or cumbersome (or both), because if you're careful, you'll either get code that needs to store compiled pattern somewhere vaguely related to the code at hand, or code that compiles the pattern on every use. If you are not careful enough, you'll get the two at the same time.

> Nice ad hominem. Go on then - what's your USP for Perl? Why should one use it over Python/Ruby/...?

Thank you, though I wasn't refering to yourself. It was pretty clear you don't write Perl much.

My reason to use it is because it was my primary language for over a decade. For other people? I don't know. All three are similar in what they can do and how does it look afterwards, as all of them are scripting languages in OOP land.

Combine that one and Perl's learning curve, and you'll get why Perl usage was declining over the last decade.

Scala uses [$]_ in very similar ways and everyone loves it.

"_" in Scala is not a magic variable like in Perl. It's a very mechanical syntax transformation, it just expands to "x => x" (or equivalent, and without colliding with any "x" that's already defined).

In practice maybe the use is similar. But having a comprehensible theoretical model makes all the difference in terms of making sure you can actually read the code and understand what will happen.

There is nothing particularly magical about $_. It is merely a global variable that is optionally used implicitly in various builtins, as well as scope-localized by loop control constructs.

Are you sure you're not just used to it? The description you've just given sounds very magic to me.

That depends on how you define "magic". I typically do so as "cannot be implemented in the language itself", which does not apply to $_, as it can be reimplemented in Perl itself. If i was bored enough i could create a module that sets up a $this variable that acts exactly the same, in pure perl.

Is it the for loops? The if statements? The function calls? I've written lots of Perl. It doesn't have to look that much different than any other language. If you find a terse 1 liner on the Internet and use that as a solution, you might not be able to read it a week later.

I suspect it's the wide range of special operators, variables and default arguments. Knowing, for example, that shift() shifts @_ by default. That <> iterates over @ARGV. That chomp chomps $_. Messing with @INC changes library search paths, etc.

Or, perhaps the syntax for dealing with elements in a somewhat deep data structure, like: push(@{$TV{$family}{kids}},"anotherkid");

Sometimes, people are just griping about regex syntax though, which seems disingenuous, since many languages use the exact same pcre expressions.

I like perl, but if it's been a while, there's definitely some back and forth with books to decipher something I wrote some time ago.

It largely depends from whom you learn. Most people google and run with the first thing google throws up and perl has many, MANY (due to its age) really shitty learning resources. Even the most popular one, the book Learning Perl, has as of its 6th edition (2013), grave flaws and miseducates newbies severely.

Some comment from the position of someone familiar with Modern Perl, which is largely what's practiced on CPAN:

> shift() shifts @_ by default

This is discouraged, precisely because it messes with @_. It has valid uses, but people tend to make sure it's clear from the code why it's used. (Mainly in OO helper stuff.)

> <> iterates over @ARGV

Almost nobody uses that, precisely because it's very unreadable. It only exists for compatibility reasons and was made to serve people used to sed/awk.

> chomp chomps $_

I haven't seen code use chomp in ages. I've never used it myself.

> Messing with @INC changes library search paths, etc.

This is rarely used as well. Mainly only when doing release engineering. It's also most often done via `use lib 'whatever';`.

    push(@{$TV{$family}{kids}},"anotherkid");

That is an outdated way to write that. In a decent modern style it would be written like this:

    push @{ $TV{ $family }{kids} }, "anotherkid";

And with a more modern Perl, this:

    push $TV{ $family }{kids}, "anotherkid";

>>It largely depends from whom you learn.

In my case, when you learn :)

Yes, I think the biggest issue with perl was the devil-may-care culture around it. That was far from the only issue, though. It had (has?) some gratuitous features which are bound to cause hard to find bugs, like implicit conversion of numeric strings to numbers in certain contexts. That particular feature was the reason I chose to learn python in the mid 90s, rather than perl.

> implicit conversion of numeric strings to numbers in certain contexts.

In Perl 6 at least, and to a large degree Perl 5 too, context only "causes" bugs if coders make assumptions that are invalid in Perl.

For example:

  say $foo + $bar

adds two numbers. So the context for $foo and $bar is numeric. So Perl coerces them to be numbers. If you didn't mean to add two numbers, don't use a numeric operation such as `+`.

If you want Perl 6 to make sure $foo and $bar are numbers already, then add a type to their declaration:

  my Int ($foo, $bar);

Your comment actually made me scroll back to the top to double check this thread was actually about Perl 6, not Perl 5!

Part of the point of Perl 6 was to address problems in the language and Larry (and/or those who wrote the original Perl 6 RFCs) considered several of the things you named to be problems.

> wide range of special operators, variables and default arguments

In Perl 6:

* The only special op I'm aware of is assignment.

* The only variables considered special are the "it" and "them" variables ($_, @_ and %_), the current match object ($/), and the current exception list ($!).

* There are still predefined variables, such as a DISTRO variable which contains an object representing the OS etc. on which Perl 6 is running, but I haven't found those problematic.

* Almost all use of default arguments in built-ins has been eliminated. The main exception I'm aware of is that subs and ops related to matching still default to operating on "it".

The Perl 5 <> op is gone.

> Or, perhaps the syntax for dealing with elements in a somewhat deep data structure, like: push(@{$TV{$family}{kids}},"anotherkid");

This would be something like this in Perl 6:

  my %TV;
  my $family = 'foo';
  push %TV{$family}<kids>, 'another';

> Sometimes, people are just griping about regex syntax though, which seems disingenuous, since many languages use the exact same pcre expressions.

This is talked of in Perl 6 circles as being ironic because regex syntax has been thoroughly cleaned up (and massively powered up too) in Perl 6.[1]

> I like perl, but if it's been a while, there's definitely some back and forth with books to decipher something I wrote some time ago.

One of the many downsides to Perl 6, imo, is that this back-to-the-book-oh-yeah aspect is still there -- but there's only incomplete doc and no books yet written by the likes of Larry.

[1] See, for example, https://github.com/moritz/json/blob/master/lib/JSON/Tiny/Gra...

>>Your comment actually made me scroll back to >>...check this thread was.. about Perl 6, not Perl 5!

Well, the context of the parent, and it's parent, was not Perl 6.

I'm a Perl newbie. What can you advise me to read (+exercises) to learn Perl 6?

IMHO Project Euler is a good start. There are solutions published in Perl6 to a large number of them.

This is because it was invented to be possible to use as an interactive shell. When you're working with an interactive shell, you want its language to be (at least somewhat) optimised for writeability, which by necessity means a lack of optimisation for readability. (Explicitness and some level of redundancy aid readability but hurt writeability.)

I believe Perl was meant as a replacement for shell scripts, as well as sed and awk script. It wasn't designed as a interactive shell. For example, the original perl man page says (quoting from http://history.perl.org/PerlTimeline.html ):

        Perl is a interpreted language optimized for scanning  arbi-
     	trary  text  files,  extracting  information from those text
     	files, and printing reports based on that information.  It's
     	also  a good language for many system management tasks.  The
     	language is intended to be practical  (easy  to  use,  effi-
     	cient,  complete)  rather  than  beautiful  (tiny,  elegant,
     	minimal).  It combines (in  the  author's  opinion,  anyway)
     	some  of the best features of C, sed, awk, and sh, so people
     	familiar with those languages should have little  difficulty
     	with  it.

The closest that perl had to an interactive shell was with the "-d" debugger. See for example this synopsis from 2007 at http://archive.oreilly.com/pub/post/writing_a_modern_perl_re... :

> One area in which Perl falls behind other languages is in its lack of a usable Read-Evaluate-Print-Loop. (perl -de 0 just isn't enough for me.) I've used Ruby's irb and a handful of Python shells, and I'm starting to become a fan of ghci, but I fall back on perl -e far too often for my sanity.

An interactive shell should, in my opinion, support more than a REPL. It should also implement job control, like suspending a job or starting jobs in the background. Perl definitely was not invented for that purpose.

I have seen just as much crappy unreadable Python in the wild.

It's an Algol-based language. I never quite got what people "got wrong" with Perl code. Yes, I've seen bad examples, but those would've looked pretty much the same in C, Pascal or Python (deep nesting, bad names, overuse of regexps).

Back in the days one argument was using "grep" or "map" instead of explicit for-loops, but in this day of functional programming, that would seem a weird criticism.

Is it the type glyphs? ($%@)

References are a bit unnecessary, yes.

Yes, it's the type glyphs. (For me, at least.) Back when I was a DBA writing database back-up scripts in Perl, I could never remember how to dereference a value in an array or hash properly. (It reminded me of my problem with pointer notation syntax in C). When I first saw Python, I thought "Wow, it's like Perl, but without the confusing notation." I rewrote the scripts in Python and never looked back.

> I could never remember how to dereference a value in an array or hash properly.

I too struggled with that and came to hate it.

Perl 6 directly addressed this and some related problems.

First, sigils are now invariant - they're just a part of the name that signals which of the three data structure types a particular variable is. Second, there's no need for a `->` dereferencing op.

  my @array = 1,2,3; # `@` sigil means indexable var
  say @array[1]; # prints 2

It might be interesting to look at an example. Perhaps you could share an example of code in Python that illustrates some data structuring code that would be confusing in Perl 5 syntax, I'll try show what the Perl 6 equivalent would be, and we can see if Perl 6 really does clean this part of the language up.

Nested arrays are a pain on the arse in Python. Do I use extend or append? Then strings are treated as character arrays. I far preferred Perl's approach where you would reference or dereference variables instead.

Past: https://news.ycombinator.com/item?id=1279238

Reply on news.ycombinator.com