141–150 of 424 posts
(yes, I know they have functional snapshot builds, but as long as there’s not a final "6.0" (or "1.0") release, expect most devs to steer clear of it. Few people (masochists, mostly) want to use an ‘experimental’ programming language for important work).
Earlier quoted context omitted.
1. Carton 2. Function::Parameters, experimental core signatures
Why, after 20 years, are signatures still experimental?
Earlier quoted context omitted.
There's no saving Perl 5; it's a legacy language in legacy maintenance mode for good reason. Renaming Raku/Camelia could help that language quit being saddled with the perception that it's also legacy in the same way, though.
The current state of Perl 5 for Python fans: ---- Perl 5: I'm not dead! TIOBE: 'Ere! 'E says 'e's not dead! Internet: Yes he is. Perl 5: I'm not! TIOBE: 'E isn't? Internet: Well... he will be soon-- he's very ill... Perl 5: I'm getting better! Internet: No you're not, you'll be stone dead in a moment. TIOBE: I can't take 'im off like that! It's against regulations! Perl 5: I don't want to go off the chart.... Interne…
A better metric is the activity on stackoverflow and github, which is what RedMonk use. That's much more stable. Java and C have both been #2 and #9 since 2015. https://redmonk.com/rstephens/files/2019/03/toptwenty-2019-0...
Earlier quoted context omitted.
I don't think you should place too much emphasis/concern/whatever on most of the special variables available in Perl 5. I would wager that most Perl programmers never use about 95% of them (that is, the short 2-3 character ones listed on that man page). At the very least, I would guess, most Perl programmers almost never use 95% of them -- and many would choose (as the perlvar man page says) to 'use English;' -- and…
Yet you have to know both versions of them all, and be able to recognize and understand both kinds when reading other people's code. How does it improve the language to be so top-heavy and chock-full of obscure unreadable arbitrary syntax, 95% of which nobody every uses, but that everyone still needs to memorize and understand in order to read? That's exactly why Perl's philosophy of TMTOWTDI is intellectually bankru…
As an outsider who hasn't written perl code in more than a decade this all makes a lot of sense to me. I think of Perl 5 as something "outdated" because I know that there is a language called Perl 6. When I think of Perl 6 I am not particularly interested in it because I assume it's more or less the same as the "old" Perl, which I don't use and didn't really like back in the day. Renaming Perl 6 to something else wou…
If Perl 6 is renamed, Perl 5 could skip to Perl 7 in the next version to avoid confusion.
When I see that we still don't have a simple "is item 'in' set" operator, 12 (?) years after the introduction of smartmatch and 5 or 6 years after its half-retraction...
(Well, we still have no sets either :-), let's talk about lists/arrays...)
When I see we still don't have a clean function parameters declaration system (better than the mess with prototypes and signatures)...
When I see that constants, enums, simple structured data (C-like-ish structs) still have to be simulated with functions and/or objects and the weight which comes together...
...On one hand, it gives a set of features that could be used to justify a jump. On the other hand, if these basic features has never been deemed useful by the language leaders until now (that is, during a couple of decades), I have little hope they will change their minds.
Earlier quoted context omitted.
I doubt it. "Raku is an interesting new language with some neat features..." will be met with "Oh, you mean Perl 6? lol." If Perl is dead, renaming the last version isn't going to change anything.
Perl isn't dead. It's a perfectly good, stable language with excellent library support. It's just not sexy and new, so there's no buzz about it. Perl6, on the other hand, is effectively another language altogether, and I hope they rename it completely to stop the confusion.
I'm sorry but Perl 6 isnt relevant IMO. It took too long. I was a Perl developer at etoys.com in 2000 and BBC in 2001. I wrote OneMusic for Radio1 and even convinced the BBCs uptight ops team to run it with modperl so it could handle the high traffic it did. I also created the job search engine WorkZoo in modperl, one of Time Magazines top 50 sites of 2005 and Indeed's main competitor at the time. Perl6 was promised.…
To be honest, I'm not sure anything can change the decline of Perl. There will continue to be Perl projects and Perl shops for a long time, just as there are COBOL projects, and COBOL shops. There will even be some new projects. But many projects will die, some companies will go out of business or migrate, and the ecosystem will continue to ossify.
Earlier quoted context omitted.
I don't think you should place too much emphasis/concern/whatever on most of the special variables available in Perl 5. I would wager that most Perl programmers never use about 95% of them (that is, the short 2-3 character ones listed on that man page). At the very least, I would guess, most Perl programmers almost never use 95% of them -- and many would choose (as the perlvar man page says) to 'use English;' -- and…
Yet you have to know both versions of them all, and be able to recognize and understand both kinds when reading other people's code. How does it improve the language to be so top-heavy and chock-full of obscure unreadable arbitrary syntax, 95% of which nobody every uses, but that everyone still needs to memorize and understand in order to read? That's exactly why Perl's philosophy of TMTOWTDI is intellectually bankru…
You have to be able to understand that if it's a two character variable of all punctuation you may need to look it up to figure out what it is. Typing `!perldoc $"` into duck duck go sent me to https://perldoc.pl/variables/$%22 ... which is roughly equivalent to `!g [docker error]` which I already do all day long.
Earlier quoted context omitted.
I mentioned it in another comment, but a really obvious one is that functions in Perl don't have parameters. Every function just takes in a list, and can do whatever it wants with that list. This page gives a good overview of the situation: https://perl101.org/subroutines.html There's a kind of elegant flexibility to that, but it also makes it really hard to program reliably in the large, to build useful tooling, or…
> functions in Perl don't have parameters Sorry, you are misinformed. That hasn't been true for a long time, see http://p3rl.org/Kavorka::Manual::Signatures Other languages would kill for this kind of beyond-complete maximum overkill feature set. > This page gives a good overview of the situation: https://perl101.org/subroutines.html No, it doesn't. That page is not wrong, but incomplete and teaches the wrong stuff,…
> WARNING: Subroutine signatures are experimental. The feature may be modified or removed in future versions of Perl.
