Hacker News Reader

Comment by roryrjb | Hacker News Reader

Perl 6 is probably a great language, I'm not very interested in it, for the reasons someone might pick it, I'd probably pick a different language; of course not for any logical reasons, but still. Perl 5 on the other hand is still a great language for lots of reasons. I hope Perl 6 is renamed and Perl 5 will become Perl again and it will be reinvigorated and more people will consider it again. Don't get me wrong, I don't use Perl day to day because of the type of work I'm doing at $DAYJOB, but people like to dump on it for all the wrong reasons or outdated reasons, but I still believe in it, and I think a lot of people still do but there just isn't the mindshare and no matter what we think about our industry and how it works, that ultimately means new developers won't use it.

View on HN

> Perl 6 is probably a great language,

Does it also have the unparseability problem[0] of Perl 5? That's a deal breaker for a lot of tooling.

[0] https://perlmonks.org/?node_id=663393

No, P6 was intended to fix as many Perl 5 problems as possible, and being eminently parseable was considered very important (and important in deciding to forsake backwards-compatibility, I believe). In fact, a key design-goal is having the language defined by a well-formed grammar that it actually uses to parse itself — and thus that can be used by tools such as editors to parse it just as easily.

This specific problem is not a deal breaker in practice. You solve the problem by adding to the readme of the tool "If the arity of a function cannot be established, we assume no arguments and print an warning. Add {foobar} before the function to assume arguments. Sorry for inconvenience."

No language tooling is perfect. We shouldn't expect that from Perl tooling either.

> No language tooling is perfect.

Java and C# tools are pretty close. But yeah, it's generally hard for dynamic languages.

I mean, it's technically parseable, since otherwise perl (the program) wouldn't be able to function. However, to parse it requires - as that article demonstrates - a preexisting knowledge of what certain words mean, and those meanings are dependent on context. That's easy for perl, since it already has to know what "whatever" means in order to compile/execute it, but is - if not impossible - than prohibitively difficult for something like a syntax highlighter or other tool meant to parse Perl without executing it per se.

Perl is, in this regard, very similar to natural language, which should be entirely unsurprising given that Larry Wall comes from a linguistics background and explicitly designed Perl to borrow various characteristics from natural languages.

From what I understand, though, Perl6's grammar has significantly fewer of these sorts of parsing complexities ("fixing" them was one of the design goals, IIRC).

It's real old and out of date now, but the STD grammar of Perl 6 was written in Perl 6 ahead of time and the Pugs implementation worked against it https://github.com/perl6/std/blob/master/STD.pm6

Rakudo (the current major Perl 6 compiler) also uses grammars to actually parse Perl 6 programs, but from the bootstrap language NQP https://github.com/rakudo/rakudo/blob/master/src/Perl6/Gramm...

Parsing C++ is also undecidable.

Reply on news.ycombinator.com