11 ms·

It just might be possible that Perl 6's crazy long development process can produce the best-adopted second system around Unfortunately, I don't share the s

It just might be possible that Perl 6's crazy long development process can produce the best-adopted second system around Unfortunately, I don't share the same optimism as the OP. In the real world, adoption is not only driven by how cool a language is, but the ecosystem of tools and developers around it. There are lots of Perl 5 codebases which won't be migrated because it's too expensive. The true lesson learned for language developers is: Don't break backwards compatibility. Ever. The Python community made this mistake, and they acknowledge it. Guido said this won't happen again. But at least for the case of Python 3, the number of breakages is relatively small, and the migration from 2 to 3 while tedious, it's not that hard. Even so, the migration of the whole ecosystem has been really really slow. But I think in the end the community will move. The Perl case, on the other side, is much worse. Migrating a relatively complex project from 5 to 6 is extraordinarily hard. It's probably the same as a whole rewrite. Also, the community is divided, with some developers keeping the improvement of Perl 5, fixing bugs and adding new features. There is no incentive for migration. If the migration has been so slow for Python 3, which had a much smaller barrier, I don't see how it could be better for Perl 6. New languages are able to develop a new ecosystem when they introduce innovative features, e.g. Rust. But Perl 6 while being a nice language, doesn't seem to have any killer feature compared to mainstream languages.

brudgers 11y ago
I would never say it is likely that any language will be well-adopted. Fortune plays too big a role. However, what Perl's long development cycle means is that its widespread adoption would depend on new users taking it up. It will be a new language from their standpoint and backward compatibility will be less an issue. Widespread adoption will also require transitioning of a core group of existing Perl power users. After 15 years, all the emotionally inflamed debates, tirades and rants have probably run their course. Everyone knows where they stand and has had time to come to piece with it...and even the youngest among those who have been there since the decision are long out of short pants. Zealots on both sides have been living together a long time.
amyjess 11y ago
The more I think about it, the more I realize that Perl 6 was misnamed. It should have been treated as a new language with some Perl heritage, not just a new version of Perl. The Perl 5 diehards aren't going to switch, and people who aren't already Perl hackers are going to think it's the same old Perl that scared them off ages ago. It's a shame, because Perl 6 is a great language (and I say this as somebody who was put off by Perl 5), and the Parrot VM is particularly awesome. It also has some of the best error reporting I've seen: it offers a number of possible solutions, and if you try to use a Perl 5-ism that's not supported anymore, it'll tell you what the Perl 6 equivalent is.
- chaosfox 11y ago
  As someone that uses Perl daily I totally agree with you. The name not only is bad for newcomers but also for Perl itself. Perl 5.0.0 was released in 1994 (!), today's Perl 5.20 is miles ahead but we can't bump the version because it would only make things even more confusing..
- gahahaha 11y ago
  > Perl 6 was misnamed Damian Conway agrees with you - but Larry Wall decides, and he insisted on calling it Perl 6. Maybe Conway has a point, but maybe so many people wouldn't have worked so hard on it for so long if it was called something else.
- DonHopkins 11y ago
  Perl unless true
- riffraff 11y ago
  > and people who aren't already Perl hackers are going to think it's the same old Perl that scared them off ages ago. consire though, that perl6 is soon going to be 20 years old, there is a whole generation of devs which were never scared off by perl5 at all. I say this as someone who, ten years ago, didn't understand a lot of the complains about perl because they were mostly directed at perl4 problems :)
