7 ms·

Its been endlessly stated but naming it 'Perl 6' was a huge mistake. Perl 5 has an enduring reputation for crufty, unmaintainable code written by graybeard sysa

by pram 9y ago

Its been endlessly stated but naming it 'Perl 6' was a huge mistake. Perl 5 has an enduring reputation for crufty, unmaintainable code written by graybeard sysadmins. I wrote a lot myself that I wouldn't want to ever deal with again. I think they would have benefitted from a clean break from a marketing perspective, especially considering it's completely different.

thanatropism 9y ago
I know the break from Python 2 to 3 is also a mistake, but I don't know which one. I learned Python 3 because it seemed that it was the new one, but to great confusion Python 2 is alive and default in Linux distributions.
- slaymaker1907 9y ago
  I think Ubuntu switched over to python 3 by default recently.
  - makecheck 9y ago
    If they still call the executable "python" then they’re demonstrating the whole issue with keeping the same name for wildly-incompatible upgrades: it “shouldn’t" matter what version a reasonably-modern OS chooses and yet it does, solely because of the name. No one would complain about having "/usr/bin/python", "/usr/bin/py3k", "/usr/bin/perl" and "/usr/bin/rakudo" all at once on the same OS but being forced to choose two is insane.
    - cat199 9y ago
      So like, the same thing that happened between various perl versions (inc 4x -> 5x) and python? Or C++ versions? or even c-library or executable format changes? Things break sometimes.
- gkya 9y ago
  I don't get all this confusion wrt Python 2 and Python 3, it's not different from GCC supporting different C standards. Just run the correct executable (i.e. python2 or python3) and done. In response to parent comment, Perl 6 is Perl. I don't think that it's difficult to understand that Perl is a family of languages, and Perl 6 is a more recent and sophisticated sibling to Perl 5. All of this is bikeshedding to me.
  - eej71 9y ago
    I think the Python 2->3 and Perl 5->6 _is_ different from GCC supporting different C standards. I think that you are overlooking the fact that the vast majority of python 2 code wouldn't run by default with python 3. Yes, there are now conversion utilities that handle most (all? maybe?) of the scenarios, but the fact remains that both Python 3 and Perl 6 break backwards compatibility. C and C++ have tried very hard to not do this. Your old C code and your old C++ code will almost always compile as is with a newer standard.
    - cygx 9y ago
      Your old C code and your old C++ code will almost always compile as is with a newer standard. Depends on the code: Some of it won't compile without providing just the right set of flags. In case of C, for me the crucial feature is not so much full backwards compatibility, but interoperability (you can link the object code regardless of the language version) and the convenience of using the same frontend executable. In case of Perl, the former is currently possible to some degree via the Perl5 module Inline::Perl6 and the Perl6 module Inline::Perl5. Personally, I would like to see the latter become a reality as well - this is the solution I'd perfer over trying to distance Perl6 from Perl5 via rebranding.
      - raiph 9y ago
        If you browse the #perl6-toolchain logs[1] you'll see folk making steady progress toward practical interop of multiple versions of the P6 language (6.c, 6.d, etc.), P6 compilers (Rakudo 2017.07 etc.), and P6 modules on the one hand and hosting this stuff on CPAN on the other. But perhaps you know about that already. I may be imagining things but, peering years into the future, it seems this versioning management aspect of the P6 toolchain might end up being the foundation of a new multiple lang/compiler/module version juggling Perl package manager that can be used with P5, P6, python etc. Does that make sense to you? [1] https://irclog.perlgeek.de/perl6-toolchain https://irclog.perlgeek.de/perl6-toolchain
