4 ms·

> Hopefully though this post will convince you to drop that veil of hatred and see the intentions behind these design decisions. I suppose that the article hon

> Hopefully though this post will convince you to drop that veil of hatred and see the intentions behind these design decisions. I suppose that the article honestly achieved what it said it set out to do. It's just that those design decisions are more like what one expected from (an albeit well-thought-out) toy or hobby language rather than a next iteration of one of the most ubiquitous languages during its heyday. That's where most of the hate and disappointment comes from, the mismatch of expectations. I suppose that the article and that previous linked page were written deliberately to both seem like a satire to the extent that you viewed it as a mainstream scripting language, and an useful overview of Perl 6 to the extent that you are willing to let it be a toy language or an experiment. From the kind of community and values that Perl advocates has always had, arguably Perl 6 is a natural evolution from Perl 5. But earlier versions of Perl were the right language in the right place when the hashes-and-arrays dynamic interpretable languages started to gain traction over the heavyweight OOP C-style languages for tasks (web servers, etc.) that would increasingly becoming more heavyweight, so there was this expectation that Perl would evolve to serve this community's needs when it didn't, leading to the mismatch of expectations.

microtherion 7y ago
> 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.
- 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.

microtherion 7y ago

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