somebehemoth 11y ago
"The Perl case, on the other side, is much worse. Migrating a relatively complex project from 5 to 6 is extraordinarily hard. It's probably the same as a whole rewrite." One of the features of Perl 6 discussed in the article is "Fully backwards compatible with the use of Inline::Perl5". So why is it extraordinarily hard to migrate? I admit it is non-trivial, but the designers made it a key point to be backward compatible. No need to rewrite, Perl5 and Perl6 can co-exist in the same codebase. "There is no incentive for migration." Have you looked at the features Perl6 provides[1]? They may not seem valuable to you but it cannot be denied that the new features are plentiful and powerful from a programming language perspective. [1]http://www.perlfoundation.org/perl6/index.cgi?the_long_perl_6_super_feature_list http://www.perlfoundation.org/perl6/index.cgi?the_long_perl_...
- ceronman 11y ago
  Inline::Perl5 is just some glue to communicate to a Perl 5 interpreter from Perl 6. It's a simple form of inter-process communication between Perl 5 and 6. It's not that you can continue writing your Perl 5 program/library in Perl 6. This approach is not only really bad for performance, it's also very limited. For example, you can't just share data between both interpreters, however you can send some basic datatypes from one to the other. This has been done for other languages as well, for example, check Inline::Python [1]. It's an interesting thing, but not very useful for production. [1] http://search.cpan.org/~nine/Inline-Python-0.49/Python.pod http://search.cpan.org/~nine/Inline-Python-0.49/Python.pod
  - cygx 11y ago
    You do have a point, but your description sells Inline::Perl5 short: For example, it is possible for Perl6 classes to inherit from Perl5 ones.
    - raiph 11y ago
      Note that Inline::Python for Perl 6 allows one to do likewise with Python. [1] "even PyQt's low level mingling finds all the information it needs and we can write programs using PyQt in Perl 6 :)" [1] https://github.com/niner/Inline-Python/commit/82cab4181d98f046c4529335f2c1748f1e89593c https://github.com/niner/Inline-Python/commit/82cab4181d98f0...
muraiki 11y ago
Yes, rewriting Perl 5 in Perl 6 would be quite an endeavor. However, that's why Inline::Perl5 was invented. It lets you use Perl 5 libraries in Perl 6 code: use Inline::Perl5; use MyProprietaryModule:from<Perl5>; use YAML:from<Perl5>; # take advantage of p5 cpan my $foo = YAML::LoadFile('foo.yaml'); my $bar = MyProprietaryModule.someMethod('baz'); So what this allows you to do is use P6 features where they might benefit your project, but still use all the P5 code you've invested in. There are some cases where Inline::Perl5 has problems, such as running P5 code multithreaded, but aside from that I've had few problems using it with stuff from CPAN and with my company's own proprietary code base. There are also the modules Inline::Python and Inline::Java (for the JVM backend), but I haven't used them.
- ceronman 11y ago
  Inline::Perl5 is just a very thin layer to communicate with a Perl 5 process. This works well for small things but it's not practical for more complex ones. You can call code of any language from any language using this technique, that doesn't mean the languages are integrated.
  - cygx 11y ago
    Note that no actual IPC is involved: The Perl5 interpreter gets loaded from a shared library and afaict does not run in a separate process.
  - raiph 11y ago
    Have you tried it this year? In his three minute lightning talk in October last year[1] nine demo'd the small things I think you're talking about (calling Python code from within Perl 5 code from within Perl 6 code and using XS-based Perl 5 modules from CPAN). But that talk was merely a snapshot of his progress just a few hours after he began. If you read the examples in the README of Inline::Perl5 as it is today I think you'll see that it is already a lot more capable than you are thinking it is. [2] [1] https://www.youtube.com/watch?v=m_Y-lvQP6jI&list=UU7PuZDAIVMyE7mgkZHunXGw https://www.youtube.com/watch?v=m_Y-lvQP6jI&list=UU7PuZDAIVM... [2] https://github.com/niner/Inline-Perl5 https://github.com/niner/Inline-Perl5
