4 ms·

> 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

by 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. :)

by raiph 7y ago

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. :)