Live data from Hacker News

Is Perl 6 Being Renamed?

blogs.perl.org

261–270 of 424 posts

Re: Is Perl 6 Being Renamed?

#261
post #127

Earlier quoted context omitted.

Yeah too bad it's slow. I write Perl 5 code at work on a daily basis and really wanted to like Perl6. Too late, too slow.

Lizormato and some other folks have put in hundreds of performance fixes...I think these things just take time. The language might have been in development and design since the 90's, but it only just got to 1.0 or a "stable release" in 2017 I think. I'm surprised Larry Wall hasn't written a Perl6 book yet. Plenty of other authors have, but I was really looking forward to something from him or Damien Conway.

I've installed just about every release since 2017. It's a nice language but still slow and lacking library support. The best thing about it is probably the rational math.

Re: Is Perl 6 Being Renamed?

#262
post #199

Raku, Camelia and Rakudo are stupid names. Perl++ is a good name. C and C++ are different enough and live alongside each other.

but this brings up C++, if in name only, which wouldn't always win you fans..

The cool part about old 90s Perl5 was ... it was doing its own thing. The best part about everyone hating you ... gives you the freedom to do precisely that.

I don't like the proposed names because they seem to imply a new language. You need Perl in the goddamn name.

I honestly think the biggest mistake that Perl5 made was going the OOP garbage way, which complicated the language as it was implemented as a hack. And everyone just said ... look Perl, ha ha ... can't do OOP!

OOP in all its forms is a mistake. Small talk OOP, CLOS, Java OOP .... sheesh it's just a hash with sub refs. C gives you function pointers and structs. OOP should have been limited to just fucking that.

Encapsulation is a mistake. Inheritance is a mistake. Polymorphism is useless in a dynamic language.

Re: Is Perl 6 Being Renamed?

#264
post #74

Earlier quoted context omitted.

I believe Perl 5's decline and Perl 6's failure to catch on is evidence of the failure of their common underlying TMTOWTDI philosophy, which encourages write-only "creative snowflake" Perl code that's an inscrutable, unreadable, unmaintainable nightmare. (The sigil-heavy line-noise syntax sure doesn't help, either.) https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to... http://wiki.c2.com/?ThereIsMoreThanOne…

So I basically agree with you & jschwartzi. But to expand or reinforce my original point, it is very clear there is a substantial contingent of programmers who do not. While of course in my own opinion, my own opinion is correct (duh), at a more global level, or maybe in a more academic sense, I'm open to the possibility that I'm wrong. I've already flopped on that matter once in my career and I reserve the right to…

You don't have to be "wrong". You just have to be not exactly the same as everybody else. And of course, nobody is exactly the same as everybody else, therefore there is not possible for there to be such a thing as The One Perfect Language. The right tool for the job; but also the right tool for the workman.

Re: Is Perl 6 Being Renamed?

#265
post #35

Earlier quoted context omitted.

What good reason is that?

I still use Perl 5 for some tasks, but my rule-of-thumb is that if I anticipate wanting to use references, I will go elsewhere.

> but my rule-of-thumb is that if I anticipate wanting to use references, I will go elsewhere

Why? References are not scary and they work just like in any other language -- they are simply a memory address that points to another value stored somewhere else.

Re: Is Perl 6 Being Renamed?

#266

I think it was CPAN that killed Perl, at least that was a major nail in the coffin for me. I have no idea what the CPAN of today is like, but back in the mid-late 90's it was horribly unreliable. There were dozens, if not hundreds of modules that did the same thing, and a lot of them had major bugs. But installing one was the big issue, as it would always choose the latest release of any module in the dependency chai…

