Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Perl 7 is going to be Perl 5.32, mostly

perl.com

Post reply on HN
Print view View original

521–530 of 573 posts

Re: Perl 7 is going to be Perl 5.32, mostly

#521

Post by latk »

daotoad wrote: post #372
latk wrote: post #314

Earlier quoted context omitted.

Interesting, I've been moving away from Perl and Python and towards Rust precisely because I'm afraid of bitrot. Perl the language is stable as fuck and takes back-compat extremely seriously. The problem for me was the library ecosystem: Cpan makes it tedious to pin/vendor dependencies, and installs dependencies globally by default.

You might want to look at Carton and cpanfiles as a way of managing dependencies. You can also get really ancient stuff off BackPAN, should your dependencies disappear from CPAN proper. https://metacpan.org/pod/Carton#Tracking-the-dependencies http://backpan.perl.org/authors/id/

Yup, Perl7 + Carton looks like a good combo for stable programs that don't have to be distributed publicly. I just wish cpanm and Carton were Core :D

Re: Perl 7 is going to be Perl 5.32, mostly

#522

Post by sergeykish »

viraptor wrote: post #279
cutler wrote: post #257

Earlier quoted context omitted.

Whatever happened to the neophyte raising him/herself up to level of the master? Programming seems to be the only profession in which the beginner is excused learning the language thoroughly and, worse, that he/she expects the language to be dumbed down to make it easier to learn. Can you imagine a budding musician complaining that musical notation should be made "easier for beginners"? If you want to grok Perl learn…

> Can you imagine a budding musician complaining that musical notation should be made "easier for beginners"? You mean like string instrument tab coloured by finger instead of sheet music? Yes, exactly like that.

Language is a tool for programmer.

Restrict scale to pentatonic even for professionals (remove physical keys, holes etc). They would absolutely mess up otherwise.

Re: Perl 7 is going to be Perl 5.32, mostly

#523

Post by lizmat »

p1necone wrote: post #436

I'm trying to work this out but not having much luck - Perl 6 was a "lets make a bunch of breaking changes and modernize Perl a bit", and now that's branched off as a new language called Raku. Now there's Perl 7, which is sort of the same idea as Perl 6 was, but less radical with the changes? Are the same people working on both? Is Larry involved with both?

Larry has not been involved with Perl 5 for the past 20 years, and not in Perl 6 for the past 3 years or so.

Re: Perl 7 is going to be Perl 5.32, mostly

#524

Post by lizmat »

cutler wrote: post #427
daotoad wrote: post #382

Earlier quoted context omitted.

Raku's big strengths lie, IMO, in the command line scripting capabilities (the MAIN function), parsing with grammars and powerful new regex syntax, and as a glue language. It's relatively easy to bind to external libraries and work with them. Look at how easily raku binds to a python charting module in this article: https://www.perl.com/article/plotting-with-perl-6/

But if it's slow at really basic stuff users will ignore it, surely?

Slow is in the eye of the beholder. Sure, for some applications, Perl blows Raku out of the water. Add in some Moose, and the situation is not so different. YMMV.

Re: Perl 7 is going to be Perl 5.32, mostly

#525

Post by lizmat »

jVinc wrote: post #354

I'm sorry if this offends. But a complete laypersons* perspective from someone who hasn't been keeping up on the current perl ecosystem is this: perl6 failed to the degree that perl 5 became perl 7, while all the perl programmers switched to ruby or python. Am I wrong? *ok, not completely layperson, I used perl a lot a decade ago an have spent a week playing with raku at one point, but nothing in my professional life…

Perl 6 / Raku did achieve its goal of a programming language that kept all the good parts of Perl, and remove it warts, making it ready to become the 100 year programming language.

In my opinion, the failure is in the timing of the process, and keeping the Perl community involved in the process.

Re: Perl 7 is going to be Perl 5.32, mostly

#526

Post by lizmat »

greggman3 wrote: post #479
py_or_dy wrote: post #306

I've been a perl zealot since 2005. I didn't even know "python" existed until around 2008 when I found a script file with a ".py" file ending in a fresh ubuntu install. I started going to perl conferences sometime after 2010 when someone on irc informed be about them. I learned so much in those conferences, mainly about the alternatives to cgi and the modern OOP "framework" named "moose". I thought I was in heaven. I…