agumonkey 11y ago
I wonder if python3 design helped writing shorter and more robust programs.
- rcthompson 11y ago
  I would think that correct unicode handling would satisfy that requirement.
  - agumonkey 11y ago
    That's what I was thinking about when typing my comment. I only wanted field reports, not only theoritical (even though clear) advantages.
  - raiph 11y ago
    It may be instructive to consider what exactly you mean by "correct unicode handling". What would you say is the length of the Thai word ปฏิบัติจริง ? What does Python 3 think is the length? What does Perl 6 think is the length? Can you explain the difference? And what do you think are the practical implications for code in Python 3 vs Perl 6 as it relates to "correct unicode handling", shorter code, and robustness?
    - agumonkey 11y ago
      I think he meant consistent more than correct. I've read that once decoded, the data will be stable, unlike python2 where transcoding (lossy one that is) may occur between different modules under your nose.
      - raiph 11y ago
        Right. Aiui both Python 3 and Perl 6 allow correct handling of Unicode byte buffers and whole strings. Which will be great for applications that don't need to do anything at substring or character level. Afaict, in Python 3, code that does things at substring/character level to Thai, Chinese, etc. text will be: * buggy, even spuriously cutting characters in half if any string changes are made, if standard string/substring/character functions are used OR * verbose and messy, if the reqired-for-correctness grapheme handling is introduced
raiph 11y ago
> Migrating a relatively complex project from 5 to 6 is extraordinarily hard. Are you willing to share any details of the project you migrated?
Negitivefrags 11y ago
> The true lesson learned for language developers is: Don't break backwards compatibility. Ever. Certainly true, and yet this is the situation that led to a lot of the hate for C++. The reason for the numerous meanings of the "static" keyword for example is because if you introduce more keywords then you might break peoples code that used those proposed keywords as variable names. And then of course a large percentage of C++'s baggage is due to backwards compatibility with C in the first place. Without that baggage C++ would be a much better language and yet you can't deny C++'s success from that decision. So the moral of the story is that you either make a language nobody uses or you continue to cop flak for all your old decisions forever.
- JoeAltmaier 11y ago
  Yeah, life sucks. There's no good solution to all that. The approach used for new keywords is to use lots of '__' on one end or the other. Anybody that used variables with those names was asking for trouble. Yet, then, the new keywords look like crap. Nobody wins. My favorite, years ago, was the usage in the normal C header files in Linux of a linked-list variable with the name 'new'. It was obvious that nobody in Linux-land had ever compiled a C++ program.
  - cygx 11y ago
    New C keywords now use a leading underscore (_Atomic, _Bool, _Static_assert, ...) and come with a header file you can include to get a more friendly name (stdbool.h, stdatomic.h, assert.h, ....). As to not keeping your C code C++ clean: Just use a dedicated C compiler and link the object files.
    - JoeAltmaier 11y ago
      Then what header files do you compile your C++ with? That's all there was at the time.
      - cygx 11y ago
        If it occurs in public header files or if you use C++ keywords as external symbols, that is indeed a bit... inconsiderate, to say the least. Header files intended for public comsumption should stick to the intersection of C and C++ in most cases.
kamaal 11y ago
>>In the real world, adoption is not only driven by how cool a language is, but the ecosystem of tools and developers around it. If it gets even half close to where Perl 5 is we can only expect great things from Perl 6. >>The true lesson learned for language developers is: Don't break backwards compatibility. Ever. If you look at the whole grammar system and the compiler design of Perl 6 you will see this is precisely what they have done. >>Guido said this won't happen again. Not that easy. To compete with newer and powerful tools you have to add features that you need. You can't do that without bloat or breaking things. Again look up the Perl 6 compiler design. >>Migrating a relatively complex project from 5 to 6 is extraordinarily hard. This is like saying migrating from C to Java is hard. Of course it is, because 5 and 6 are two different languages. >>There is no incentive for migration. There never ever was and should never be, Perl 6 is for new projects. Perl 5 and Perl 6 are two different languages which will have their own evolution path. >>But Perl 6 while being a nice language, doesn't seem to have any killer feature compared to mainstream languages. Seriously?? Have you even looked at Perl 6.
- ceronman 11y ago
  > Seriously?? Have you even looked at Perl 6. Yes I have. Many interesting features. Most of them not good enough to be considered killer, IMO. What are your suggestions?
  - deleted 11y ago
    [deleted]
  - raiph 11y ago
    Here's one I've started to focus on in the last few months: say "ปฏิบัติจริง".chars; # says 7 [1] Perl 6 may be a game changer in years to come among those who need to munge text that's Thai, Chinese, etc. http://www.reddit.com/r/perl/comments/2szv7m/beginner_programmer_here_looking_for_help_for_an/cqzk3hi http://www.reddit.com/r/perl/comments/2szv7m/beginner_progra...
    - ceronman 11y ago
      I don't see how this is a language killer feature. It looks more like a library feature. And yes, Perl 6 has a superb unicode library. In other languages, you can add the functionality as libraries. This is an example in Python: import unicodedata def count_graphemes(string): count = 0 for codepoint in string: if not unicodedata.category(codepoint).startswith('M'): count += 1 return count print(count_graphemes("ปฏิบัติจริง")) # prints 7 This example is over simplified as grapheme clusters are trickier to detect, but proper support is coming to Python's standard library: http://bugs.python.org/issue18406 http://bugs.python.org/issue18406

