5 ms·

I don't get all this "Perl 6 is a different language" nonsense. It was created by Larry Wall and retains all the characteristics of Perl 5 whilst adding a lot o

by cutler 7y ago

I don't get all this "Perl 6 is a different language" nonsense. It was created by Larry Wall and retains all the characteristics of Perl 5 whilst adding a lot of great stuff from other languages. Sadly, performance prevents it being taken seriously in production.

jhanschoo 7y ago
FWIW, C++ is a different language from C, and C code is more C++ compatible than Perl 5 is for Perl 6.
- markbnj 7y ago
  > FWIW, C++ is a different language from C It's been 20 years so my information could be very much out of date, but at that time anyway I would not have said this statement was true. C++ then was a superset of C, and any C++ compiler was capable of compiling ANSI C.
  - sbmassey 7y ago
    Even back then, C++ introduced new keywords, so valid C code like int new; would not compile in C++.
    - markbnj 7y ago
      That's true, as a superset it reserved words that had not been reserved before... still think it's a stretch to call it a different language though.
  - earenndil 7y ago
    Your information is very much out of date. C++ makes a few important changes that make most c code incompatible. #1, implicit cast between void and non-void pointers is not allowed, so something like: int *x = malloc(sizeof(int) * 15) is legal c, but in c++ you would have to cast the malloc call. Also, type of character literals is int in c but char in c++. String literals are const only in c++. Functions that take no arguments must be declared as taking void (as in void func(void)) in c, but simply () in c++.
zzzcpan 7y ago
> performance prevents it being taken seriously in production. Performance is a big one. Not focusing on performance is like a strategic mistake for a programming language these days.
- windsurfer 7y ago
  Ruby seems to be doing ok.
  - chessturk 7y ago
    I agree, somehow we're not all writing everything in Rust yet. Maybe it's coming, but I doubt it.