zoffix222 9y ago
There's actually talk about amending the name for next major language release ( https://rakudo.party/post/The-Hot-New-Language-Named-Rakudo https://rakudo.party/post/The-Hot-New-Language-Named-Rakudo ). Exactly for the reasons you state: it's a completely different language than Perl and so far it proved too confusing for everyone.
- cygx 9y ago
  For what it's worth, I disagree and was a bit annoyed that you've re-opened that particular Pandora's box again ;)
  - zoffix222 9y ago
    I don't mind annoying people to solve problems.
    - cygx 9y ago
      I think you're trying to solve the wrong problem: Don't move the languages further apart through rebranding, move the implementations closer together through improved interoperability. Have a frontend that can invoke the perl5 interpreter as well as Rakudo as appropriate, supporting the perl5 command line flags, and arguably quite a bit of the problem goes away.
      - panic 9y ago
        Maybe the problem isn't with the "Perl" part of the name, but with the "6" part? It sounds like an incremental update when it's actually a new language.
        labster 9y ago
        Perl X 10.0, like Apple did then?
    - labster 9y ago
      You should mind annoying people to cause problems. Bringing up the language naming thing, again after 10+ years of discussion, has all of the problem solving ability of "hay guise whats going on in this thread?" Branding is not the problem with Perl 6, though it is the easiest thing to bikeshed. The problem is compiler speed, language interoperability, and enough of a toolchain to start building serious apps. Make that good enough, and no one will care what our language is called.