brudgers 11y ago

I would never say it is likely that any language will be well-adopted. Fortune plays too big a role. However, what Perl's long development cycle means is that its widespread adoption would depend on new users taking it up. It will be a new language from their standpoint and backward compatibility will be less an issue. Widespread adoption will also require transitioning of a core group of existing Perl power users. After 15 years, all the emotionally inflamed debates, tirades and rants have probably run their course. Everyone knows where they stand and has had time to come to piece with it...and even the youngest among those who have been there since the decision are long out of short pants. Zealots on both sides have been living together a long time.

amyjess 11y ago

The more I think about it, the more I realize that Perl 6 was misnamed. It should have been treated as a new language with some Perl heritage, not just a new version of Perl. The Perl 5 diehards aren't going to switch, and people who aren't already Perl hackers are going to think it's the same old Perl that scared them off ages ago. It's a shame, because Perl 6 is a great language (and I say this as somebody who was put off by Perl 5), and the Parrot VM is particularly awesome. It also has some of the best error reporting I've seen: it offers a number of possible solutions, and if you try to use a Perl 5-ism that's not supported anymore, it'll tell you what the Perl 6 equivalent is.

chaosfox 11y ago
As someone that uses Perl daily I totally agree with you. The name not only is bad for newcomers but also for Perl itself. Perl 5.0.0 was released in 1994 (!), today's Perl 5.20 is miles ahead but we can't bump the version because it would only make things even more confusing..
gahahaha 11y ago
> Perl 6 was misnamed Damian Conway agrees with you - but Larry Wall decides, and he insisted on calling it Perl 6. Maybe Conway has a point, but maybe so many people wouldn't have worked so hard on it for so long if it was called something else.
DonHopkins 11y ago
Perl unless true
riffraff 11y ago
> and people who aren't already Perl hackers are going to think it's the same old Perl that scared them off ages ago. consire though, that perl6 is soon going to be 20 years old, there is a whole generation of devs which were never scared off by perl5 at all. I say this as someone who, ten years ago, didn't understand a lot of the complains about perl because they were mostly directed at perl4 problems :)

somebehemoth 11y ago

"The Perl case, on the other side, is much worse. Migrating a relatively complex project from 5 to 6 is extraordinarily hard. It's probably the same as a whole rewrite." One of the features of Perl 6 discussed in the article is "Fully backwards compatible with the use of Inline::Perl5". So why is it extraordinarily hard to migrate? I admit it is non-trivial, but the designers made it a key point to be backward compatible. No need to rewrite, Perl5 and Perl6 can co-exist in the same codebase. "There is no incentive for migration." Have you looked at the features Perl6 provides[1]? They may not seem valuable to you but it cannot be denied that the new features are plentiful and powerful from a programming language perspective. [1]http://www.perlfoundation.org/perl6/index.cgi?the_long_perl_6_super_feature_list http://www.perlfoundation.org/perl6/index.cgi?the_long_perl_...

