5 ms·

> From the kind of community and values that Perl advocates has always had, arguably Perl 6 is a natural evolution from Perl 5. I think it's fair to say that P

> From the kind of community and values that Perl advocates has always had, arguably Perl 6 is a natural evolution from Perl 5. I think it's fair to say that Perl 6 represents the values of some very prominent Perl advocates, but not necessarily all of the community. Perl 5 was (is) both a rather eclectic and an eminently practical language. In my view, Perl 6 doubled down on the eclecticism when many users had expected it to double down on the practicality.

raiph 7y ago
> In my view, Perl 6 doubled down on the eclecticism when many users had expected it to double down on the practicality. Is your view of its practicality based on using it heavily or have you mostly or completely left it alone because it's too slow or seems too eclectic or some other reason?
- jhanschoo 7y ago
  From the linked article, Perl 6 tries to support all kinds of paradigms. This really detracts from professional development where communicating code and clear code is necessary. Every language that supports too many paradigms or gives too much expressive power to the user eventually has a "the good parts" books that proscribes a conventional way to program in that language in a professional setting.
  - b2gills 7y ago
    Perl 6 supports all kinds of paradigms, this makes it so that you don't have to write parts of the code in different languages and try to cobble them together. So the code can be written using the clearest paradigm for the task at hand without switching languages. --- The only real bad parts of Perl6 that I can see, is the parts that are copied from elsewhere largely unmodified. The C-style `for` loop is one such example. loop ( my int $a = 0 ; $a < 10 ; ++$a ) { print("hi\n"); } Why would anyone write that when they could write this instead: print("hi\n") xx 10; Where there isn't a chance for an off-by-one error, or accidently creating an infinite loop. You can still use it to intentionally create an infinite loop: my @a = rand xx ∞; # a lazy infinite array of random floating point numbers. --- After someone would write a “the good parts” book, the next major version of the language would probably fix many if not all of the not-so-good parts. If there is a feature that isn't one of “the good parts”, we'll just change it until it is. That's one of the great features of being an easily mutable language, you can mutate it into a better language. (It already has mutated in some small ways.) --- Perl6 doesn't have too many paradigms, if anything it has too few. I would love if it had support for implicit auto currying like Haskell does. (Instead I have to settle for explicit currying.)
  - raiph 7y ago
    > From the linked article, Perl 6 tries to support all kinds of paradigms. There are two relevant aspects to P6. What P6 supports out of the box. And what P6 can support if someone cares to develop that support. Out of the box P6 supports a carefully designed combination of the basics including FP, OO, and procedural/imperative. > This really detracts from professional development where communicating code and clear code is necessary. Your "This" doesn't validly apply to P6. P6 can easily be extended to support arbitrary integrated DSLs but the standard out-of-the-box P6 does not try to support "all kinds of paradigms". Communicating code and clear code is necessary for almost all development scenarios, not just professional. Indeed, this is one of the reasons I favor P6. > Every language that supports too many paradigms or gives too much expressive power to the user eventually has a "the good parts" books that proscribes a conventional way to program in that language in a professional setting. There are about 10 books for P6. None are "the good parts" style books.
- microtherion 7y ago
  I have never used Perl 6, though I have made sporadic efforts to learn it. The development process certainly did not fill me with confidence about practicality, but I had already come to the conclusion that whatever I wanted from Perl, it could not possibly give me while preserving its original character, so (after some detour through Ruby), I switched to Python.
  - raiph 7y ago
    Thanks for replying. Now I'm curious about the things you wanted from Perl that it did/does not provide. :)
    - microtherion 7y ago
      Primarily a class system as a first class citizen of the language, with uniform object syntax, without sigils or other syntactic contortions. Being able to pass around open file handles without having to look up 5 kinds of punctuation. Being able to build up complex data structures without having to use explicit references, where something completely different would auto-vivify itself if I used the wrong sigil.
      - raiph 7y ago
        Makes sense. Thanks for replying. :)
jhanschoo 7y ago
> very prominent Perl advocates, but not necessarily all of the community I agree, but my suspicion is that the larger mainstream community grew out of Perl being in the right time and place for a scripting language borrowing idioms from sh and C. Whereas the central figures directing Perl were always driven in the direction of eclecticism.
- microtherion 7y ago
  > The central figures directing Perl were always driven in the direction of eclecticism I don't agree. Larry Wall always had an eclectic streak, but he was also a very practical guy, trying to scratch system administrators' itches with Perl. A lot of Perl 5's eclecticism stems from its predecessors: sed, awk, sh The other key contributors in Perl 5 in the 90s (The various Perl 5.x pumpkings, Tom Christiansen, Randal Schwarz, etc) were also very practically inclined. But as far as I recall, apart from Larry, most key contributors to Perl 6 did NOT work on the Perl 5 core prior to 2000 (I'm sure somebody could pull up actual names and statistics to confirm or correct this), though they were certainly active in the community.