I have disliked perl since I first started using it because it clear it's a hack with hack upon hack of fixes to try to wallpaper over how bad it is. For example, IIRC it's pretty clear it used to be all variables were global. The solution was a manual command to push a variable onto the stack. That's a horrible solution as it requires perfection everywhere. Another is all the special meaning but global variables lik…

This is one if the reasons that the Perl 6 project started (now known as the Raku Programming Language). Raku only has three of these special (lexical) variables left:

  $_    the topic
  $/    result of the last match
  $!    the last exception caught
An overview: https://docs.raku.org/language/5to6-perlvar

Re: Perl 7 is going to be Perl 5.32, mostly

#527

Post by lizmat »

seesaw wrote: post #470
Vivtek wrote: post #329

Earlier quoted context omitted.

As a 53-year-old Perl developer (my CPAN handle is MICHAEL, I'm that old), I freakin love Vue. I haven't done paid work with Perl since the 90's. Now I'm glad I haven't. I use it for my private work because it does what I want it to do, but on the few occasions I've coded for pay since leaving the industry, I've used Python.

I did object oriented programming in Perl from 96 to 2010. We used Perl to create scalable and maintainable enterprise applications. Perl was a pleasure to code in. It is unfortunate the whole Perl6 effort ended up killing Perl. Although I have moved on to other languages, I still haven’t found an enjoyable language as Perl.

Perhaps then, now is the time to have a look at the Raku Programming Language. It is said to be optimized for fun (as in -Ofun). https://raku.org

Re: Perl 7 is going to be Perl 5.32, mostly

#528

Post by ChiranSoogoor »

gmmeyer wrote: post #71
hinkley wrote: post #35

Earlier quoted context omitted.

Many places don’t support antifragility. Having an old system that nobody wants to rewrite may not be a reflection on the engineers. You’re an expert, and a rewrite is going to expose you to a lot of scrutiny. You are going to break things, when maybe you haven’t broken things in a long time and people like it that way. So when some day arrives where a new fad is hot and it’s hard to impossible to find Perl programme…

There's no need to rewrite a system that works and that you're not gonna change. While programming languages go out of fashion there will always be people who are capable of writing them. The median age of a cobol programmer has not changed in 20 years because more people keep learning the language. Demand in this case, will likely create its own supply.

Wisdom is in not in spending years and millions rewriting billions of lines of cobol code into a new language and then rewriting that other language into another newer language and so on … what's the problem in maintaining what's already working?!!

Re: Perl 7 is going to be Perl 5.32, mostly

#529

Post by HelloNurse »

banana_giraffe wrote: post #2

They last line of the article summarizes it well: > Perl 7 is v5.32 with different settings. Your code should work if it’s not a mess. Expect a user release within a year. Are there actually people that are still deploying new things in Perl? The only times I see it is for legacy stuff, and then only because the script is too much of a hassle to be rewritten.

Last year I had to perform date arithmetic in C shell scripts on a locked down server (no way to install or compile programs and obsolete or missing utilities).

I considered Perl, since it was the only scripting language interpreter, but the good enough (on paper) date handling libraries I found on CPAN turned out to require a far newer Perl 5 version that was available.

I'm afraid that the best-case Perl solution would have been more difficult to write than the roundabout but reliable and easy to understand final solution (Oracle SQL functions executed through the command-line SQL*Plus client).

Re: Perl 7 is going to be Perl 5.32, mostly

#530

Post by singingfish »

cutler wrote: post #480
singingfish wrote: post #473

Earlier quoted context omitted.

rails as far as I understand is opinionated and optimised for CRUD / database type applications. Catalyst is much more agnostic about the model you use. It provides the flexibility and a way of structuring the code and providing debug tooling that makes structuring a decent size app well reasonably easy to do.

Catalyst was painful to work with in my experience. Just getting it setup was an achievement. Subroutine signatures as routes is an ugly hack.

I like catalyst,s dispatcher. And some of the pain of installing catalyst in the early days resulted in huge improvements to the change toolchain.
Post reply on HN