> But installing one was the big issue, as it would always choose the latest release of any module in the dependency chain, including the perl interpreter itself. You are mistaken. No cpan client is capable of upgrading perl itself. If a cpan module declares a dependency on a perl version later than what you are currently running, the installation simply fails (as what would happen if there is a dependency declaratio…

Maybe that's how it is today, but every time I installed a module in would invariably end with CPAN downloading the source of the latest build, compile it, and install it. Then I'd have to go and re-install every module under the new version.

Re: Is Perl 6 Being Renamed?

#267

I think it was CPAN that killed Perl, at least that was a major nail in the coffin for me. I have no idea what the CPAN of today is like, but back in the mid-late 90's it was horribly unreliable. There were dozens, if not hundreds of modules that did the same thing, and a lot of them had major bugs. But installing one was the big issue, as it would always choose the latest release of any module in the dependency chai…

> But installing one was the big issue, as it would always choose the latest release of any module in the dependency chain, including the perl interpreter itself. You are mistaken. No cpan client is capable of upgrading perl itself. If a cpan module declares a dependency on a perl version later than what you are currently running, the installation simply fails (as what would happen if there is a dependency declaratio…

Well, not strictly mistaken, but severely outdated. The CPAN module did try to upgrade Perl in ancient versions, and this of course was a terrible idea.

Re: Is Perl 6 Being Renamed?

#268

Earlier quoted context omitted.

SBCL is not Common Lisp. ChickenScheme is not Scheme, nor is guile Scheme. GCC is not C. V8 is not JavaScript. Neither is SpiderMonkey. clang is also not C. tcc is not C. Visual C++ is not C or C++. Delphi is not Object Pascal. Pypy is not Python, nor is Jython, nor is Stackless Python, nor is IronPython. JRuby is not Ruby. yasm and fasm are not x86 assembly or x86_64 assembly or ARM assembly. I'm seeing a pattern of…

Here's the difference. If I said "what's an implementation of Common lisp?" You'd say SBCL. If I Said "What's an implementation of C" you'd say GCC. If I said "What's an implementation of Javascript?" You'd say V8, Spidermonkey, etc. When I ask "What's an implementation of Perl6" The answer is "Nothing implements perl 6, isn't that wonderful!" It used to take forever diving around to find something that could run som…

> When I ask "What's an implementation of Perl6" The answer is

Rakudo (compiler) and Rakudo Star (full distribution). Both of which have been production-ready since shortly after the Perl 6.c spec release in December 2015.

Your rant would be understandable back before there was a stable spec, especially long before when the in-process language description and the various implementations were sometimes far apart. But it's been years since it had even a remote resemblance to reality.

Re: Is Perl 6 Being Renamed?

#269

Earlier quoted context omitted.

> but also that it had some limitations that have only become more glaring over the years. I don't have any real experience with Perl, so could you maybe expand a little? I'm curious about what you think the limitations are.

My experience is that Perl scripts other people wrote are impossible to understand. It made me never want to touch it again. I was handed several unmaintained ten year old Perl scripts to update and in every case I just rewrote it in python just because Perl gave me a migraine looking at it.

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 into larger scripts without refactoring. Regex can triple that problem (thankfully Perl 6 allows you to write some of the most intelligible — seriously! — regex out there).

Re: Is Perl 6 Being Renamed?

#270
post #244

Earlier quoted context omitted.

This is a good list. The default user experience for Perl 6 needs to be dramatically improved. Developer ergonomics matter! Yes, when you run 'python' you get cpython, and Java is probably hotspot vm or openjdk or something (but Java is not a good example of developer ergonomics). Rust is one of the best examples here -- adoption is being driven by the ease-of-use of the entire toolchain, including the package manage…

perl6 has a REPL just like python if you just type perl6. There is a package manager called zef. It has some of the best and most human-readable compiler errors I have ever seen in a compiler. It has one of the simplest FFI to C I have seen to interface with the rest of the world. If there is anything perl6 got wrong, it wasn't ergonomics.

Yes, perl6 does a lot of things right. It's a great language and ecosystem that deserves more adoption.

But all the things the parent comment listed, particularly branding, are in my mind part of developer ergonomics. And there is room for improvement. They wouldn't be talking about renaming the language if this wasn't the case.

Post reply on HN