dragonwriter 7y ago
> In my view, Perl 6 doubled down on the eclecticism when many users had expected it to double down on the practicality. Perl 6 is, in my view, from a language design PoV extremely practical (it has lots of features, but each has a very clear pragmatic rationale). From a project management point of view, it was perhaps insufficiently pragmatic, because there weren't the resources to get a production ready, fully productized implementation in a reasonable period of time.

raiph 7y ago

> In my view, Perl 6 doubled down on the eclecticism when many users had expected it to double down on the practicality. Is your view of its practicality based on using it heavily or have you mostly or completely left it alone because it's too slow or seems too eclectic or some other reason?

jhanschoo 7y ago
From the linked article, Perl 6 tries to support all kinds of paradigms. This really detracts from professional development where communicating code and clear code is necessary. Every language that supports too many paradigms or gives too much expressive power to the user eventually has a "the good parts" books that proscribes a conventional way to program in that language in a professional setting.
- b2gills 7y ago
  Perl 6 supports all kinds of paradigms, this makes it so that you don't have to write parts of the code in different languages and try to cobble them together. So the code can be written using the clearest paradigm for the task at hand without switching languages. --- The only real bad parts of Perl6 that I can see, is the parts that are copied from elsewhere largely unmodified. The C-style `for` loop is one such example. loop ( my int $a = 0 ; $a < 10 ; ++$a ) { print("hi\n"); } Why would anyone write that when they could write this instead: print("hi\n") xx 10; Where there isn't a chance for an off-by-one error, or accidently creating an infinite loop. You can still use it to intentionally create an infinite loop: my @a = rand xx ∞; # a lazy infinite array of random floating point numbers. --- After someone would write a “the good parts” book, the next major version of the language would probably fix many if not all of the not-so-good parts. If there is a feature that isn't one of “the good parts”, we'll just change it until it is. That's one of the great features of being an easily mutable language, you can mutate it into a better language. (It already has mutated in some small ways.) --- Perl6 doesn't have too many paradigms, if anything it has too few. I would love if it had support for implicit auto currying like Haskell does. (Instead I have to settle for explicit currying.)
- raiph 7y ago
  > From the linked article, Perl 6 tries to support all kinds of paradigms. There are two relevant aspects to P6. What P6 supports out of the box. And what P6 can support if someone cares to develop that support. Out of the box P6 supports a carefully designed combination of the basics including FP, OO, and procedural/imperative. > This really detracts from professional development where communicating code and clear code is necessary. Your "This" doesn't validly apply to P6. P6 can easily be extended to support arbitrary integrated DSLs but the standard out-of-the-box P6 does not try to support "all kinds of paradigms". Communicating code and clear code is necessary for almost all development scenarios, not just professional. Indeed, this is one of the reasons I favor P6. > Every language that supports too many paradigms or gives too much expressive power to the user eventually has a "the good parts" books that proscribes a conventional way to program in that language in a professional setting. There are about 10 books for P6. None are "the good parts" style books.
microtherion 7y ago
I have never used Perl 6, though I have made sporadic efforts to learn it. The development process certainly did not fill me with confidence about practicality, but I had already come to the conclusion that whatever I wanted from Perl, it could not possibly give me while preserving its original character, so (after some detour through Ruby), I switched to Python.
- raiph 7y ago
  Thanks for replying. Now I'm curious about the things you wanted from Perl that it did/does not provide. :)
  - microtherion 7y ago
    Primarily a class system as a first class citizen of the language, with uniform object syntax, without sigils or other syntactic contortions. Being able to pass around open file handles without having to look up 5 kinds of punctuation. Being able to build up complex data structures without having to use explicit references, where something completely different would auto-vivify itself if I used the wrong sigil.
    - raiph 7y ago
      Makes sense. Thanks for replying. :)

jhanschoo 7y ago

> very prominent Perl advocates, but not necessarily all of the community I agree, but my suspicion is that the larger mainstream community grew out of Perl being in the right time and place for a scripting language borrowing idioms from sh and C. Whereas the central figures directing Perl were always driven in the direction of eclecticism.

microtherion 7y ago
> The central figures directing Perl were always driven in the direction of eclecticism I don't agree. Larry Wall always had an eclectic streak, but he was also a very practical guy, trying to scratch system administrators' itches with Perl. A lot of Perl 5's eclecticism stems from its predecessors: sed, awk, sh The other key contributors in Perl 5 in the 90s (The various Perl 5.x pumpkings, Tom Christiansen, Randal Schwarz, etc) were also very practically inclined. But as far as I recall, apart from Larry, most key contributors to Perl 6 did NOT work on the Perl 5 core prior to 2000 (I'm sure somebody could pull up actual names and statistics to confirm or correct this), though they were certainly active in the community.

dragonwriter 7y ago

> In my view, Perl 6 doubled down on the eclecticism when many users had expected it to double down on the practicality. Perl 6 is, in my view, from a language design PoV extremely practical (it has lots of features, but each has a very clear pragmatic rationale). From a project management point of view, it was perhaps insufficiently pragmatic, because there weren't the resources to get a production ready, fully productized implementation in a reasonable period of time.