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

201–210 of 573 posts

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

#201

Post by yellowapple »

roywashere wrote: post #123
lgl wrote: post #95

Earlier quoted context omitted.

> Are there actually people that are still deploying new things in Perl? My personal experience: at one of my previous jobs we've had the need to find a support ticket system (preferably free) that was flexible enough to handle a few hundred email accounts with different signatures, headers, reply templates, queues, filters, and more for each individual account. At the time the "winner" was OTRS [0] [1], a system in…

I actually worked for OTRS for some years. It is quite a remarkable company as it is creating an open source line of business software with a nice team of people and is making a sustainable business out of it. There are not much other software companies that managed to do this. Yes, you can call them open core now. But still many companies are using the community edition and are served well by it. I worked closely wi…

What I'm hoping for is that Perl 7 will enforce those "proper code conventions" and mitigate that deterioration. Making a lot of common pragmas the default is a good start there.

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

#202

Post by davorg »

cutler wrote: post #153
OakNinja wrote: post #109

Developers in their forties wrote Perl. Developers in their thirties replaced Perl. Developers in their twenties say “What’s Perl?”

Yes and developers in their 50s retired in their mid-30s after making fortunes writing Perl.

I wish :-)

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

#203

Post by toast0 »

radiator wrote: post #179
toast0 wrote: post #39

Earlier quoted context omitted.

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.

Some people would consider that a good thing.

I assume you're saying it's a good thing there's no reasonable protobuf support? The problem is I have access to data I'd like to manipulate, but it's in protobuf, so my options are:

a) somehow convince Google to let me access Nest data through a proper API

b) get a different thermostat

c) magically get the perl protobuf libraries to actually work

d) write just enough protobuf parsing (and possibly generating) to read my data, and curse

e) use another language to parse the data (ugh)

(I guess you could like to throw out 20 years of experience)

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

#204

Post by derriz »

hinkley wrote: post #168
gmmeyer wrote: post #71

Earlier quoted context omitted.

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.

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.

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

#205

Post by wbl »

earthboundkid wrote: post #84
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 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…

$| is related to pipes. Much of the sigils are like this.

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

#206

Post by staycoolboy »

freedomben wrote: post #151
staycoolboy wrote: post #116

Earlier quoted context omitted.

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.

Awk and Ruby aren't on your list, any experience with those that you could compare/contrast with Perl?

Awk is very similar in syntax, but doesn't provide the sophistication of match vs subst, and doesn't support suffix modifiers.

I only used Ruby briefly over 20 years ago so I can't comment.

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

#207

Post by hyperbovine »

cafard wrote: post #164

I have used Perl since the Perl 4 days. One can write bad Perl, and I've written a lot. One can write good Perl, and I've written some. It has saved me and others quite a lot of time on assorted projects. These days I tend to use Python where once I'd have used Perl. This is mostly because I find that the young are far more likely to know Python than to know Perl. I will be retiring one of these days, after all.

I don't think it's necessarily generational. Perl and Python differ in a key regard: Perl went all in on TIMTOWTDI, whereas Python went in the complete opposite direction: enforced whitespace, minimal syntax, strong use of conventions and idioms. (When was the last time you heard somebody inquiring about the Perl-ic way to write something?) As a result, a lot of Perl code is an unreadable mess, and many Python programs are intelligible even to non-programmers. It's hard to overstate what a win this is for Python.

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

#208

Post by yellowapple »

papito wrote: post #149
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.

IMDB was written in Perl, notoriously. Seeing that the layout has not changed in ages, I can only assume it's still Perl. I'd imagine a bigger rewrite effort would have led to a more slick iteration on the UI, and it seems the legacy HTML templates are still baked in.

DuckDuckGo's also written in Perl, and doesn't seem to have any trouble maintaining a reasonably-modern-looking UI.

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

#209

Post by hinkley »

yellowapple wrote: post #188
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…

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

A former boss was fond of saying "Software is done when nobody is willing to work on it anymore."

New people make idiomatic mistakes, and if the language isn't cool they expect more money. Recruiting people is harder, so you tend to get stuck with the people you have, and managers tend to bristle at that. Eventually a new language full of people who look like cogs is going to win out. I hate that this is true, but it is.

I maintained a Python test harness for a while. No prior experience with Python. I mostly stayed out of trouble, in part because I set low expectations, tried nothing fancy. But it wasn't what I wanted to be doing, and not what I wanted the team to be doing. When I left they finally canned the entire thing.

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

#210

Post by tomku »

cutler wrote: post #141
orf wrote: post #100

Earlier quoted context omitted.

Lets see the code? Regex has always been a Perl selling point, and you're just benchmarking the Python Regex library (written in C) against Perl's regex library. That's not a fantastic basis for a comparison.

Perl 5: #!/usr/bin/env perl use 5.026; open my $fh, ' ) { chomp; say if /\b\w{15}\b/; } close $fh; Python 3.8 #!/usr/bin/env python import re with open('logs1.txt', 'r') as fh: for line in fh: if re.search(r'\b\w{15}\b', line): print(line, end='') Why isn't it a fair comparison? The startup time is generic and string parsing is a major feature of, say, web development. I didn't say Perl5 numerics match Python's but e…

It doesn't account for anywhere near the whole difference, but in a tight loop like that Python's going to be spending a good chunk of its time re-compiling the regex from the raw string literal every iteration. Hoist the regex definition out of the loop like so and it'll probably run about 30% faster:

  #!/usr/bin/env python3

  import re

  with open('logs1.txt', 'r') as fh:
      regex = re.compile(r'\b\w{15}\b')
      for line in fh:
          if regex.search(line): print(line, end='')
Perl almost certainly does this by default for regex literals, and that's a fair advantage for the "kitchen sink" style of language design versus orthogonal features (regex library, raw strings) that Python uses.
Post reply on HN