omaranto 9y ago
I think the people behind the Eta programming language would agrwe with you: they implemented Haskell on the JVM, fully compatible with the Haskell standard and including many popular GHC extensions, but don't mention the word Haskell at all on their landing page: http://eta-lang.org/ http://eta-lang.org/
- gbacon 9y ago
  Apples and oranges. Haskell is defined by a language specification, not an implementation.
  - mbrock 9y ago
    Only that most people program in GHC, not Haskell.
    - michaelcampbell 9y ago
      I feel there's a subtlety to your comment that I don't get. Can you explain? (I've not yet learned Haskell.)
      - mrkgnao 9y ago
        There was a 1998 "Haskell Report" which formally defined Haskell-the-language. This version of Haskell is called Haskell 98 (sort of like C++98). There is also an updated version released in 2010, which defines an expanded language called Haskell 2010. https://www.haskell.org/onlinereport/ https://www.haskell.org/onlinereport/ https://www.haskell.org/onlinereport/haskell2010/ https://www.haskell.org/onlinereport/haskell2010/ The purpose of these documents is to specify what an implementation of Haskell 98 or 2010, respectively, should support. Just like the analogous standards published for the C and C++ languages, the Haskell reports make no reference to any specific implementation. The most popular implementation of Haskell is the GHC compiler. (In fact, in reality it's the only compiler anyone uses, with very few exceptions. For better or worse, Haskell is a one-implementation language at present.) GHC accepts a greatly expanded language compared to what the reports specify, including a large number of language extensions that can be turned on with flags. (sort of like how Clang or modern GCC accept C++11/14). There are minor changes from one version to another, so the language accepted by GHC today is often called GHC Haskell for disambiguation. What GP is pointing out is that almost everyone using Haskell today writes in the language that GHC accepts today instead of sticking to some official standard. If you want to learn Haskell, you don't need to worry about this at all. All reference materials and books teach modern GHC Haskell, which is also what is used by practically all Haskell users. As noted before, very few people use non-GHC compilers (usually it's just the people implementing or testing them) and you're very unlikely to encounter these implementations.
jfoutz 9y ago
Perl 5 was my first love as a programming language. I rarely use it now, but it will always have a special place in my heart. I learned so much with that language. Blessing a regex for example. That was the first time I felt like I had a super power.
- smegel 9y ago
  Perl 5 is still a great replacement for sed and awk in one-liners. Which is what it was originally envisaged as (although more than just one-liners), and is probably how it should survive - the most powerful one-line tool in existence.
  - gbacon 9y ago
    [citation needed]
    - smegel 9y ago
      > Apples and oranges. Haskell is defined by a language specification, not an implementation. reply Oh, a Haskell zealot. And to think I was about to start an argument!
      - JadeNB 9y ago
        > > Apples and oranges. Haskell is defined by a language specification, not an implementation. Do you have the wrong thread? You're quoting https://news.ycombinator.com/item?id=15005881 https://news.ycombinator.com/item?id=15005881 , but replying to https://news.ycombinator.com/item?id=15005874 https://news.ycombinator.com/item?id=15005874 (albeit by the same user).
  - goatlover 9y ago
    With all due respect to APL?
    - throwaway7645 9y ago
nerdponx 9y ago
Once I got about halfway into this review, talking about the "whatever star" and all the different ways to declare hashes, it seems like this language is right on track to do the same.

by pram 9y ago

thanatropism 9y ago

I know the break from Python 2 to 3 is also a mistake, but I don't know which one. I learned Python 3 because it seemed that it was the new one, but to great confusion Python 2 is alive and default in Linux distributions.

slaymaker1907 9y ago
I think Ubuntu switched over to python 3 by default recently.
- makecheck 9y ago
  If they still call the executable "python" then they’re demonstrating the whole issue with keeping the same name for wildly-incompatible upgrades: it “shouldn’t" matter what version a reasonably-modern OS chooses and yet it does, solely because of the name. No one would complain about having "/usr/bin/python", "/usr/bin/py3k", "/usr/bin/perl" and "/usr/bin/rakudo" all at once on the same OS but being forced to choose two is insane.
  - cat199 9y ago
    So like, the same thing that happened between various perl versions (inc 4x -> 5x) and python? Or C++ versions? or even c-library or executable format changes? Things break sometimes.
gkya 9y ago
I don't get all this confusion wrt Python 2 and Python 3, it's not different from GCC supporting different C standards. Just run the correct executable (i.e. python2 or python3) and done. In response to parent comment, Perl 6 is Perl. I don't think that it's difficult to understand that Perl is a family of languages, and Perl 6 is a more recent and sophisticated sibling to Perl 5. All of this is bikeshedding to me.
- eej71 9y ago
  I think the Python 2->3 and Perl 5->6 _is_ different from GCC supporting different C standards. I think that you are overlooking the fact that the vast majority of python 2 code wouldn't run by default with python 3. Yes, there are now conversion utilities that handle most (all? maybe?) of the scenarios, but the fact remains that both Python 3 and Perl 6 break backwards compatibility. C and C++ have tried very hard to not do this. Your old C code and your old C++ code will almost always compile as is with a newer standard.
  - cygx 9y ago
    Your old C code and your old C++ code will almost always compile as is with a newer standard. Depends on the code: Some of it won't compile without providing just the right set of flags. In case of C, for me the crucial feature is not so much full backwards compatibility, but interoperability (you can link the object code regardless of the language version) and the convenience of using the same frontend executable. In case of Perl, the former is currently possible to some degree via the Perl5 module Inline::Perl6 and the Perl6 module Inline::Perl5. Personally, I would like to see the latter become a reality as well - this is the solution I'd perfer over trying to distance Perl6 from Perl5 via rebranding.
    - raiph 9y ago
      If you browse the #perl6-toolchain logs[1] you'll see folk making steady progress toward practical interop of multiple versions of the P6 language (6.c, 6.d, etc.), P6 compilers (Rakudo 2017.07 etc.), and P6 modules on the one hand and hosting this stuff on CPAN on the other. But perhaps you know about that already. I may be imagining things but, peering years into the future, it seems this versioning management aspect of the P6 toolchain might end up being the foundation of a new multiple lang/compiler/module version juggling Perl package manager that can be used with P5, P6, python etc. Does that make sense to you? [1] https://irclog.perlgeek.de/perl6-toolchain https://irclog.perlgeek.de/perl6-toolchain

zoffix222 9y ago

There's actually talk about amending the name for next major language release ( https://rakudo.party/post/The-Hot-New-Language-Named-Rakudo https://rakudo.party/post/The-Hot-New-Language-Named-Rakudo ). Exactly for the reasons you state: it's a completely different language than Perl and so far it proved too confusing for everyone.

cygx 9y ago
For what it's worth, I disagree and was a bit annoyed that you've re-opened that particular Pandora's box again ;)
- zoffix222 9y ago
  I don't mind annoying people to solve problems.
  - cygx 9y ago
    I think you're trying to solve the wrong problem: Don't move the languages further apart through rebranding, move the implementations closer together through improved interoperability. Have a frontend that can invoke the perl5 interpreter as well as Rakudo as appropriate, supporting the perl5 command line flags, and arguably quite a bit of the problem goes away.
    - panic 9y ago
      Maybe the problem isn't with the "Perl" part of the name, but with the "6" part? It sounds like an incremental update when it's actually a new language.
      - labster 9y ago
        Perl X 10.0, like Apple did then?
  - labster 9y ago
    You should mind annoying people to cause problems. Bringing up the language naming thing, again after 10+ years of discussion, has all of the problem solving ability of "hay guise whats going on in this thread?" Branding is not the problem with Perl 6, though it is the easiest thing to bikeshed. The problem is compiler speed, language interoperability, and enough of a toolchain to start building serious apps. Make that good enough, and no one will care what our language is called.

omaranto 9y ago

I think the people behind the Eta programming language would agrwe with you: they implemented Haskell on the JVM, fully compatible with the Haskell standard and including many popular GHC extensions, but don't mention the word Haskell at all on their landing page: http://eta-lang.org/ http://eta-lang.org/

gbacon 9y ago
Apples and oranges. Haskell is defined by a language specification, not an implementation.
- mbrock 9y ago
  Only that most people program in GHC, not Haskell.
  - michaelcampbell 9y ago
    I feel there's a subtlety to your comment that I don't get. Can you explain? (I've not yet learned Haskell.)
    - mrkgnao 9y ago
      There was a 1998 "Haskell Report" which formally defined Haskell-the-language. This version of Haskell is called Haskell 98 (sort of like C++98). There is also an updated version released in 2010, which defines an expanded language called Haskell 2010. https://www.haskell.org/onlinereport/ https://www.haskell.org/onlinereport/ https://www.haskell.org/onlinereport/haskell2010/ https://www.haskell.org/onlinereport/haskell2010/ The purpose of these documents is to specify what an implementation of Haskell 98 or 2010, respectively, should support. Just like the analogous standards published for the C and C++ languages, the Haskell reports make no reference to any specific implementation. The most popular implementation of Haskell is the GHC compiler. (In fact, in reality it's the only compiler anyone uses, with very few exceptions. For better or worse, Haskell is a one-implementation language at present.) GHC accepts a greatly expanded language compared to what the reports specify, including a large number of language extensions that can be turned on with flags. (sort of like how Clang or modern GCC accept C++11/14). There are minor changes from one version to another, so the language accepted by GHC today is often called GHC Haskell for disambiguation. What GP is pointing out is that almost everyone using Haskell today writes in the language that GHC accepts today instead of sticking to some official standard. If you want to learn Haskell, you don't need to worry about this at all. All reference materials and books teach modern GHC Haskell, which is also what is used by practically all Haskell users. As noted before, very few people use non-GHC compilers (usually it's just the people implementing or testing them) and you're very unlikely to encounter these implementations.

jfoutz 9y ago

Perl 5 was my first love as a programming language. I rarely use it now, but it will always have a special place in my heart. I learned so much with that language. Blessing a regex for example. That was the first time I felt like I had a super power.

smegel 9y ago
Perl 5 is still a great replacement for sed and awk in one-liners. Which is what it was originally envisaged as (although more than just one-liners), and is probably how it should survive - the most powerful one-line tool in existence.
- gbacon 9y ago
  [citation needed]
  - smegel 9y ago
    > Apples and oranges. Haskell is defined by a language specification, not an implementation. reply Oh, a Haskell zealot. And to think I was about to start an argument!
    - JadeNB 9y ago
      > > Apples and oranges. Haskell is defined by a language specification, not an implementation. Do you have the wrong thread? You're quoting https://news.ycombinator.com/item?id=15005881 https://news.ycombinator.com/item?id=15005881 , but replying to https://news.ycombinator.com/item?id=15005874 https://news.ycombinator.com/item?id=15005874 (albeit by the same user).
- goatlover 9y ago
  With all due respect to APL?
  - throwaway7645 9y ago

nerdponx 9y ago

Once I got about halfway into this review, talking about the "whatever star" and all the different ways to declare hashes, it seems like this language is right on track to do the same.