Perl Steering Council lays out a backwards compatible future for Perl 7

The much-anticipated Perl 7 continues to twinkle in the distance although the final release of 5.36.0 is "just around the corner", according to the Perl Steering Council. Well into its fourth decade, the fortunes of Perl have ebbed and flowed over the years. Things came to a head last year, with the departure of former " …

[VoiceOfTruth]

Backwards compatibility

-> It all sounds wonderful, but the price would have been the breaking of some backwards compatibility

This has been around forever, and I don't care about backwards compatibility 25 years later. I want to avoid doing this with Perl.

#!/usr/bin/perl

my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);

print("Year according to Perl: $year\n");

$year += 1900;

print("Fixed year: $year\n");

Year according to Perl: 122

Fixed year: 2022

Before you chime in I know that I can do:

use Time::Piece;

my $t = Time::Piece->new();

print $t->year . "\n";

That wasn't my point. My point is localtime(time) has forever been broken in Perl, and the reasons given were 'backwards compatibility'. Move on, Perl.

Then there's the Perl web site. Full of tutorials, some of which do not work. How about DNS? (https://learn.perl.org/examples/dns.html). If I copy and paste that (changing the resolver IP) and run it, do I get some DNS result? No, instead I get:

String found where operator expected at ./dns.pl line 17, near "say "Found an A record: ""

(Do you need to predeclare say?)

syntax error at ./dns.pl line 17, near "say "Found an A record: ""

Execution of ./dns.pl aborted due to compilation errors.

It's not good.

[Anonymous Coward]

Re: Backwards compatibility

My point is localtime(time) has forever been broken in Perl, and the reasons given were 'backwards compatibility'. Move on, Perl.

Are you suggesting that the result of running localtime(time) should change between versions of Perl and break existing code which relies on the current behaviour?

[VoiceOfTruth]

Re: Backwards compatibility

That's what was said 20 years ago. These people would still be using steam engines if they could.

The year returned by Perl localtime is wrong. It has always been wrong. So everyone in the whole world who uses it has to work around it.

[Anonymous Coward]

Re: Backwards compatibility

The year returned by the C function localtime is what gets returned by the Perl version of the same name. That hasn't been changed, either - nor has the PHP version: https://www.php.net/manual/en/function.localtime.php

[karlkarl]

Re: Backwards compatibility

Yes people *can* still use steam engines for their legacy projects. Why do you want to damage that?

Make a localtime_other() and be done with it. Heck if you pitch it hard enough, it might even be accepted into the standard libraries. I wouldn't vote against it; know why? Because it doesn't *break* anything.

Raku was made for API breakers; if that system worked, why are you "wasting" your time with Perl?

[jake]

Re: Backwards compatibility

Some people use steam engines on current projects. My 1915 Case might only make 65HP[0], but she'll also happily deliver upwards of 1200 ft/lb of torque. Quite the handy bit of kit.

[0] That 65 HP is burning scrap wood. She makes about 70 at the flywheel on coal (according to an ancient belt-driven dyno), but have you seen the price of anthracite recently? And no, I'm not going to burn low-grade coal. I'm the guy who has to work on the ol' gal. Likewise, I don't burn pressure treated wood.

[Grinnz]

Re: Backwards compatibility

It exists already. Time::Piece is in the core library and has a method to return the year as the OP admitted.

[jake]

Re: Backwards compatibility

"These people would still be using steam engines if they could."

I still use a steam engine (more formerly a traction engine, specifically a 1915 Case) to plow my bottom land. She's the only tractor I have that'll pull the 12 bottom in that soil (rocky, with a very high clay content). Are you seriously denigrating this very useful tool?

Likewise, I can show you successful businesses that are still running 40 to 50 year old COBOL and Fortran code. Not everything old is useless.

Shall we mention the Voyagers?

[VoiceOfTruth]

Re: Backwards compatibility

I don't have a problem with steam engines. I have a problem with people clinging to the steam engine method of programming. We've moved beyond that. There are very few steam engine manufacturers in the world. That era has passed. Why isn't Perl looking forward rather than backwards?

Would you make an electric car today with some steam valves added on just because? Perl needs to move on.

[yetanotheraoc]

Re: Backwards compatibility

"It has always been wrong."

It's only wrong if it doesn't match the spec. It's all 1s and 0s, write a function or use a library function to translate the 1s and 0s to some other representation. Even 2022 is just an arbitrary number, don't get too attached to it.

[Anonymous Coward]

Re: Backwards compatibility

localtime() isn't "broken". You may not like the API, but it works correctly. It's defined to return current year - 1900.