- patrickas 7y ago
  That is exactly what the main architect of the compiler has been working on for the past couple of years. Performance has been enhanced by a few factors since it was released in 2015. For a lots of things the next stable release (as soon as the latest round of optimization have been merged) will be on par with perl5 / ruby / python ... The main slow thing remaining is Grammars which if I understand correctly are not available in those other languages to compare speed, but that is next on the road map for optimization. Here is a recent talk about the state of perl6 performance: https://www.youtube.com/watch?v=QNeu0wK92NE https://www.youtube.com/watch?v=QNeu0wK92NE
  - zzzcpan 7y ago
    Well, no, these are all slow interpreted languages. There is no reason to invest any time into another one just as slow in 2019.
    - Ultimatt 7y ago
      Wat? Consider Perl was created in 1987 when compute resources were things like the Apple II with a Motorola 68020 at 16 MHz with 4MB of RAM. Exactly what do you imagine was the reaction back then? Something being "interpreted" (which Perl 6 is not any more than C# or Java or JavaScript) simply doesn't matter given modern computers, and things like JIT at runtime are hugely valuable even in languages like C. Some interpretation is better than upfront compilation.
mkozlows 7y ago
Perl 6 is more different from Perl 5 than Java 11 is from Java 1, or ES2019 is from OG Javascript. It is genuinely a different language, and pretending that it's the same language has been a huge problem for both of these languages to an even larger extent than this article recognizes.
muraiki 7y ago
The article says: > Perl 6 performance has now gotten to the point where it's often comparable to Perl 5 or surpasses it. It still needs some work in this area, but the work is clear, the goals are straightforward, and Perl 6 is going to easily oustrip Perl 5 in terms of performance. If the Perl 6 community wants to rename, it's perhaps the perfect time to do so. It doesn't look like a bad choice if performance is a primary concern. Shrug.
pjc50 7y ago
It's a different language because you can't run Perl5 programs unmodified in Perl6. The same is also true of Python2/Python3, which is why that transition has also taken so long. The difference is they managed to do it without everyone abandoning Python2 for something else.
- viraptor 7y ago
  Apart from specific cases, which all have workarounds, you can run the same source in python 2 and 3. Many projects still do and handle the edge cases with libraries like "six". Even that transition/difference is much smaller than the perl5/6 issue.
- empath75 7y ago
  It’s pretty easy to upgrade most code from python 2 to 3 and a lot of code just runs as is. The reason the upgrade path was so slow, imo, is that even a reasonably small amount of work is still work, and for a lot of people, the benefits didn’t justify spending any time at all rewriting software that already worked.
  - chucksmash 7y ago
    After the initial round of "useful PyPI packages don't support Python 3 though, I can't migrate", that "I know 3.x is different and I'll have to read up on the differences....later" was absolutely the biggest blocker for adoption imo. I know proficient Python programmers who were starting projects from scratch in 2017 and didn't want to use Python 3.x because they were in a hurry, worried that they didn't know how to write Python 3.x in a timely manner because they hadn't invested the time to learn it. Lots and lots of people just knew it was a known unknown for them, had no idea of the magnitude of the effort required to switch (tiny for new projects! tiiiny) and just put "look into this" somewhere deep on their backlog.
- Grinnz 7y ago
  The other difference is that they did not split into a python 2 and python 3 dev team over the period of two decades which then both decided to keep officially developing their respective languages.
dragonwriter 7y ago
> It was created by Larry Wall and retains all the characteristics of Perl 5 whilst adding a lot of great stuff Except, you know, rampant incompatible syntax. Being invented by the same person and having an overlap of desirable features doesn't make it the same language, in the same way that C# is not Delphi.
Ultimatt 7y ago
Not entirely convinced performance stops it being taken seriously, it just prevents some use cases. Unless you've tried a really recent version of Rakudo and found it monstrously slow at something? If you have, report it!

by cutler 7y ago

jhanschoo 7y ago

FWIW, C++ is a different language from C, and C code is more C++ compatible than Perl 5 is for Perl 6.

markbnj 7y ago
> FWIW, C++ is a different language from C It's been 20 years so my information could be very much out of date, but at that time anyway I would not have said this statement was true. C++ then was a superset of C, and any C++ compiler was capable of compiling ANSI C.
- sbmassey 7y ago
  Even back then, C++ introduced new keywords, so valid C code like int new; would not compile in C++.
  - markbnj 7y ago
    That's true, as a superset it reserved words that had not been reserved before... still think it's a stretch to call it a different language though.
- earenndil 7y ago
  Your information is very much out of date. C++ makes a few important changes that make most c code incompatible. #1, implicit cast between void and non-void pointers is not allowed, so something like: int *x = malloc(sizeof(int) * 15) is legal c, but in c++ you would have to cast the malloc call. Also, type of character literals is int in c but char in c++. String literals are const only in c++. Functions that take no arguments must be declared as taking void (as in void func(void)) in c, but simply () in c++.

zzzcpan 7y ago

> performance prevents it being taken seriously in production. Performance is a big one. Not focusing on performance is like a strategic mistake for a programming language these days.

windsurfer 7y ago
Ruby seems to be doing ok.
- chessturk 7y ago
  I agree, somehow we're not all writing everything in Rust yet. Maybe it's coming, but I doubt it.
patrickas 7y ago
That is exactly what the main architect of the compiler has been working on for the past couple of years. Performance has been enhanced by a few factors since it was released in 2015. For a lots of things the next stable release (as soon as the latest round of optimization have been merged) will be on par with perl5 / ruby / python ... The main slow thing remaining is Grammars which if I understand correctly are not available in those other languages to compare speed, but that is next on the road map for optimization. Here is a recent talk about the state of perl6 performance: https://www.youtube.com/watch?v=QNeu0wK92NE https://www.youtube.com/watch?v=QNeu0wK92NE
- zzzcpan 7y ago
  Well, no, these are all slow interpreted languages. There is no reason to invest any time into another one just as slow in 2019.
  - Ultimatt 7y ago
    Wat? Consider Perl was created in 1987 when compute resources were things like the Apple II with a Motorola 68020 at 16 MHz with 4MB of RAM. Exactly what do you imagine was the reaction back then? Something being "interpreted" (which Perl 6 is not any more than C# or Java or JavaScript) simply doesn't matter given modern computers, and things like JIT at runtime are hugely valuable even in languages like C. Some interpretation is better than upfront compilation.

mkozlows 7y ago

Perl 6 is more different from Perl 5 than Java 11 is from Java 1, or ES2019 is from OG Javascript. It is genuinely a different language, and pretending that it's the same language has been a huge problem for both of these languages to an even larger extent than this article recognizes.

muraiki 7y ago

The article says: > Perl 6 performance has now gotten to the point where it's often comparable to Perl 5 or surpasses it. It still needs some work in this area, but the work is clear, the goals are straightforward, and Perl 6 is going to easily oustrip Perl 5 in terms of performance. If the Perl 6 community wants to rename, it's perhaps the perfect time to do so. It doesn't look like a bad choice if performance is a primary concern. Shrug.

pjc50 7y ago

It's a different language because you can't run Perl5 programs unmodified in Perl6. The same is also true of Python2/Python3, which is why that transition has also taken so long. The difference is they managed to do it without everyone abandoning Python2 for something else.

viraptor 7y ago
Apart from specific cases, which all have workarounds, you can run the same source in python 2 and 3. Many projects still do and handle the edge cases with libraries like "six". Even that transition/difference is much smaller than the perl5/6 issue.
empath75 7y ago
It’s pretty easy to upgrade most code from python 2 to 3 and a lot of code just runs as is. The reason the upgrade path was so slow, imo, is that even a reasonably small amount of work is still work, and for a lot of people, the benefits didn’t justify spending any time at all rewriting software that already worked.
- chucksmash 7y ago
  After the initial round of "useful PyPI packages don't support Python 3 though, I can't migrate", that "I know 3.x is different and I'll have to read up on the differences....later" was absolutely the biggest blocker for adoption imo. I know proficient Python programmers who were starting projects from scratch in 2017 and didn't want to use Python 3.x because they were in a hurry, worried that they didn't know how to write Python 3.x in a timely manner because they hadn't invested the time to learn it. Lots and lots of people just knew it was a known unknown for them, had no idea of the magnitude of the effort required to switch (tiny for new projects! tiiiny) and just put "look into this" somewhere deep on their backlog.
Grinnz 7y ago
The other difference is that they did not split into a python 2 and python 3 dev team over the period of two decades which then both decided to keep officially developing their respective languages.

dragonwriter 7y ago

> It was created by Larry Wall and retains all the characteristics of Perl 5 whilst adding a lot of great stuff Except, you know, rampant incompatible syntax. Being invented by the same person and having an overlap of desirable features doesn't make it the same language, in the same way that C# is not Delphi.

Ultimatt 7y ago

Not entirely convinced performance stops it being taken seriously, it just prevents some use cases. Unless you've tried a really recent version of Rakudo and found it monstrously slow at something? If you have, report it!