Live data from Hacker News

Is Perl 6 Being Renamed?

blogs.perl.org

411–420 of 424 posts

Re: Is Perl 6 Being Renamed?

#411
post #372

To my mind, the blockers for Perl 6 adoption in order of importance have been: 1. The name, saddling it with the legacy of Perl. (I say this as someone who really liked working with Perl back in the waning years of the old millennium, and believes that Perl was visionary in pointing the way to the state of modern programming... but also that it had some limitations that have only become more glaring over the years.)…

I started my first programming job using Perl in 2003. There was talk about Perl 6 being ready soon. It sounded really cool like many people I was quite excited about it. Sadly the screwing around and refusing to give a real release date really messed things up ("It will be ready by Christmas, we just aren't saying which year"). I moved on to Python - which has been a good move career wise, but its a shame as I enjoy…

Let me clear that up for you, if you are still in doubt.

Perl5 had a period of slow releases in the 2000s, this changed in 2010 with the release of version 5.12. Since then, Perl 5 has been on a yearly release cycle. The current release is version 5.30.0. When it became clear Perl6 wasn't coming any time soon, some people left Perl. Others knuckled down and wrote some great code that made Perl5 into a much better language. With many core feature additions and deprecations, new CPAN modules, and tooling to support consistent work by teams, the Perl5 language is more expressive and better than ever.

Perl6 took forever, had major internal conflicts, but managed to survive and ship a specification in December 2015, version 6.c (6.a was an alpha version, and 6.b a beta). The Rakudo Perl6 compiler gets monthly releases, but most people install the Rakudo Star distribution, which bundles some extra modules and just makes life a bit easier. Rakudo Star began shipping "A usable Perl 6 compiler" in 2010. Regular releases tracked changes in the compiler.

The Perl6.c spec was announced in December 2015, and the first Rakudo to implement it was released at the same time. Rakudo Star, lagged a bit and released in January 2016.

Here's the Perl6 release announcement: https://perl6advent.wordpress.com/2015/12/25/christmas-is-he...

The Perl 6.d spec was released in November 2018, and the Rakudo 2018.11 version defaults to supporting it.

Here's a link the Perl6 FAQ with more info on the Perl6 versioning and releases. https://docs.perl6.org/language/faq

If you liked Perl5 then, come back and give modern perl5 a try.

Perl6 is an amazingly expressive and fun language to write with.

Re: Is Perl 6 Being Renamed?

#412
post #327

Earlier quoted context omitted.

That's a problem with the people who wrote the script, though, not the language itself. Consider the difference between a minified JS script or one produced with emscripten and the code pre-minification. One is unintelligible guaranteed, the other … maybe haha. Unfortunately, what tended to happen is people would write one liners, and slowly expand the one liners into more complex one liners, and then integrate them…

That's a problem with the people who wrote the script, though, not the language itself. That's like the folks who say "the problem with C (buffer overflow, UB, etc.) isn't C, it's the people who write C". Which leads to at some point contemplative folks deciding either "this is happening so often, maybe it is the language" or "the majority of people writing this language are incompetent". While I've heard plenty of p…

90% of Perl's line noise comes from using short cute variable names and trying to cram way too much into way too compressed regexes.

There's nothing inherent about Perl that causes people to use $z instead of $somethingDescriptive. And regexes have for quite some time allowed for insignificant whitespace to comment things in detail.

If you comment your regexes and use decent variable names, you solve 98% of the readability problems of Perl, and both of those could be enforced with a linter. But as I said, a lot of the problems come from one liners being slowly expanded. Using single letter var names for anything is fine in a one liner, but not good for long term program legibility or maintance in any language.

Re: Is Perl 6 Being Renamed?

#413

Earlier quoted context omitted.

# copy stdin to stdout, except for lines starting with # while left_angle_right_angle: if dollar_underscore[0] =eq= "#": continue_next; } print dollar_underscore; } Hilarious...

The opening block with `:` and ending block with `}` literally killed me.

If Roger Zelazny weren’t literally dead, he’d literally be rolling over in his grave for your use of the word literally.

Re: Is Perl 6 Being Renamed?

#414
post #381

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

> Perl6 has been under development for over a decade at this point, and this equivocating statement is the best that can be said about performance? If the "work is clear, the goals are straightforward" and Perl 6 should easily outstrip Perl 5 on performance, then by gosh they should demonstrate that. As the other of the post in question, I refer you to this presentation: https://www.youtube.com/watch?v=QNeu0wK92NE It…

"author of the post in question"

God, what a horrible typo :)

Re: Is Perl 6 Being Renamed?

#415
post #398

Earlier quoted context omitted.

> it seems like you think everyone who disagrees with you is stupid. This isn't an explanation for anything. It is the simpliest explanation. In fact it was stupid and arrogant leadership mostly. There was no disagreement, as we didn't say a beep then. They made those stupid decisions all by themselves, and didn't listen to any advice. The better people just silently left, shaking their heads.

