3 ms·
> Numerical operations are opaque as you never quite know if it's a rational or a float. Not so. When you put in floats, you get floats out. If you want always
by perlgeek 9y ago
> Numerical operations are opaque as you never quite know if it's a rational or a float.
Not so. When you put in floats, you get floats out. If you want always-rational numbers, put in FatRat and you get out FatRat -- with the predictable bad performance on algorithms that converge on irrational numbers.
> The grammar engine is inferior to other languages 3rd party modules
Nothing stops you from using superior 3rd party modules in Perl 6. Heck, you can use Python modules through Inline::Python in Perl 6.
> hard to debug
I haven't found it harder to debug than other parser libraries, but your mileage my vary. I'm a fan of Grammar::Tracer, which hasn't failed me yet.
> Everything seems to be writable in a multitude of ways with no clear indication if these ways are functionally different.
That is true, but I find it irksome that you mention it right next to Python, which also has a multitude of ways to do different things, even though the Zen of Python says there should be just one way. Think string formatting, for example. I believe it's a trait of every programming language that doesn't set out to babysit you.
- wodenokoto 9y agoThank you for inputs on the specifics. Would you say the reviewer/author is misunderstanding Perl6, or that I am misunderstanding the review?
- Ultimatt 9y agoI think you are reading in too much the criticism of how grammars work. Ultimately the leading compiler uses the Perl 6 grammar engine and tooling to implement the language compiler! So if your needs are substantially less complex than needing to implement your own programming language, say parse some XML or something. Then the grammar engine is more than competent. The authors criticism of how to handle errors during parse and making a really advanced robust parser is definitely fair. However, the technology for doing this in a deep way does exist. It's already found in the grammar debugger module from one of the core devs (https://github.com/jnthn/grammar-debugger https://github.com/jnthn/grammar-debugger). There just isn't perhaps a nicer "user" level API for you handling parsing in a flexible way when something goes wrong. There are mechanisms for making your grammar flexible though such as proto rules/tokens/regexes https://docs.perl6.org/language/grammars#Protoregexes https://docs.perl6.org/language/grammars#Protoregexes here when different options are encountered you can trigger different code to handle whats being parsed.
- perlgeek 9y agoThe review touches the basics, and can't go into all the options that are available.
- zengargoyle 9y agoCheck out Perl 6's (or Rakudo's if you prefer) error messages. If they are LTA (Less Than Awesome), it's a bug. Often the Perl 6 Grammar that is parsing my Perl 6 code actually tells me things I didn't notice.... The stuff you need is available, but Perl 6 isn't going to give you an automagic generic error that's any better than "Parse failed at line 5 character 13". You can do that yourself rather easily, and if you want no LTA errors, you'll need to do them yourself.
- raiph 9y agoEvan did not intend folk to read what he wrote as a definitive testimonial. https://www.reddit.com/r/programming/comments/6thwnx/a_review_of_perl_6/dllv7uh/ https://www.reddit.com/r/programming/comments/6thwnx/a_revie...