4 ms·

You are speaking of the 22 year old Perl 5. This HN thread is about Perl 6. Larry Wall (primary author of record for both Perl 5 and Perl 6) noted in an articl

by raiph 10y ago

You are speaking of the 22 year old Perl 5. This HN thread is about Perl 6. Larry Wall (primary author of record for both Perl 5 and Perl 6) noted in an article[1] that: "Perl 6 is also a completely different language ... [that specifically addresses] readability" Or, in greater depth: "Perl 6 is also a completely different language that has been rethought and rebalanced on every level, with much stronger support for both functional and object-oriented programming as well as reactive and concurrent programming. There is now pervasive concern for composability, evolvability, readability, and maintainability. We try to "hang everything on the right peg" to allow proper separation of concerns. While we still believe in providing multiple ways to accomplish something, we now try to encourage one of those ways as an appropriate starting default. So we think the language scales both down and up to the level of talent of the programmer; the programmer can start out in "baby talk" without getting into too much trouble and then whenever he or she is ready to learn a new concept, the language is ready to support that and to make it easy to refactor the code as the programmer grows in sophistication. For developers who are already sophisticated, they'll see that most of the problems endemic to the currently available dynamic languages are solved in Perl 6. We understand lexical and dynamic scoping. We detect most typos at compile time. We don't have a global interpreter lock. We encourage Smalltalk-style trait composition over uncontrolled mixins, multiple inheritance, or monkey patching." [1] http://www.infoworld.com/article/2882300/perl/perl-creator-larry-wall-rethought-version-6-due-this-year.html http://www.infoworld.com/article/2882300/perl/perl-creator-l...

beat 10y ago
Great. So why should I go to Perl 6? What's the compelling use case? Ruby had a compelling use case - Rails. Rails completely reinvented how web applications could be written, and it did so in large part because it relied on the nature of the language (specifically its reliance on duck typing). That's why attempts to mimic Rails in other languages always feel a little clunky. JavaScript, for all its blecherous losing horror, had a compelling use case - it ran in browsers. Later, Node became a compelling use case, for dealing with both performance issues and package management problems that plagued other systems (including Rails). Python had multiple compelling use cases. It became very popular in math programming and teaching, for its clarity and consistency. Perl's compelling use case was with Perl 4, as a general purpose glue scripting language in a Unix world. It solved tremendous problems. Perl 5 didn't have a compelling case, and it grossly exaggerated the already bad problems with complexity and inconsistency. Am I talking about Perl 5? Yes, because for 22 YEARS, we've been saddled with that crap. Two decades of waiting for Perl 6, for Perl to unfuck itself and become something useful for more than one person at a time. That's like, my entire career. Longer than most programmers in this industry have been in the industry. Longer than some of them have been alive. 22 years. So why, why, why should I switch? What's the promise now? What problem am I having with Ruby that it can solve?
- raiph 10y ago
  > So why, why, why should I switch? What's the promise now? What problem am I having with Ruby that it can solve? All good questions. My personal answers boil down to "no need" (to switch), "see the rest of this thread" (to read what promise Perl 6 might have), and perhaps https://docs.perl6.org/language/rb-nutshell https://docs.perl6.org/language/rb-nutshell (to read how someone familiar with Ruby explains how to map Ruby knowledge on to Perl 6).
  - beat 10y ago
    Since programming language is often tied to programming framework, then switching languages means sacrificing frameworks. That's a problem. Admittedly, it's a form of Lava Flow Antipattern, but it's significant. I'm giving up a useful toolset, and I'm giving up accumulated domain knowledge. So why do it? Mainly, if the framework I'm currently using can't do things I need to do, or if it's incredibly painful to use. To the extent that someone has neither of those problems, a new language is a cure worse than the disease, whatever its benefits. Look at it this way... imagine there's a rib joint across the street. It may not have the best bbq, but it's there. Do I walk across the street for bbq, or do I drive halfway across town to get slightly better? I'll take what's there, thank you. Now, if I'm a vegan, I'll get up and go somewhere else.
    - Ulti 10y ago
      I think that says more about you than everyone else. I would walk halfway across town for slightly better bbq. Ultimately what is there to life than improving the quality of your experience. The issue is what consitutes better BBQ is completely subjective. So we might start from opposite sides of town and try and get to each others nearby BBQ ribs place. That's just human nature. With respect to "frameworks" some of this tends to be kind of centric to how you program. For the last decade most of my work isn't within any framework because its algorithmic with only a need for string IO and some parsers. Perl 6 for that is the framework.
