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.
Is Perl 6 Being Renamed?
261–270 of 424 posts
Re: Is Perl 6 Being Renamed?
#262Raku, 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..
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?
#263I love open source drama
Re: Is Perl 6 Being Renamed?
#264Earlier 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…
Re: Is Perl 6 Being Renamed?
#265Earlier 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.
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?
#266I 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…
Re: Is Perl 6 Being Renamed?
#267I 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…
Re: Is Perl 6 Being Renamed?
#268Earlier 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…
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?
#269Earlier 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.
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?
#270Earlier 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.
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.