Hacker News Reader

Comment by akkartik | Hacker News Reader

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.

Reply on news.ycombinator.com