It is the simpliest explanation. It's the laziest explanation. Did you ever ask yourself why , for example, all of the calling convention code paths were consolidated into a single code path? It wasn't to make a single, inefficient code path as you claim. It was to provide a gradual transition for clients to a better designed calling convention system which could then be optimized for actual client uses. The goal was…

Explanation for others: They made it 10x slower, so that perl6 decided to ditch them. It worked, but that's about all. Nobody can use it.

Re: Is Perl 6 Being Renamed?

#416
post #415

Earlier quoted context omitted.

It is the simpliest explanation. It's the laziest explanation. Did you ever ask yourself why , for example, all of the calling convention code paths were consolidated into a single code path? It wasn't to make a single, inefficient code path as you claim. It was to provide a gradual transition for clients to a better designed calling convention system which could then be optimized for actual client uses. The goal was…

Explanation for others: They made it 10x slower, so that perl6 decided to ditch them. It worked, but that's about all. Nobody can use it.

Always interesting to read the final sum-total précis of what political people accomplish when they burst into a technical china shop with good intentions and not a clue. An unbelievably slow VM is an inevitable result, no matter the field. You could be doing laboratory science when a politician explodes through the door, and a year later, somehow end up with a scripting language that runs in a VM implemented in Perl...

Re: Is Perl 6 Being Renamed?

#417
post #415

Earlier quoted context omitted.

It is the simpliest explanation. It's the laziest explanation. Did you ever ask yourself why , for example, all of the calling convention code paths were consolidated into a single code path? It wasn't to make a single, inefficient code path as you claim. It was to provide a gradual transition for clients to a better designed calling convention system which could then be optimized for actual client uses. The goal was…

Explanation for others: They made it 10x slower, so that perl6 decided to ditch them. It worked, but that's about all. Nobody can use it.

Explanation for others

How odd then that ~90% of the discussions about ditching Parrot were primarily complaining about the deprecation policy and first-class Rakudo support, not speed.

I suppose you would know better though, being objectively smarter than everyone else who ever made a decision about the project. How unfortunate that we can't take your word for it; we can only read all of the public discussion about it.

Re: Is Perl 6 Being Renamed?

#418
post #366

Earlier quoted context omitted.

I did some tests for prime number crunching. For example the C-style loop statement is faster than Perl's own foreach. Perl6 was the slowest of them all while the fastest was LuaJIT. The whole code is two loops with a bunch of multiplications and additions, an array push, loading a hash and looking up values in it. https://news.ycombinator.com/item?id=16720027

This seems like a very odd standard to use? I understand that you wanted to compare performances of different languages, that's great. But if you actually wanted to get the job done idiomatically, the code is one short, simple line of Perl 6. The performance, while admittedly slower, is within the same order of magnitude as your Perl 5 version. To me, this is the magic of Perl 6. Sure, if you want to use 16 lines of…

It's just stuff that I use daily in normal code, so this benchmark pretty much serves the pupose very well: it uses mundane operations, also uses memory, one can adjust it by raising the bar 10x times, so the actual algorithm takes several orders of magnitude longer than the JIT penalty. In fact most of the interpreted languages would pretty much crunch for minutes at 10⁴, while Go, Crystal, D and Rust would take seconds or tens of seconds. Perl6 is basically stuck there forever and at the other end of the spectrum are Node and Dart. LuaJIT would run out of memory at that figure, otherwise it's among the fastest.

Re: Is Perl 6 Being Renamed?

#419
post #372

Earlier quoted context omitted.

I started my first programming job using Perl in 2003. There was talk about Perl 6 being ready soon. It sounded really cool like many people I was quite excited about it. Sadly the screwing around and refusing to give a real release date really messed things up ("It will be ready by Christmas, we just aren't saying which year"). I moved on to Python - which has been a good move career wise, but its a shame as I enjoy…

Let me clear that up for you, if you are still in doubt. Perl5 had a period of slow releases in the 2000s, this changed in 2010 with the release of version 5.12. Since then, Perl 5 has been on a yearly release cycle. The current release is version 5.30.0. When it became clear Perl6 wasn't coming any time soon, some people left Perl. Others knuckled down and wrote some great code that made Perl5 into a much better lan…

Perl 5 post 5.12 is nice but people like rurban an mlehmann claim p5p are screwing it up and breaking backwords compatibility for no good reason. These two individuals are quite knowledgeable programmers, so I'm inclined to agree with them. Both have created their own fork of Perl 5.

Perl 6 is quite nice as a language but the implementation is slow and it has too litlle lib support. Also not great for scripting because of the VM penalty.

Re: Is Perl 6 Being Renamed?

#420

Earlier quoted context omitted.

I would move 4 up to 2. Every time I read an article about how cool Perl 6, I see the clever bits of syntax and think "WTF? I might enjoy playing with that for fun, but no way in hell would I use that for work."

The language geek part of me loves Perl. The business part of me would never let it be used for production code. Too much business risk to tolerate.

Would you let JavaScript be used in production code? Because it is used and it's a mess.
Post reply on HN