ceronman 11y ago
Inline::Perl5 is just some glue to communicate to a Perl 5 interpreter from Perl 6. It's a simple form of inter-process communication between Perl 5 and 6. It's not that you can continue writing your Perl 5 program/library in Perl 6. This approach is not only really bad for performance, it's also very limited. For example, you can't just share data between both interpreters, however you can send some basic datatypes from one to the other. This has been done for other languages as well, for example, check Inline::Python [1]. It's an interesting thing, but not very useful for production. [1] http://search.cpan.org/~nine/Inline-Python-0.49/Python.pod http://search.cpan.org/~nine/Inline-Python-0.49/Python.pod
- cygx 11y ago
  You do have a point, but your description sells Inline::Perl5 short: For example, it is possible for Perl6 classes to inherit from Perl5 ones.
  - raiph 11y ago
    Note that Inline::Python for Perl 6 allows one to do likewise with Python. [1] "even PyQt's low level mingling finds all the information it needs and we can write programs using PyQt in Perl 6 :)" [1] https://github.com/niner/Inline-Python/commit/82cab4181d98f046c4529335f2c1748f1e89593c https://github.com/niner/Inline-Python/commit/82cab4181d98f0...

muraiki 11y ago

Yes, rewriting Perl 5 in Perl 6 would be quite an endeavor. However, that's why Inline::Perl5 was invented. It lets you use Perl 5 libraries in Perl 6 code: use Inline::Perl5; use MyProprietaryModule:from<Perl5>; use YAML:from<Perl5>; # take advantage of p5 cpan my $foo = YAML::LoadFile('foo.yaml'); my $bar = MyProprietaryModule.someMethod('baz'); So what this allows you to do is use P6 features where they might benefit your project, but still use all the P5 code you've invested in. There are some cases where Inline::Perl5 has problems, such as running P5 code multithreaded, but aside from that I've had few problems using it with stuff from CPAN and with my company's own proprietary code base. There are also the modules Inline::Python and Inline::Java (for the JVM backend), but I haven't used them.

ceronman 11y ago
Inline::Perl5 is just a very thin layer to communicate with a Perl 5 process. This works well for small things but it's not practical for more complex ones. You can call code of any language from any language using this technique, that doesn't mean the languages are integrated.
- cygx 11y ago
  Note that no actual IPC is involved: The Perl5 interpreter gets loaded from a shared library and afaict does not run in a separate process.
- raiph 11y ago
  Have you tried it this year? In his three minute lightning talk in October last year[1] nine demo'd the small things I think you're talking about (calling Python code from within Perl 5 code from within Perl 6 code and using XS-based Perl 5 modules from CPAN). But that talk was merely a snapshot of his progress just a few hours after he began. If you read the examples in the README of Inline::Perl5 as it is today I think you'll see that it is already a lot more capable than you are thinking it is. [2] [1] https://www.youtube.com/watch?v=m_Y-lvQP6jI&list=UU7PuZDAIVMyE7mgkZHunXGw https://www.youtube.com/watch?v=m_Y-lvQP6jI&list=UU7PuZDAIVM... [2] https://github.com/niner/Inline-Perl5 https://github.com/niner/Inline-Perl5

agumonkey 11y ago

I wonder if python3 design helped writing shorter and more robust programs.

rcthompson 11y ago
I would think that correct unicode handling would satisfy that requirement.
- agumonkey 11y ago
  That's what I was thinking about when typing my comment. I only wanted field reports, not only theoritical (even though clear) advantages.
- raiph 11y ago
  It may be instructive to consider what exactly you mean by "correct unicode handling". What would you say is the length of the Thai word ปฏิบัติจริง ? What does Python 3 think is the length? What does Perl 6 think is the length? Can you explain the difference? And what do you think are the practical implications for code in Python 3 vs Perl 6 as it relates to "correct unicode handling", shorter code, and robustness?
  - agumonkey 11y ago
    I think he meant consistent more than correct. I've read that once decoded, the data will be stable, unlike python2 where transcoding (lossy one that is) may occur between different modules under your nose.
    - raiph 11y ago
      Right. Aiui both Python 3 and Perl 6 allow correct handling of Unicode byte buffers and whole strings. Which will be great for applications that don't need to do anything at substring or character level. Afaict, in Python 3, code that does things at substring/character level to Thai, Chinese, etc. text will be: * buggy, even spuriously cutting characters in half if any string changes are made, if standard string/substring/character functions are used OR * verbose and messy, if the reqired-for-correctness grapheme handling is introduced

