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

181–190 of 573 posts

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

#181

Post by aduitsis »

staycoolboy wrote: post #116
jes5199 wrote: post #48

Earlier 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…

Perl was my first encounter with regular expressions. To this day, no language I've used does it better and cleaner. This includes Python, Boost/C++, Java, JavaScript, LISP, Go and Rust.

Favorite syntactic sugar feature: the /x modifier which makes the regex ignore spaces and comments, meaning you can break your regex into multiple lines and comment them.

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

#182

Post by ashton314 »

My very first program was:

    perl -e 'print int rand(10);'
Good times. Good times. :)

I wrote a lot of Perl. I even wrote a small LISP interpreter entirely in Perl! These days I write more Racket and Elixir, but there's still a soft spot in my heart for Perl. I hope this will breath some fresh life into the language. I think it has a lot of interesting ideas about language design that new languages would do well to copy.

Perl is (in)famous for all the shortcuts possible in the language. While this does steepen the learning curve, I think there are some valuable ideas worth exploring. The implicit topic variable (`$_`) is super nice when throwing together a little script. The semantics are well laid-out in its documentation. I think an improvement would be to somehow make it more clear directly in the language itself where the topic variable is used. Maybe that's what I'll end up looking at in some research. :)

Lots of languages, I feel, optimize for readability for beginners. (I'm thinking about Python and Go here.) Perl is optimized for people familiar with the language. I think that can be a good thing, if done right. What do you guys think?

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

#183

Post by aduitsis »

Ovid wrote: post #155

As a short summary about Perl 7: If your Perl is old-school, that's OK. Use Perl 5 and we'll keeping supporting you. If you your Perl isn't old-school, use Perl 7 and get new features. If you're not sure, ask us and we'll hold your hand to help you understand. We're here to make sure you're OK.

Any chance Cor makes it into Perl 7?

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

#184

Post by phone8675309 »

cutler wrote: post #102
jqcoffey wrote: post #40

Earlier quoted context omitted.

Ok, so I wrote tons of Perl and am to this day a fan, but I don’t think one can call a blessed hash (or scalar for the fancy folks) an object _system_. It is flexible and fun and I do miss it. True story: years of passing functions to other functions and map/greps made the switch to FP Scala (another language I fear will die) a lot easier!

I've heard Python's object system isn't that different under the hood.

You even have the same boilerplate of the first argument to a class member function being the object itself.

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

#185

Post by bch »

joosters wrote: post #104
earthboundkid wrote: post #84

Earlier quoted context omitted.

Perl definitely has a lot of non-patterned arcana. For instance, $| This variable, if nonzero, will flush the output buffer after every write() or print() function. Normally, it is set to 0. In other languages, you do something like os.stdout.buffered(true) or sys.stdout = io::buffer(sys.stdout) or something like that where you're combining composable pieces: the standard std variable, a standard way of opening files…

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.

Some things are unavoidable though. Perl hijacking a user space variable to do internal sort management? Bizarre to my mind, and utterly confounding the first time one accidentally runs into it.

[0] https://stackoverflow.com/questions/26127617/what-exactly-ar...

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

#186

Post by lilSebastian »

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.

Perl is used extensively in the enterprise solutions we deliver for our client.

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

#187

Post by DonHopkins »

joosters wrote: post #180
DonHopkins wrote: post #173

Earlier quoted context omitted.

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…

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.

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

#188

Post by yellowapple »

hinkley wrote: post #35
politelemon wrote: post #19

Earlier quoted context omitted.

Yes... We have some high revenue, important contract type systems written a long time ago and maintained by the same subject matter experts who simply move the codebases (old and new) to newer systems and stacks. As you can tell, the SMEs have no interest in learning other things and so any new initiatives that require them to implement it is subject to their preferences.

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…

> and it’s hard to impossible to find Perl programmers

Which I'm finding harder to understand as I learn more languages. Yeah, every language has its differences and idiosyncrasies, but as long as you have access to docs (if not third-party resources like expert blogs or Stack Overflow) it's pretty straightforward to figure those out and be reasonably productive relatively soon.

That is: a senior programmer should have enough background knowledge to be able to be productive on any language ("polyglot" shouldn't be a big deal), and a junior programmer won't typically have enough experience in any particular language to be definitively a "$LANGUAGE programmer". In either case, whether or not a programmer already knows the language before being hired is kind of a moot point.

My current dayjob was the first time I had written any non-trivial amounts of Python, Javascript, or C# in a professional capacity in my whole career. Being productive on them wasn't terribly hard - it's just different syntax around a lot of the same concepts (and sure, there were also some new concepts - took a good while for me to wrap my head around async/await, for example, coming from a background of message passing between threads or processes or actors - but those can be learned).

Usually the choice of programming language is far less significant as a barrier to one's understanding of a codebase than, say, the actual problem domain. Writing software for, say, a warehouse tends to necessitate knowing an awful lot about how warehouses work; whether or not you happen to know a given programming language is entirely secondary to whether or not you know the difference between a picker and a packer, or between a replenishment and a cycle count. Similar deal in medicine, or education, or manufacturing, or sales, or finance, or what have you.

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

#190

Post by qalmakka »

Perl is the swiss army knife of the shell. Works the same everywhere, it has always been reliable and superuseful for simple to medium scripts. It's the glue that keeps a lot of stuff together, and I'm happy it got back to its tracks after the v6 faux pas.
Post reply on HN