'Massive' Ongoing Changes to Perl Help It Move Beyond Its Unix Roots (stackoverflow.blog) 74
Perl's major version number hasn't changed since 1994, notes a new blog post at Stack Overflow by Perl book author Dave Cross. Yet the programming language has still undergone "massive changes" between version 5.6 (summer of 2000) and version 5.36 (released this May).
But because the Perl development strives for backwards compatibility, "many new Perl features are hidden away behind feature guards and aren't available unless you explicitly turn them on...." You're no doubt familiar with using print() to display data on the console or to write it to a file. Perl 5.10 introduced the say() command which does the same thing but automatically adds a newline character to the output. It sounds like a small thing, but it's surprisingly useful. How many times do you print a line of data to a file and have to remember to explicitly add the newline? This just makes your life a little bit easier....
Some of the improvements were needed because in places Perl's Unix/C heritage shows through a little more than we'd like it to in the 21st century. One good example of this is bareword filehandles... It is a variable. And, worst than that, it's a package variable (which is the closest thing that Perl has to a global variable)... [But] for a long time (back to at least Perl 5.6), it has been possible to open filehandles and store them in lexical variables... For a long time, Perl's standard functions for dealing with dates and times were also very tied to its Unix roots. You may have seen code like this:
my @datetime = localtime();
The localtime() function returns a list of values that represent the various parts of the current local time... Since Perl 5.10, the standard library has included a module called Time::Piece. When you use Time::Piece in your code, it overrides localtime() and replaces it with a function that returns an object that contains details of the current time and date. That object has a strftime() method... And it also has several other methods for accessing information about the time and date [including a method called is_leap_year]... Using Time::Piece will almost certainly make your date and time handling code easier to write and (more importantly) easier to read and understand....
In most languages you'd have a list of variable names after the subroutine name and the parameters would be passed directly into those. Well, as of version 5.36 (which was released earlier this summer) Perl has that too. You turn the feature on with use feature 'signatures'.... Subroutine signatures have many other features. You can, for example, declare default values for parameters.
And new features possibly coming soon incude a new object-oriented programming framework named Corinna being written into the Perl core. "Beyond that, the Perl development team have their eye on a major version number bump."
And to avoid confusion with Raku -- the offshoot programming language formerly known as Perl 6 -- the next major version of Perl will be Perl 7.
But because the Perl development strives for backwards compatibility, "many new Perl features are hidden away behind feature guards and aren't available unless you explicitly turn them on...." You're no doubt familiar with using print() to display data on the console or to write it to a file. Perl 5.10 introduced the say() command which does the same thing but automatically adds a newline character to the output. It sounds like a small thing, but it's surprisingly useful. How many times do you print a line of data to a file and have to remember to explicitly add the newline? This just makes your life a little bit easier....
Some of the improvements were needed because in places Perl's Unix/C heritage shows through a little more than we'd like it to in the 21st century. One good example of this is bareword filehandles... It is a variable. And, worst than that, it's a package variable (which is the closest thing that Perl has to a global variable)... [But] for a long time (back to at least Perl 5.6), it has been possible to open filehandles and store them in lexical variables... For a long time, Perl's standard functions for dealing with dates and times were also very tied to its Unix roots. You may have seen code like this:
my @datetime = localtime();
The localtime() function returns a list of values that represent the various parts of the current local time... Since Perl 5.10, the standard library has included a module called Time::Piece. When you use Time::Piece in your code, it overrides localtime() and replaces it with a function that returns an object that contains details of the current time and date. That object has a strftime() method... And it also has several other methods for accessing information about the time and date [including a method called is_leap_year]... Using Time::Piece will almost certainly make your date and time handling code easier to write and (more importantly) easier to read and understand....
In most languages you'd have a list of variable names after the subroutine name and the parameters would be passed directly into those. Well, as of version 5.36 (which was released earlier this summer) Perl has that too. You turn the feature on with use feature 'signatures'.... Subroutine signatures have many other features. You can, for example, declare default values for parameters.
And new features possibly coming soon incude a new object-oriented programming framework named Corinna being written into the Perl core. "Beyond that, the Perl development team have their eye on a major version number bump."
And to avoid confusion with Raku -- the offshoot programming language formerly known as Perl 6 -- the next major version of Perl will be Perl 7.
Linus decided version numbers are meaningless (Score:1)
Re:Linus decided version numbers are meaningless (Score:4, Interesting)
Even Linus makes sure his version numbers increment and not oscillate.
Perl has already used 6.0 and it keeps repeating 5.x. Type in "Perl 6" on Google and you'll find plenty of stuff which really points to Raku. As long as they don't take the huge step of saying "Raku no longer follows on from modern Perl" they will keep getting more and more obscure and losing users and more importantly losing library maintainers.
I don't understand why the Perl people don't understand that "we are no longer guaranteeing forward compatibility with Perl 6" is a huge thing to say and that they need to say it soon to be able to move forward effectively.
Re: (Score:2)
Even Linus makes sure his version numbers increment and not oscillate.
Perl has already used 6.0 and it keeps repeating 5.x. Type in "Perl 6" on Google and you'll find plenty of stuff which really points to Raku. As long as they don't take the huge step of saying "Raku no longer follows on from modern Perl" they will keep getting more and more obscure and losing users and more importantly losing library maintainers.
I don't understand why the Perl people don't understand that "we are no longer guaranteeing forward compatibility with Perl 6" is a huge thing to say and that they need to say it soon to be able to move forward effectively.
Shenanigans like that are but one of the reasons I haven't written a line of Perl code in 15 years and if they manage to break Python continuity one more time I'm going to abandon that language too.
Re: (Score:2)
don't understand why the Perl people don't understand that "we are no longer guaranteeing forward compatibility with Perl 6" is a huge thing to say and that they need to say it soon to be able to move forward effectively.
It appears that you either didn't understand or didn't read the summary.
Re: (Score:3)
don't understand why the Perl people don't understand that "we are no longer guaranteeing forward compatibility with Perl 6" is a huge thing to say and that they need to say it soon to be able to move forward effectively.
It appears that you either didn't understand or didn't read the summary.
I'm guessing you mean the bit that says
the next major version of Perl will be Perl 7.
and you didn't read the bit in the other articles which says that they still don't plan this for any particular time because they still don't think there's enough change to justify a "major" version so the next release and probably many more to follow will be a minor release.
This. Is. Confusing. As. Fuck. Normally I'd just follow some slashdot traditions and be just a tad ruder to you than you were to me. Today, however, I just feel sympathy with you for finding out th
Re: (Score:2)
I'm guessing you mean the bit that says
the next major version of Perl will be Perl 7.
No, I am referencing the part that I actually quoted . I'll quote it again, to make things easy for you (apparently you need this):
don't understand why the Perl people don't understand that "we are no longer guaranteeing forward compatibility with Perl 6" is a huge thing to say and that they need to say it soon to be able to move forward effectively.
You seem to have missed the point that Perl 6 no longer exists -- it has been renamed Raku and is a fork of Perl, not a later version.
Re: (Score:2)
You seem to have missed the point that Perl 6 no longer exists -- it has been renamed Raku and is a fork of Perl, not a later version.
And you seem to be using an old definition of "exists". According to Google Perl 6 clearly does exist [letmegooglethat.com] and that's all that matters for confusing people.
Re: (Score:2)
Strangely, I get a blank page when I use that LMGTFY link, which doesn't really support the point you are trying to make.
Generally, though, Perl 6 links redirect to Raku.
Re: (Score:2)
I guess I would respect your security tools. It's likely that you're rightly blocking some javascript that LMGTFY requires. I'll just say it's a reasonably well known site and has been there for a while, if that's a good way of judging security. Just googling "Perl 6" yourself should probably work though I think that what you will see will depend more on your custom settings.
On the top of the Google page that LMGTFY shows there's the following text:
Re: (Score:2)
Let me add. the final link given out by LMGTFY is https://google.gprivate.com/search.php?search?q=Perl+6 [gprivate.com]. Hopefully that's the non-customized google which will show the same for you?
Re: (Score:2)
Just as another random example, which should be more convincing than Google than some, the gitignore.io ignore file generator references Perl6 and doesn't have Raku at all. Ask Madame Streisand about trying to get things expunged from the internet.
Re: (Score:1)
Re: (Score:1)
Re: (Score:3)
$, @, % provide good clarity. It's always clear when a $ is a pointer. Not wanting to appear "toy" is what gets a lot of languages into trouble, following new paradigms that look better in concept than deployed. Or they may be good, but take a decade to mature. At least Perl is well documented, and the module ecology is solid once you figure out which ones are more standard and less experimental. That said, I only use it for utilities, and use another derided language for web front-ends. One that took a dec
Re:Linus decided version numbers are meaningless (Score:4, Insightful)
Like C.... Perl should SKIP version 7 and simply use YEARS. Perl 2022 at the end of this year really is this recent Perl with tons of new popular features ON BY DEFAULT (but not all of them.) or how about just Perl 22? only becomes a naming issue in 2100.
They can optimize them for faster startup in 2023 and decide which features can't be disabled that were enabled by default previously. bug fixes can be builds during the year.
Re: (Score:2)
or how about just Perl 22? only becomes a naming issue in 2100.
Y2.1K, here we come!
Re: (Score:2)
I thought that when I typed it; however, you seriously think we are going to care in 2100 hundred about Perl versioning?? Maybe it'll crash the AI overlords and give the resistance a chance? (Or the AI will cleverly just start counting at 100 and use 3 digits)
Re: (Score:2)
I thought that when I typed it; however, you seriously think we are going to care in 2100 hundred about Perl versioning??
No, I just find it amusing. Though we had to deal with a lot of stuff in Y2K that we never thought would have lasted that long...
oh noes the newline (Score:2)
I don't need more functions which wrap functions, if I did I'd write them. It's not going to hurt me, except for creating unnecessary backwards compatibility, but it's not like it's hard to write that wrapper function.
OTOH,
"When you use Time::Piece in your code, it overrides localtime() and replaces it with a function that returns an object that contains details of the current time and date."
That's great. No changes have to be made to the code? Perfecto.
Re: (Score:2)
Yeahp. Say is basically pointless. Just type "$\ = '\n';" and you get a newline after every print.
I used to really like Perl, but the more I've used it for complicated things, the less I like it. I've been using other languages, particularly Python and C++, for things that I used to do in Perl.
Re: (Score:1)
I still really like perl, I have written a little bit of C++, I despise python since the first time I ever tried to C&P a code sample it flattened and was worthless. Indentation having meaning is a holdover from punch cards, and getting past that was an advance in computing. Odds are good that if I want to do something I can't easily do with shell scripting, I can do it with perl, or I'm going to be modifying someone else's code to do it anyway.
Re: oh noes the newline (Score:2)
Agreed. There are some things about Python that I really don't like (indentation, like you said), but I've had to pick it up because it won the war. I used to be pretty good at perl, but that was 15 years ago. I don't see myself going back to it.
Re: (Score:2)
I honestly used to think: "I don't need Python. I have Perl." I started messing around with Python a few years ago, and I found it to be usable despite the white space issues. I use it mostly for small utilities that I might have otherwise written in Perl.
I still probably write more Perl than any other language. I'm paid to work on a large F/OSS project that is mostly written in Perl. Sometimes, I curse the Perl layer because too many people have introduced too many different idioms into the code over the y
Re: (Score:2)
I never found threads all that difficult in perl. You either use thread queues to pass objects to worker pools, or use a worker pool library. Is the difficulty that you want to be able to write the code the same as single-threaded code and share scopes with the main thread?
Re: (Score:2)
The project I work on uses many non-MT safe modules. Encode being the main one. You simply cannot use threads in Perl with non-MT safe modules.
In C++ or Python, if you have non-MT safe code, you can implement a MT safe wrapper with locks or atomics.
Re: (Score:2)
Got it, thanks. That makes sense--in my use case I was writing my own logic, so that wasn't an issue.
A side note: when I eventually ported that small-ish program to Rust, I discovered a lot of bugs. Now I don't trust myself to write code of that complexity in Perl anymore. Surely it can be done, but I'd better not attempt it.
Re: (Score:2)
> There are some things that the architecture of Perl 5 makes very hard to do that are dead easy in Python, threads for instance.
LOL. CPython, the standard one everyone uses, still has the GIL - The Global Interpreter Lock
That is, Python doesn't support proper threading. Some libraries, such as numpy, manually release this lock allowing a degree of threading during a numpy calculation. Understanding this isn't simple, and requires a deep dive into the documentation of any computation library you are con
Re: (Score:2)
TBH, I mostly only use threads with C++, so I should have reflected that in my previous comment. Thank you for sharing your response, I did know that about threads in Python.
I've mostly only used threads in toy/practice programs in Python. I use the subprocess module a lot.
I suppose I should reread my posts more carefully before hitting submit.
Re:oh noes the newline (Score:4, Funny)
Just type "$\ = '\n';"
I always thought you have to type, "$&**#@&*NO CARRIER" to get that done. Thanks for clearing that up.
Re: (Score:2)
What about portability though? Line endings differ between systems.
Windows/Terminals: CR LF
Linux/BSD/Amiga/MacOS: LF
Old QNX: RS
ZX80: 0x78
If it was just Windows we might be okay, but it's the terminals that are the problem. RS232 to terminal is still widely used.
Re: (Score:2)
CR from "classic" MacOS was the one I saw the most besides LF and CRLF. The ZX80 was 0x76.
Perl handles eoln transparently by converting to LF on input and back to whatever eoln on output, but it's good to know what it's doing so you know when to use binmode(), which is explained in detail here: https://perldoc.perl.org/funct... [perl.org]
It's a very stable language, and easier to script in than shell, or one-liners. I rarely use awk, sed, etc. Just perl script it and self-document it, and it's portable. I do use grep
Re: (Score:2)
Re: (Score:2)
MacOS is now called Classic MacOS, while OSX is called macOS. Now that breaks backwards naming! Perl naming has no problem if you accept that Perl 6 does not exist, like Windows 9.
Re: (Score:1)
was literally last century. We've all been using DateTime since the nineties; there was no
reason to change this.
Honestly, the thing that would make me want to use a recent version of Perl, is the
defined-or operator, especially the defined-or-set-equal version (//=). THAT is useful.
Help Perl move beyond its Unix roots (Score:2)
"many new Perl features are hidden away behind feature guards and aren't available unless you explicitly turn them on...."
Yea, it's not as if anyone would ever read the manual
"You're no doubt familiar with using print() to display data on the console or to write it to a file. Perl 5.10 introduced the say() command which does the same thing but automatically adds a newline character to the output."
Wow
Re: (Score:2)
Wow .. that looks a lot like the "c" print function and it's not as if anyone ever overloaded a function with their own features.
perl does have a printf() [perl.org] which functions broadly the same way as the C function. It also has a print() function which does not, it is more like C++ cout, except you can specify a filehandle and it otherwise defaults to the current filehandle (which until modified is stdout.)
None of these functions in any of these languages print a newline after your input. Hence say(), I guess. This was never a big problem though. Or IME, even a small one. I'd rather just see the \n in my print statement than distinguish
the newline alternative to print is... say?! (Score:2)
How intuitive! /s
How about adding an option that people could use like... you know... /n at the end of a line, or if you really have to, add a println function?
Re:the newline alternative to print is... say?! (Score:4, Insightful)
or if you really have to, add a println function?
Probably it's because Larry Wall is a "linguist", so he prefers using random English language synonyms straight out of the thesaurus such as say() instead of standard computing conventions like println().
It's too late for Perl (Score:3, Funny)
Re: (Score:2)
Let's face it - Python has already won
Won what? The distinction of being the most popular language among people who are confused by curly braces and semicolons? Perl is still here, still being developed, and still dramatically more performant than Python is even expected to become in the foreseeable future.
Despite all that, the decision to use whitespace for structure in Python might be the only reason Perl is still here. Ugh.
Re: (Score:2)
> Despite all that, the decision to use whitespace for structure in Python might be the only reason Perl is still here. Ugh.
You can write Python with braces and run it through a tiny Perl script to re-indent it.
Re:It's too late for Perl (Score:4, Interesting)
You can write Python with braces and run it through a tiny Perl script to re-indent it.
If only there was a way for the Python developers to add a switch to allow braces...
They could settle the debate once and for all and take over the entire world!
Re: (Score:2)
How about:
from __future__ import braces
ok, maybe not what you expected :p
Re: (Score:2)
>>> from __future__ import braces
File "<stdin>", line 1
SyntaxError: not a chance
Re: (Score:2)
not a chance... hum, I guess it wasnt your lucky day :p
Re: (Score:2)
I'll just write Perl, I'm already familiar with it (enough to use it anyway, if not to manipulate or even comprehend someone else's "clever" Perl code) and I have yet to experience wanting but not finding a module to do something I thought there should be a Perl module to do. I've used it over the years to do a variety of jobs including programming VLANs on catalyst switches with a Framemaker front end.
Recently I wrote a little perl script using XS to evaluate CSVs and then load their contents into postgres
Re: (Score:2)
Re: (Score:2)
I think python's use of whitespace might be why it is so popular.
In fact, I believe that both things are true; it's both why it is so popular, and also why some people don't like it.
I for one have already sort-of learned Perl, and what Python I have seen hasn't impressed me, plus other stuff I've shared in this thread already. Perl as I use it hasn't changed much since 4. Things have obviously changed, but few of them have affected me significantly. So far every time I have tried to solve a problem with it, I have succeeded, so either I'm short on imagination or Perl is
Re: (Score:2)
On the other hand, sometimes the regular expression that does what you need it to do is hard to look at.
Yeah, regexes are what got me into Perl back in the day. They can be a bit inscrutable, but they are just so powerful, and you can do some crazy things, like negative lookbehinds and named backreferences (https://perldoc.perl.org/perlre). Like you said somewhere else, you can do regexes in Python too, but Perl regexes are faster and just seem more natural to me when writing them.
Too bad Raku kind of fizzled out because they really kicked it up a notch with grammars (among many other useful things),
https://e [wikibooks.org]
Re: (Score:2)
I haven't seen any CPAN modules written in obfuscated Perl. They're full of POD documentation and use clear coding practices.
Re: (Score:2)
Edit: s/obfuscated/condensed/
Re: (Score:2)
I wasn't suggesting otherwise. I also wouldn't know personally because so far every one I've ever used has worked, and I haven't had to tamper with it. Perl was the first scripting language (that I'm aware of at least) to have such a strong ecosystem around it, and since I was around at the time, it's what I picked up. I've never had cause to regret it. While other scripting languages abound, Perl still suits my needs. It's arguably a perfect match for Unix, and Unix is so far the best match for reality.
Re: (Score:2)
WTF would you do that?
And why blame perl for your own incompetence? That's like blaming a hammer because you deliberately target your own thumb every time you strike with it.
Re: (Score:1)
> and still dramatically more performant than Python is even expected to become in the foreseeable future.
Only a small percentage of sites really need to care about performance. Via a load balancer, one can throw hardware at the problem. For most CRUD apps, the bottleneck should be the database. If not, you are likely doing something wrong. (Other domains may be different.)
As far as the language wars, Perl and Python both have something to be desired, but people get used to the warts of their language s
Re: (Score:2)
Only a small percentage of sites really need to care about performance.
If the only Python were mod_python, and the only use of [/usr]/bin/python were CGI scripting, then that would be ducky. But Python is now being used for cases where performance is relevant. And for something like horking a bunch of text and twiddling it, Perl is four to five times faster. It's not just text processing (Perl's original reason for existence) where Perl is more performant, though. Literally any time execution of the actual language matters and the heavy lifting isn't all being done by a librar
Return the audio guide when you exit the museum (Score:4, Funny)
Unix (Score:2)
Right now is the wrong time to leave behind "Unix roots." Unix is more popular as a development environment than ever. Even developers on Microsoft Windows use Unix.
Unix is not the problem Perl has.
Re: (Score:3)
Right now is the wrong time to leave behind "Unix roots."
Don't worry, it's not what is happening, headline is misleading. TFA is a historical perspective. The "say" and "localtime" commands are under discussion were released 22 and 15 years ago (perl 5.6 and 5.10) and absolutely nobody is talking about what OS developers are using. The mention of "Perlâ(TM)s Unix/C heritage" is about how original Perl commands replicated old C syntax, which then evolved in more recent versions of perl to be more programmer friendly.
massive changes? (Score:2)
I suppose they might be present, but none were mentioned in the summary.
What I want to know is how fast is it (in comparison), or how does it handle thread safety, or SOMETHING that would make a significant difference. So far every time I've looked at perl, something else would do the job better. Sometimes even awk won.
Minor correction here (Score:2)
The print() function prints it's arguments, followed by the defined line terminator, $\. The default of which is not defined (or the empty string. I forget which). Defining this in a proper initialization routine can set it correctly for whichever OS you happen to be using. I'm not certain if say() has adopted the same behavior or just defaults to a newline. Which could be a nightmare when porting code to a non-Unix system with a different delimiter. Same holds true for hard-coding "\n" on the tail of each
Re: (Score:2)
Global variables are evil
local $\ = "\n";
Re: (Score:2)
Maybe the next version of systemd includes something that replaces a python interpreter :p
it already replaces so many things, I wouldn't be surprised if we had soon a systemd os running straight from the boot sector :p
Re: (Score:2)
it already replaces so many things, I wouldn't be surprised if we had soon a systemd os running straight from the boot sector :p
On the other hand, maybe we should replace pid 1 with perl.
I've often thought it would be nifty to build a Unixlike system where there was only one binary (plus libraries and the linker) on the system, that binary was a script interpreter, and the whole system was implemented as scripts and script libraries (including an interactive one for the "shell".) There's no good reason to do it whatsoever since storage is relatively cheap now, and I have hobbies already.
use strict ðY£ (Score:1)
lol, people still use or care about this hideous language?!?
The worlds only write only language won't die (Score:1)
The worlds only write only language won't die. Nobody writing modern software uses it. Why do we care?
Re: (Score:2)
Re: (Score:2)
Clearly, no one is ever going to pay for that. If it hasn't happened by now, it will never never never happen, no, oh-oh-oh. The only way Slashdot is ever getting updated with Unicode support is if it's fully rewritten. Though honestly, how hard can it be to replicate this, uh, "fine" front end? Especially the classic view, which is the only one worth using anyway. Some site features no longer even function and/or were removed, like tagging, so you arguably don't have to implement them.
Needs Windows love (Score:2)
For example, I ran across a bug in which I couldn't open filenames with Chinese characters in Windows, but it was working well in Linux. After a lot of searching, I found out that it was already a known bug, but for some reason it was not being fixed.
Then there's also the fact that producing standalone executables in Windows is a big mess, too complicated and the result is big and slow.
Perl is excellent in Linux,
Corinna? What happened to Rakudo? (Score:1)
I thought Rakudo was "Perl 6.x"? Now we'll have yet another Perl?
About subroutine signatures... (Score:1)
With these signatures, you could assume that there was finally a way to simplify the passing of a parameter by reference (to be able to modify a variable passed as parameter). Well it's not even supported ! You can still use these old references of course, but nothing to simplify the over abundance of $ there ! :
Well they are between 10 and 20 years late on a feature like this already, even in perl6 (raku) they support this like that
sub inc(Int $x is rw) {
$x++;
}
and it's normal, it's one of th