5 ms·

> Obviously most Perl users understand the benefits of Perl 6. I've been using Perl since 1994, built a company around Perl 5 code and the attractiveness of Pe

> Obviously most Perl users understand the benefits of Perl 6. I've been using Perl since 1994, built a company around Perl 5 code and the attractiveness of Perl 6 for me so far is: 0. I know the price paid (later) for ease of writing (maintainability or lack thereof and lots of traps for the unwary - using Perl::Critic has a devastating effect on perceived "freedom" and simplicity) and a language crammed full of fancy features (the Perl 5 interpreter code base is widely considered unmaintainable these days). I honestly can't think of a single use case of Perl 6 with more than 10 lines or so where it'll work better than e.g. Go.

mst 11y ago
> the Perl 5 interpreter code base is widely considered unmaintainable these days People love to say this, but having read a fair chunk of the sources to perl5, cpython, ruby, Tcl and erlang's VMs, my semi-educated conclusion is "reasonably fast interpreters written in portable C all end up as their own slightly bizarre CPP-supported C dialect, and all end up more similar than they are different".
- lazyjones 11y ago
  > and all end up more similar than they are different". It's not that simple. Tcl, Ruby and Python all have several competing implementations, while to my knowledge nobody has even written a complete Perl 5 parser (except the one in the official Perl 5 code).
  - kamaal 11y ago
    One of the goals of Perl 6 is to ensure several implementations of a Perl 6 specifications should be possible.
  - mst 11y ago
    While this is true, I was specifically addressing the comprehensibility of the core perl5 VM sources - so the existence of N other VMs seems orthogonal to me. Or: I agree with everything you said apart from the implication that what you said is a counter argument to what I said - it seems to me that both can be true without conflict.
  - dragonwriter 11y ago
    > Tcl, Ruby and Python all have several competing implementations, while to my knowledge nobody has even written a complete Perl 5 parser (except the one in the official Perl 5 code). AFAIK, all the viable competing Ruby implementations use the parser from the mainline implementation; parsing Ruby is notoriously hard, and parsing isn't a weak point that alternative implementations usually try to improve.

mst 11y ago

> the Perl 5 interpreter code base is widely considered unmaintainable these days People love to say this, but having read a fair chunk of the sources to perl5, cpython, ruby, Tcl and erlang's VMs, my semi-educated conclusion is "reasonably fast interpreters written in portable C all end up as their own slightly bizarre CPP-supported C dialect, and all end up more similar than they are different".

lazyjones 11y ago
> and all end up more similar than they are different". It's not that simple. Tcl, Ruby and Python all have several competing implementations, while to my knowledge nobody has even written a complete Perl 5 parser (except the one in the official Perl 5 code).
- kamaal 11y ago
  One of the goals of Perl 6 is to ensure several implementations of a Perl 6 specifications should be possible.
- mst 11y ago
  While this is true, I was specifically addressing the comprehensibility of the core perl5 VM sources - so the existence of N other VMs seems orthogonal to me. Or: I agree with everything you said apart from the implication that what you said is a counter argument to what I said - it seems to me that both can be true without conflict.
- dragonwriter 11y ago
  > Tcl, Ruby and Python all have several competing implementations, while to my knowledge nobody has even written a complete Perl 5 parser (except the one in the official Perl 5 code). AFAIK, all the viable competing Ruby implementations use the parser from the mainline implementation; parsing Ruby is notoriously hard, and parsing isn't a weak point that alternative implementations usually try to improve.