BTW, that behaviour was inherited from POSIX; see the definition of "struct tm": https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html

[VoiceOfTruth]

Re: Backwards compatibility

Hello. We live in the year 2000 something.

[Anonymous Coward]

Re: Backwards compatibility

I presume you want to mandate the unix world changes epoch from 1970-01-01 too?

The returned year is strftime has always been "since the year 1900".. There is no ambiguity in that. There are no bugs. (Though when Y2K hit, you saw numerous occasions of the year being reported as 19100 - but that's due to people not reading specs, and assuming what seems to work must work - thats a crappy programmer bug)

But ok, let's say you change the base from 1900 to 2000. Let's even ignore all the issues with old software only working on old perl, and new software having to grok perl version etc. Yes, let's forget that's even an issue.

What have you achieved?

instead of writing "year= tm.tm_year + 1900" you write "year = tm.tm_year + 2000", which does nothing but reallow the ambiguity of last centary, where people assume the returned value is simple "20XX"

If you're that bothered, use strftime.

[Anonymous Coward]

Re: Backwards compatibility

@VoiceOfTruth

Soon to be the post Soviet 1990s again for you.

[VoiceOfTruth]

Re: Backwards compatibility

I know all this crap. And this is a new version of Perl, like Perl 6 was a new version of Perl. It's time to fix it and not keep saying 'it has always been that way'. This is the sort of crap which puts people off Perl, yet the Perl Luddites cling onto it. They have time to rename Perl 6 to Raku, but not fix basic deficiencies.

Go in its time package makes life easy. When I print the year I get the correct year, not a year -1900:

package main

import (

"fmt"

"time"

)

func main() {

t := time.Now()

fmt.Println(t.Year())

}

go run year.go

2022

[jake]

Re: Backwards compatibility

You've spent how long, just in this thread, bitching about what exactly?

During the meanwhile, in all the years I've been using perl (a third of a century, give or take), I've wasted exactly zero seconds worrying about this non-problem.

Life's too short. Relax, have a homebrew.

Or, you could bop over to the perl forums and try to get the people who can actually make the change you want agree with you. That, at least, would be constructive ... if probably an equal waste of time.

[VoiceOfTruth]

Re: Backwards compatibility

-> I've wasted exactly zero seconds worrying about this non-problem.

How much time around the world has been wasted by typing $year += 1900;

Don't calculate the answer using Perl because you might need to munge the answer.

[Grinnz]

Re: Backwards compatibility

Complain to POSIX, this is how localtime works in C and every other language that implements the binding to that function. Nothing to do with Perl and won't be changing. That's why interfaces like Time::Piece exist.

Feel free to report the broken example (politely) to https://github.com/perlorg/perlweb. The fix is "use feature 'say';"

[VoiceOfTruth]

Re: Backwards compatibility

-> Feel free to report the broken example (politely) to https://github.com/perlorg/perlweb. The fix is "use feature 'say';"

How about the Perl web site gets off its collective arse and publish working examples? It's incredible that they put this crap out there without even looking at it.

[Grinnz]

Re: Backwards compatibility

Lots of things are incredible, like complaining about something other people did for free and refusing to contribute anything useful yourself.

[VoiceOfTruth]

Re: Backwards compatibility

Imagine that your first introduction to Perl is a DNS thing. I know, I'll use Perl. Oh look, there's an example on the Perl web site. I'll use that.

Oh, it does not work. What have I done wrong? I've typed it exactly as it is there. Maybe I'll copy and paste it. Oh, it still does not work. Is it my version of Perl?

How the Perl web site has the audacity to inflict this sort of non-working example on the world I do not know. Why people defend non-working examples just because they are free I do not know.

[that one in the corner]

Re: Backwards compatibility

Love the way that you are complaining about broken examples at the same time as demanding a change that will break even more examples.

And then consider someone asking the question "Is it my version of Perl?" - yes, it would be, if you had your way.

It is a shame if there are broken examples - but having found them, you have opened a ticket, haven't you? Or maybe even attached to the ticket a corrected version?

[Frumious Bandersnatch]

Re: Backwards compatibility

Feel free to report the broken example (politely) to https://github.com/perlorg/perlweb. The fix is "use feature 'say';"

Or use the `-E` flag to Perl somewhere. Or, more neatly, specify what the minimum required Perl version is for your code, eg:

use v5.10;

Use `perldoc feature` to see what new optional features are available in your perl and what version they first appeared in.

[DrXym]

Re: Backwards compatibility

More desirable is they should just implement a decent chrono package where there are no surprises and where if you ask for *any* date you can do stuff like durations, offsets and so forth.

[John Gamble]

Re: Backwards compatibility

Your mileage may vary, of course, but they did.

MetaPAN Date.

[Norman Nescio]

Re: Backwards compatibility

This is good advice. Rolling your own time functions is fraught with elephant traps:

Falsehoods programmers believe about time

Asking for the ability to process *any* date programmatically is a 'bit of a stretch'.

Making <time> safe for historians>

Assumptions about time and clocks is a rich source of obscure errors and gotchas.

[Dan 55]

Re: Backwards compatibility

Wait until you find out what date epoch begins at in UNIX, it's going to blow your mind.

[Crypto Monad]

"they expressed a desire to increase the rate at which new features are introduced and encourage their adoption"

I would prefer a language which *minimises* the rate at which new features are introduced. Each feature adds cognitive load, and whilst it may make certain patterns shorter to code, it makes them harder to read.

However, whatever you think of Perl, you can't accuse it of developing too quickly over the last 2 decades.

[John Gamble]

The problem is that that attitude tends to lead to nothing being added. There are a couple of features supplied by modules that should have been in the language proper at least a decade ago, and maybe before then.

And I would be thrilled if a couple of features were eliminated (or at least transferred into a module). The reduce "reduce cognitive load" argument cuts both ways.

[Anonymous Coward]

boilerplate

I don't understand the need to change things much to reduce boilerplate

What's wrong with

use Modern::Perl;

or somesuch?

[DrXym]

Sensibly written

What does that even mean in the context of perl which is renowned for unintelligible lines of code?

[jake]

Re: Sensibly written

Any language can be written to be unintelligible to the uninitiated, even English ... but I would wager that the more unintelligible the code can be made to appear while still doing exactly what the programmer intends, the more powerful that language is.

[VoiceOfTruth]

Re: Sensibly written

While I used Perl for a few years about 25 years ago, I would not want to go back to it. If you use any of the shorthand stuff it becomes illegible if you don't use Perl very regularly.

[John Gamble]

Re: Sensibly written

Golfers, mostly (this was a C phenomenon too, back in the day).

It's one of those things that look fun, until you realize that there are programmers who will take those idioms seriously and use them in their code. I had to undo a lot of them in one module I upgraded.

[DarkwavePunk]

Perl

Used Perl4 as an awk/sed substitute for silly nested/piped shell scripts. Worked okay and still looked horrible. Perl5 still fits that role as well. If version 7 doesn't break the horrible 1-line data munge crap - go for it. Stick with sed/awk/shell, if only to piss off the Ops team. </sysadmin>

[yetanotheraoc]

Re: Perl

sed/awk/shell works for me. I can't write programs as concise as the ones in _The Awk Programming Language_, nevertheless the Posix text utilities and a little nawk/gawk glue can get me pretty far.

"throw away one of Perl's key strengths"

I can see how that would cause arguments. Every language has its own way of doing things. Trying to make Perl into something else, e.g. Javascript, would not be good Perl and it wouldn't be good Javascript either.

[Gene Cash]

Perl is great for copy protection

Nobody can read and understand a perl script other than the author!

Write it in perl and nobody will be able to steal your algorithm.

[Dan 55]

Re: Perl is great for copy protection

I hear Perl allows subroutines, comments, and formatting, and has done for quite a while now...

[Thought About IT]

Write-only

As far as I'm concerned, Perl is a write-only language so they'll have to make drastic changes to fix that fundamental deficiency.

[Warm Braw]

What happened to Perl 7?

Perhaps the new incarnation should be renamed swine and the previous versions maintained as they are - perls before swine, if you will.

[-tim]

The real Perl problem: lack of new developers

Our problem with Perl is lack of new programmers. Our business runs a bit of Perl and it is the most profitable per line of code by a huge margin but new coders haven't even looked at Perl.

As far as backward compatibility goes, recent version of Perl 5 have broken more things that any other version change I can remember and I have scripts that started out with version 3.

[ciaran]

Re: The real Perl problem: lack of new developers

I do most of my tools in Perl, I feel very productive, I can maintain my code easily.

However when I go it'll all go in the bin.

I tried doing a few projects in Bash to be more politically correct, but in truth none of my colleagues are able to write or understand a real program in Bash.

I feel that I should switch to Python, it has a lot of good features, but I never have a new project and the time to invest at the same time.

Back to my current question, how to parse a date in year + day of year format in perl. Surprisingly none of the standard modules want to touch it...