- b2gills 10y ago
  The Perl 6 project started only slightly more than a decade and a half ago. Ruby's "DSL" ability is what allowed Rails, in Perl 6 everything is a DSL. Even strings are written a customizable DSL. You can turn on and off string features, and add new ones. It goes even deeper than that, you can swap the parser out with a new one mid-parse. One implementing Ruby for example. ( While it is possible to do this today, this isn't specced yet, as the exact way to do this is still in flux to get it to the same quality as the rest of the language ) So in a sense, all programming languages can be thought of as a subset of Perl 6. ( There would be little point in doing this for assembly though, as it will probably have to be emulated in most cases ) This feature is usually only used to slightly alter the existing parser currently. That isn't even the best part, many features from other high level languages have already been brought together in Perl 6, in a way that makes them seem as if they have always belonged together. If you asked a random sampling of people about which feature that they like in Perl 6, you will probably get a different one from each.
deleted 10y ago
[deleted]

by raiph 10y ago

beat 10y ago

Great. So why should I go to Perl 6? What's the compelling use case? Ruby had a compelling use case - Rails. Rails completely reinvented how web applications could be written, and it did so in large part because it relied on the nature of the language (specifically its reliance on duck typing). That's why attempts to mimic Rails in other languages always feel a little clunky. JavaScript, for all its blecherous losing horror, had a compelling use case - it ran in browsers. Later, Node became a compelling use case, for dealing with both performance issues and package management problems that plagued other systems (including Rails). Python had multiple compelling use cases. It became very popular in math programming and teaching, for its clarity and consistency. Perl's compelling use case was with Perl 4, as a general purpose glue scripting language in a Unix world. It solved tremendous problems. Perl 5 didn't have a compelling case, and it grossly exaggerated the already bad problems with complexity and inconsistency. Am I talking about Perl 5? Yes, because for 22 YEARS, we've been saddled with that crap. Two decades of waiting for Perl 6, for Perl to unfuck itself and become something useful for more than one person at a time. That's like, my entire career. Longer than most programmers in this industry have been in the industry. Longer than some of them have been alive. 22 years. So why, why, why should I switch? What's the promise now? What problem am I having with Ruby that it can solve?

raiph 10y ago
> So why, why, why should I switch? What's the promise now? What problem am I having with Ruby that it can solve? All good questions. My personal answers boil down to "no need" (to switch), "see the rest of this thread" (to read what promise Perl 6 might have), and perhaps https://docs.perl6.org/language/rb-nutshell https://docs.perl6.org/language/rb-nutshell (to read how someone familiar with Ruby explains how to map Ruby knowledge on to Perl 6).
- beat 10y ago
  Since programming language is often tied to programming framework, then switching languages means sacrificing frameworks. That's a problem. Admittedly, it's a form of Lava Flow Antipattern, but it's significant. I'm giving up a useful toolset, and I'm giving up accumulated domain knowledge. So why do it? Mainly, if the framework I'm currently using can't do things I need to do, or if it's incredibly painful to use. To the extent that someone has neither of those problems, a new language is a cure worse than the disease, whatever its benefits. Look at it this way... imagine there's a rib joint across the street. It may not have the best bbq, but it's there. Do I walk across the street for bbq, or do I drive halfway across town to get slightly better? I'll take what's there, thank you. Now, if I'm a vegan, I'll get up and go somewhere else.
  - Ulti 10y ago
    I think that says more about you than everyone else. I would walk halfway across town for slightly better bbq. Ultimately what is there to life than improving the quality of your experience. The issue is what consitutes better BBQ is completely subjective. So we might start from opposite sides of town and try and get to each others nearby BBQ ribs place. That's just human nature. With respect to "frameworks" some of this tends to be kind of centric to how you program. For the last decade most of my work isn't within any framework because its algorithmic with only a need for string IO and some parsers. Perl 6 for that is the framework.
b2gills 10y ago
The Perl 6 project started only slightly more than a decade and a half ago. Ruby's "DSL" ability is what allowed Rails, in Perl 6 everything is a DSL. Even strings are written a customizable DSL. You can turn on and off string features, and add new ones. It goes even deeper than that, you can swap the parser out with a new one mid-parse. One implementing Ruby for example. ( While it is possible to do this today, this isn't specced yet, as the exact way to do this is still in flux to get it to the same quality as the rest of the language ) So in a sense, all programming languages can be thought of as a subset of Perl 6. ( There would be little point in doing this for assembly though, as it will probably have to be emulated in most cases ) This feature is usually only used to slightly alter the existing parser currently. That isn't even the best part, many features from other high level languages have already been brought together in Perl 6, in a way that makes them seem as if they have always belonged together. If you asked a random sampling of people about which feature that they like in Perl 6, you will probably get a different one from each.

deleted 10y ago

[deleted]