raiph 11y ago

> Migrating a relatively complex project from 5 to 6 is extraordinarily hard. Are you willing to share any details of the project you migrated?

Negitivefrags 11y ago

> The true lesson learned for language developers is: Don't break backwards compatibility. Ever. Certainly true, and yet this is the situation that led to a lot of the hate for C++. The reason for the numerous meanings of the "static" keyword for example is because if you introduce more keywords then you might break peoples code that used those proposed keywords as variable names. And then of course a large percentage of C++'s baggage is due to backwards compatibility with C in the first place. Without that baggage C++ would be a much better language and yet you can't deny C++'s success from that decision. So the moral of the story is that you either make a language nobody uses or you continue to cop flak for all your old decisions forever.

JoeAltmaier 11y ago
Yeah, life sucks. There's no good solution to all that. The approach used for new keywords is to use lots of '__' on one end or the other. Anybody that used variables with those names was asking for trouble. Yet, then, the new keywords look like crap. Nobody wins. My favorite, years ago, was the usage in the normal C header files in Linux of a linked-list variable with the name 'new'. It was obvious that nobody in Linux-land had ever compiled a C++ program.
- cygx 11y ago
  New C keywords now use a leading underscore (_Atomic, _Bool, _Static_assert, ...) and come with a header file you can include to get a more friendly name (stdbool.h, stdatomic.h, assert.h, ....). As to not keeping your C code C++ clean: Just use a dedicated C compiler and link the object files.
  - JoeAltmaier 11y ago
    Then what header files do you compile your C++ with? That's all there was at the time.
    - cygx 11y ago
      If it occurs in public header files or if you use C++ keywords as external symbols, that is indeed a bit... inconsiderate, to say the least. Header files intended for public comsumption should stick to the intersection of C and C++ in most cases.

kamaal 11y ago

>>In the real world, adoption is not only driven by how cool a language is, but the ecosystem of tools and developers around it. If it gets even half close to where Perl 5 is we can only expect great things from Perl 6. >>The true lesson learned for language developers is: Don't break backwards compatibility. Ever. If you look at the whole grammar system and the compiler design of Perl 6 you will see this is precisely what they have done. >>Guido said this won't happen again. Not that easy. To compete with newer and powerful tools you have to add features that you need. You can't do that without bloat or breaking things. Again look up the Perl 6 compiler design. >>Migrating a relatively complex project from 5 to 6 is extraordinarily hard. This is like saying migrating from C to Java is hard. Of course it is, because 5 and 6 are two different languages. >>There is no incentive for migration. There never ever was and should never be, Perl 6 is for new projects. Perl 5 and Perl 6 are two different languages which will have their own evolution path. >>But Perl 6 while being a nice language, doesn't seem to have any killer feature compared to mainstream languages. Seriously?? Have you even looked at Perl 6.

ceronman 11y ago
> Seriously?? Have you even looked at Perl 6. Yes I have. Many interesting features. Most of them not good enough to be considered killer, IMO. What are your suggestions?
- deleted 11y ago
  [deleted]
- raiph 11y ago
  Here's one I've started to focus on in the last few months: say "ปฏิบัติจริง".chars; # says 7 [1] Perl 6 may be a game changer in years to come among those who need to munge text that's Thai, Chinese, etc. http://www.reddit.com/r/perl/comments/2szv7m/beginner_programmer_here_looking_for_help_for_an/cqzk3hi http://www.reddit.com/r/perl/comments/2szv7m/beginner_progra...
  - ceronman 11y ago
    I don't see how this is a language killer feature. It looks more like a library feature. And yes, Perl 6 has a superb unicode library. In other languages, you can add the functionality as libraries. This is an example in Python: import unicodedata def count_graphemes(string): count = 0 for codepoint in string: if not unicodedata.category(codepoint).startswith('M'): count += 1 return count print(count_graphemes("ปฏิบัติจริง")) # prints 7 This example is over simplified as grapheme clusters are trickier to detect, but proper support is coming to Python's standard library: http://bugs.python.org/issue18406 http://bugs.python.org/issue18406