Amazing. I literally first installed this on my laptop over 10 years ago. (Using Parrot)
Perl 7 is going to be Perl 5.32, mostly
211–220 of 573 posts
Re: Perl 7 is going to be Perl 5.32, mostly
#212Earlier quoted context omitted.
I tend to replace my car when it starts to show signs of future problems, not when I'm up to my eyeballs in repairs. We shouldn't really be treating software differently. The liability for a mission critical system that works but cannot be repaired climbs over time. Just because it works doesn't mean it isn't broken.
That analogy doesn't really work - software doesn't get worn out from interaction with users. If software is working and in use, then it's age doesn't matter. Evolution/flux is not the natural state of all software. I've seen plenty of business/enterprise software which has continued to provide business value for decades without structural or architectural changes.
Lots of security patches and infrastructure are held hostage by breaking changes to APIs. Eventually you have to upgrade, and the longer you have put it off the more painful it will be.
And as we've seen with old video games, there are lots of timing problems that you simply never encounter on the original hardware but are impossible to ignore on recent vintage hardware.
Re: Perl 7 is going to be Perl 5.32, mostly
#213Earlier quoted context omitted.
That doesn't add up because today's most popular languages - JS, Java, Python, PHP and Ruby - were also released in the 90s.
As far as i know Java and PHP became popular later in the 90s / early 2000s. Javascript was browser only until 2010, Ruby only became popular after Rails came out mid-2000s. There is a decade gap there.
> Javascript was browser only until 2010
Depending on how you look at it you are at least a decade too late: we Java folks had the Rhino Javascript engine back in the late 1990ies, and it had an interpreted mode since 1998: https://en.wikipedia.org/wiki/Rhino_(JavaScript_engine)
I think it is even mentioned in the Javascript in a Nutshell book by David Flanagan (I haven't read it since then but I studied that book as I wrote a map rendering system in Javascript back in school in 2005.)
Re: Perl 7 is going to be Perl 5.32, mostly
#214Earlier quoted context omitted.
Sure, it's got lots of historical baggage, but there are more sensible alternatives to $| - like STDOUT->autoflush(1) - it's not like you have to use the obscure versions of every feature.
That certainly doesn't solve the problem of other people showboating their knowledge of obscure Perl sigils by using those ridiculous line-noise abbreviations in code you're trying to use and understand, so you have to look up each bit of obscure punctuation in its particular context in order to understand the code. If hard-to-read-and-remember syntax exists, people WILL use it. And some people will make a POINT to u…
You have to bare in mind Perls roots are as an awk-like language for the command line. In those instances weird line noise syntax was the idiom and as Perl grew it moved away from that but without breaking compatibility by default.
This leads to serious Perl projects relying on the numerous headers (as described in the very article we are discussing) to ensure everyone applies a more modern coding style.
So you can absolutely stop people from using $|
The point of Perl 7 is to have sane defaults.
Re: Perl 7 is going to be Perl 5.32, mostly
#215This is just bad maintenance. Just pick all the stuff people are complaining about and fix it! 1. Improve threads 2. Improve C API support 3. Give local::lib, cpanm by default ... multiple perl versions by default 4. Give direct support for coroutines / async await 5. Mark experimental features as non-experimental (attributes, signatures) 6. Pick an OO system, package system 7. Make switch cool again 8. Get more core…
it's likely a lot easier to do all that in the perl7 branch, so that backwards-incompatible changes can be made if needed.
Re: Perl 7 is going to be Perl 5.32, mostly
#216Earlier quoted context omitted.
I've been writing (Modern) Perl for about 3.5 years and I disagree that Perl necessarily tends to unreadable code. I really don't think that's true at all. To quote myself from a recent discussion: I think some languages do make it easy to write convoluted code, but through judicious use of coding standards (including a helping of common sense [don't be clever where you can at all avoid it, which IME is ~~almost~~ al…
Strongly agreed. It’s much more about the team, the conventions used, the organization of the codebase, and the coding culture of the team, than it is about a specific language.
True, but the cultures that grow up around a specific language tend to encourage certain conventions, standards of organization, and team coding cultures.
Re: Perl 7 is going to be Perl 5.32, mostly
#217Earlier quoted context omitted.
Perl 6 was renamed to Raku in October 2019.
Ah, I am glad the name change happened. I got side tracked before it came to a conclusion. I'm guessing if it didn't happen then, it surely would have to be changed now because of this new version, which looks like far less of a fork in the road. I know some people aren't fans of Perl5, but it's what I learned and I wasn't all that excited to have to toss everything I knew (and my reference books) just because of a n…
Perl 6 has been renamed to Raku (https://raku.org using the #rakulang tag on social media). You can run Perl inside of it if you want to, with the Inline::Perl5 module. Check out the Rakudo Weekly News https://rakudoweekly.blog if you want to stay up-to-date!
Re: Perl 7 is going to be Perl 5.32, mostly
#218tl;dr - Perl 7.0 is going to be v5.32 but with different, saner, more modern defaults. Perl was great 20 years ago for basic scripts. Where is it still used today who hasn't transitioned to Python/etc?
Perl continues to be great for basic scripts. Why change and throw away 20 years of experience? The only thing I've noticed that's lacking is decent protobuf support.
I think what you're looking for is this: https://metacpan.org/pod/Google::ProtocolBuffers::Dynamic
Re: Perl 7 is going to be Perl 5.32, mostly
#219Earlier quoted context omitted.
huh. I spent a couple years writing perl professionally, I guess that was around 2006, and I couldn't agree less. Its object system is so bizarre compared to any other language - it's like it doesn't really have an object system, it has parts of a system that you can try to assemble, but no matter what you do you end up with something weird. And on top of that, the sigils, refs, and `wantarray` systems means that fig…
The Moose library is a pretty advanced OO library that was inspired by Common Lisp's CLOS & Smalltalk I think. Most Perl developers I know use a large amount of libraries as the language itself is lacking in many areas. A lot of people are fine with that, but I prefer kitchen-sink languages which are fairly opinionated.
I'm sorry, Moose is a pig. Its startup time is atrocious. Its run time overhead is non-trivial. People who use Moose in my experience just showboat that they can do OO. Does it help? Maybe. But what it surely does is it makes a program run and startup significantly slower.
Re: Perl 7 is going to be Perl 5.32, mostly
#220Earlier quoted context omitted.
Because perl improved over time, but they didn't want to break people's existing code needlessly. No-one ever deliberately invents 'senseless' things, we just discover better ways over time. Sure, if we could somehow magically always invent the best way first of all, that would be great. But we can't, so we make the best of what we have, and improve when we can. But there's no need to punish the existing users of old…
The concept of giving functions names spelled out with letters that form words that describe their meaning was invented a long time before Perl figured out that doing that was better than overloading a limited set of ASCII punctuation with random abstract unrelated concepts.
...and how many of them were designed to be sprinkled liberally in the command line?
Python has a REPL but you couldn’t dump a Python one liner in your Bash pipeline.
Maybe a LISP might qualify but then you’re back to a language family that is unreadable to many and unknown to most (and I say this as someone who loves LISP)
When talking about the original design of Perl you can’t put it in the same category as Python, Pascal and the C-family of languages. Perl was born from an entirely different problem to solve and that’s why some of it’s historic features seem so alien to people outside of the Perl community.