Perl 7 is going to be Perl 5.32, mostly(perl.com)
perl.com
Perl 7 is going to be Perl 5.32, mostly
https://www.perl.com/article/announcing-perl-7/
574 comments
I loved Perl back in at the turn of the millennia. My first data science equivalent projects were in Perl.
To this day I can not find anything quicker to prototype in. Python is slow in comparison. Perl is great for quickly hacking something together for R&D purposes. Also, if you need to write something custom, Perl runs so much faster than Python and R.
I, like many people, stopped using Perl beyond a quick script in 2010. Not out of a lack of love. Perl was great. I wonder if your experience comes from being around the laggards, not so much Perl devs itself. When I was working in Perl no one around me was afraid of Javascript. Javascript and Perl are both C based. They aren't that different.
Your story is eye opening. It tells me what it would have been like if I had stuck around. I imagine working with the few who didn't want to learn new skills must have been more painful than you're letting on.
To this day I can not find anything quicker to prototype in. Python is slow in comparison. Perl is great for quickly hacking something together for R&D purposes. Also, if you need to write something custom, Perl runs so much faster than Python and R.
I, like many people, stopped using Perl beyond a quick script in 2010. Not out of a lack of love. Perl was great. I wonder if your experience comes from being around the laggards, not so much Perl devs itself. When I was working in Perl no one around me was afraid of Javascript. Javascript and Perl are both C based. They aren't that different.
Your story is eye opening. It tells me what it would have been like if I had stuck around. I imagine working with the few who didn't want to learn new skills must have been more painful than you're letting on.
I wrote a lot of popular web apps in Perl, some that appeared in NY Times and Time mag. I quit around 2010 and went over to php which is easier. Wrote a great app and built a successful software biz around it. I think 2010 may have been when Perl 6 felt hopeless and there was no clear leadership or direction in the community.
Mod_perl was the sh*t back in the late 90s for super high performance web apps on Apache. Then Perl stalled and everything else didn’t.
Perl could have been where Python is today if they didn’t take 20 years to waffle about a release that was supposed to do everything and ended up doing nothing because everyone left.
Mod_perl was the sh*t back in the late 90s for super high performance web apps on Apache. Then Perl stalled and everything else didn’t.
Perl could have been where Python is today if they didn’t take 20 years to waffle about a release that was supposed to do everything and ended up doing nothing because everyone left.
What's also forgotten is the Perl community's endless procrastination in adopting a meta-object protocol (MOP) and the too-late arrival of Miyagawa's brilliant contribution - PSGI/Plack. These 2 factors, I believe, led to Perl being overtaken by Rails, Django and the various PHP frameworks.
Perl’s lunch was eaten more by Ruby IMO. The bifurcation happened as the Perl programmers that wanted a more traditional OOP system picked up Ruby and the folks writing Bash++ oftentimes went to Python. These days it seems like Ruby is where Perl was in 2010.
These days it seems like Ruby is where Perl was in 2010
Unlike OP's experience with Perl, most legacy Ruby and/or Rails codebases are not too disasterous.
That's probably because Rails hits the sweet spot. It's just complex enough to support a medium-sized website well. Most innovations since Rails have targeted high-load websites.
mod_perl was dropped with the release of apache 2.4 in 2012 (that's a major release, apache is not semver). If I remember well, it was kicked out of the apache repo.
mod_python was also abandoned around the same time. It simply stopped being developed and stopped working (it's crashing on python 2.7).
Basically applications stop running inside apache memory with mod_xxx for good reasons (it's unstable and crashing both apache and the app). Languages moved to a FastCGI interface or to have a standalone web server.
mod_python was also abandoned around the same time. It simply stopped being developed and stopped working (it's crashing on python 2.7).
Basically applications stop running inside apache memory with mod_xxx for good reasons (it's unstable and crashing both apache and the app). Languages moved to a FastCGI interface or to have a standalone web server.
Do you mean faster to write, or faster to run, or the combination of both?
Both. Perl is around 20x slower than C for common tasks, while Python is around 133x slower than C for common tasks like looping, depending on what you're doing of course.
Perl is the ultimate mockup language in that you can crank out code very fast and get good bug free results. It lets you write in the way you think where other programming languages force you to write a specific way. Ofc you can get good at Python, so good at it you might get as fast as Perl. And Python is easier to read. The advantage of Perl, writing like you think, makes it difficult for anyone but you (or someone else who thinks like you) to read and maintain your code. The ugly code stereotype comes into play from this.
Perl isn't like Python. It's great if you want to write a one off script for doing quick analytics or a one off script that checks something on a server. It's fantastic for that. Python, you'd need to google around for a library, hope you find one, grab it, write a 100 lined file, and then finally be done, where Perl was a quick one-liner to do the same thing. Ofc the Perl is going to look like garbage and not be maintainable and the Python is going to look golden and be maintainable. They both fit a different need and different use case.
Perl is the ultimate mockup language in that you can crank out code very fast and get good bug free results. It lets you write in the way you think where other programming languages force you to write a specific way. Ofc you can get good at Python, so good at it you might get as fast as Perl. And Python is easier to read. The advantage of Perl, writing like you think, makes it difficult for anyone but you (or someone else who thinks like you) to read and maintain your code. The ugly code stereotype comes into play from this.
Perl isn't like Python. It's great if you want to write a one off script for doing quick analytics or a one off script that checks something on a server. It's fantastic for that. Python, you'd need to google around for a library, hope you find one, grab it, write a 100 lined file, and then finally be done, where Perl was a quick one-liner to do the same thing. Ofc the Perl is going to look like garbage and not be maintainable and the Python is going to look golden and be maintainable. They both fit a different need and different use case.
I don't think your performance numbers are very accurate. I've done a bit of Perl and a lot of Python and they're fairly comparable in most cases. Python is lightning fast for a lot of scripting tasks and I generally use very few libraries for day to day tasks because the Python stdlib is so good.
Unless you're doing something really simple with Perl command line switches that operate over an entire file, I'd bet Perl and Python solutions will be in the neighborhood of the same number of loc even with all the magic in Perl as Python has a lot of modern conveniences. It's easy to build a complex datastructure in Python with nested dictionaries with sets/lists/other dictionaries... whatever. In Perl it's more complex.
Unless you're doing something really simple with Perl command line switches that operate over an entire file, I'd bet Perl and Python solutions will be in the neighborhood of the same number of loc even with all the magic in Perl as Python has a lot of modern conveniences. It's easy to build a complex datastructure in Python with nested dictionaries with sets/lists/other dictionaries... whatever. In Perl it's more complex.
No, his estimates look pretty accurate to me. I've also done a fair bit of both Perl and Python (including working with the internals in C).
Perl is significantly faster than Python for many types of common string manipulation tasks. They're both fast, sure, but Perl has some key optimizations.
Perl is significantly faster than Python for many types of common string manipulation tasks. They're both fast, sure, but Perl has some key optimizations.
For maybe some regex tasks sure, but there are also plenty of Python operations that are significantly faster than Perl, not to even mention all the data science stuff. I might have misunderstood the comment as evaluating the language on one thing doesn't capture a broad/general spectrum of usefulness.
Every language in this category will have bindings to domain specific high performance modules. This is part of why performance doesn't matter all that much - we can always push hot operations into another language.
Perl generally outperforms python in core language features.
Perl generally outperforms python in core language features.
The benchmarks shown elsewhere here tend to disagree with that. I think at one point that was more true than it is now. Overall though they seem to be comparable enough to where it probably doesn't matter.
Also, the bindings have to exist which they don't with Perl for a lot of scientific uses (PDL is not a substitute for Numpy/SciPy/Pandas).
Don't get me wrong. I own at least 12 Perl books and have reviewed some of the latest Perl 6 (Raku) books and really really like Raku. There's not much wrong with Perl in my book (certainly not what most people claim). I've reached for it a few times at work and found it to be fairly pleasant to use. My biggest complaints about building complex data structures in Perl (yes it's much easier than C, but still complicated if you're coming from Python) and having to remember when something is "$" that in my mind should be "@" have all been fixed by Raku.
I just wanted to point out that your views about it being much faster across the board don't seem to be correct.
Also, the bindings have to exist which they don't with Perl for a lot of scientific uses (PDL is not a substitute for Numpy/SciPy/Pandas).
Don't get me wrong. I own at least 12 Perl books and have reviewed some of the latest Perl 6 (Raku) books and really really like Raku. There's not much wrong with Perl in my book (certainly not what most people claim). I've reached for it a few times at work and found it to be fairly pleasant to use. My biggest complaints about building complex data structures in Perl (yes it's much easier than C, but still complicated if you're coming from Python) and having to remember when something is "$" that in my mind should be "@" have all been fixed by Raku.
I just wanted to point out that your views about it being much faster across the board don't seem to be correct.
Any data to back up this claim? My experience in dealing with large numbers of files, huge data sets, is that Perl generally roars, while python lags. I converted a python code to Perl associated with some recent work, and got a good ~2.5x overall improvement. It varied a bit as a function of the input, but generally Perl is superior in performance. Some areas Python is better, but not many.
No, the numbers are pretty accurate. In most of the cases I've run into, Perl is faster than Python for its operations. Some trivial examples[1] showed up on HN a few weeks ago, about how this person "optimized" python, by eventually replacing python with C.
As for the nested complex data structures, Perl's been doing that forever (e.g. since 5.x started). And its trivial to use.
That's one of the nicer aspects of Perl. Things you think should work, often, just do. And work the way you want them to. It's not perfect. It is very, very good though.
[1] https://scalability.org/2020/05/on-optimizing-scripting-lang...
As for the nested complex data structures, Perl's been doing that forever (e.g. since 5.x started). And its trivial to use.
That's one of the nicer aspects of Perl. Things you think should work, often, just do. And work the way you want them to. It's not perfect. It is very, very good though.
[1] https://scalability.org/2020/05/on-optimizing-scripting-lang...
> I don't think your performance numbers are very accurate.
Food for thought.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Food for thought.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
So Python is faster than Perl on 6/10 benchmarks? This seems to support my argument that they are generally fairly comparable and definitely not that Perl is waaay faster.
More food for thought: https://bitbucket.org/ewanhiggs/csv-game/src/master/README.m...
> Ofc the Perl is going to look like garbage and not be maintainable
Please stop perpetuating this myth. It really depends how you write it. Perl isn't going to do the tidying up for you, you'll have to properly structure the code yourself. If you still write Perl code like it’s 1991 then maybe itcs not maintainable. I work on a largeish Perl code base and I can assure you it's quite maintainable, moreso than most Js that people install via npm as we speak.
Please stop perpetuating this myth. It really depends how you write it. Perl isn't going to do the tidying up for you, you'll have to properly structure the code yourself. If you still write Perl code like it’s 1991 then maybe itcs not maintainable. I work on a largeish Perl code base and I can assure you it's quite maintainable, moreso than most Js that people install via npm as we speak.
[deleted]
> If you still write Perl code like it’s 1991 then maybe itcs not maintainable.
This is probably one of the issues with Perl. You can still write Python code like it's 1991 and it will still be readable and maintainable.
This is probably one of the issues with Perl. You can still write Python code like it's 1991 and it will still be readable and maintainable.
no you cant, cuz 2.x python wont work in 3.x ;)
Fair enough, but note that the discussion topic is "writing xyz code like it's 1991", which doesn't exclude using a modern compiler.
Don't forget about PyPy, which may well be faster than Perl (I haven't compared them) or Cython if you're stuck with CPython.
That's a good point.
I tried googling around and couldn't find any speed comparisons between the languages, just talk between the two like eg https://news.ycombinator.com/item?id=8626131
So, I guess I'll address this directly:
The tasks Perl is designed to do are different than the kinds of tasks PyPy is designed to do, so it is a bit of apples an oranges comparison.
PyPy starts to get its speed benefit when a task takes 1) longer than 3 seconds to run and 2) Is directly written in Python, not using libraries written in C.
Perl is designed to parse large files, do string parsing, and one off scripts. It being fast is nice, but it's not designed to be running large math heavy processing scripts to begin with. If a Perl script takes longer than a second to run, not including IO limitations and network limitations, it may not be the ideal tool for the job.
So while PyPy gets comparable to Perl speeds, Perl being fast is almost moot, because it's not designed to be used that way to begin with.
I tried googling around and couldn't find any speed comparisons between the languages, just talk between the two like eg https://news.ycombinator.com/item?id=8626131
So, I guess I'll address this directly:
The tasks Perl is designed to do are different than the kinds of tasks PyPy is designed to do, so it is a bit of apples an oranges comparison.
PyPy starts to get its speed benefit when a task takes 1) longer than 3 seconds to run and 2) Is directly written in Python, not using libraries written in C.
Perl is designed to parse large files, do string parsing, and one off scripts. It being fast is nice, but it's not designed to be running large math heavy processing scripts to begin with. If a Perl script takes longer than a second to run, not including IO limitations and network limitations, it may not be the ideal tool for the job.
So while PyPy gets comparable to Perl speeds, Perl being fast is almost moot, because it's not designed to be used that way to begin with.
Both I would guess.
Perl in serial is already faster to run than Python, and as soon as you start using threads Perl blows Python straight out of the water. The only reason that stuff like tensorflow or numpy is not as dog slow as the rest of python is that they are bindings to c(++) or fortran libs.
Writing faster is debateable, but Perl has tons of niceties like embedded regex syntax, string interpolation, one-line if/unless that make Perl both more concise and less boilerplatey, which arguably also makes it faster to write.
There is also "faster to maintain". Perls compatibility means that there is almost none of the churn e.g. Python has with regard to syntax and semantics changes. Perl code from almost 3 decades ago usually works quite fine, whereas Python code breaks in every minor version upgrade and needs a complete rewrite for major versions
Perl in serial is already faster to run than Python, and as soon as you start using threads Perl blows Python straight out of the water. The only reason that stuff like tensorflow or numpy is not as dog slow as the rest of python is that they are bindings to c(++) or fortran libs.
Writing faster is debateable, but Perl has tons of niceties like embedded regex syntax, string interpolation, one-line if/unless that make Perl both more concise and less boilerplatey, which arguably also makes it faster to write.
There is also "faster to maintain". Perls compatibility means that there is almost none of the churn e.g. Python has with regard to syntax and semantics changes. Perl code from almost 3 decades ago usually works quite fine, whereas Python code breaks in every minor version upgrade and needs a complete rewrite for major versions
I've been writing Python for a good while now and I haven't seen too many issues between minor versions.
As for major versions...well...there's only been one significant change in this area (2 to 3) so I feel like maybe you're hyperbolizing a little :-)
As for major versions...well...there's only been one significant change in this area (2 to 3) so I feel like maybe you're hyperbolizing a little :-)
Python 3 was released in 2008, Python 2.7 had some kind of release last year but my memory is that up to about 2013 there was still a serious question of 2.7 vs 3 when you started a new project ("I know we should use 3, but then we can't have x-lib!").
So it happened once but it took up about 25% of the last 20 years.
So it happened once but it took up about 25% of the last 20 years.
A little. But there were changes from e.g. 2.5 to 2.7 and in the earlier 3.x versions that broke stuff. That never happened with Perl code here.
>Perl in serial is already faster to run than Python
Not it isn't.
>The only reason that stuff like tensorflow or numpy is not as dog slow as the rest of python is that they are bindings to c(++) or fortran libs.
So if I make a foo.py file and run the code, it runs faster. "but it's really c(++) or fortran!" doesn't matter in the slightest.
Not it isn't.
>The only reason that stuff like tensorflow or numpy is not as dog slow as the rest of python is that they are bindings to c(++) or fortran libs.
So if I make a foo.py file and run the code, it runs faster. "but it's really c(++) or fortran!" doesn't matter in the slightest.
I feel you. I'm currently at a startup that, somewhat by accident, ended up writing their backend in PHP.
Modern PHP is actually fine; it's largely avoided the issues perl has; adoption of the latest versions is quite high, and it's...fine. Not the best, not the worst, broadly comparable to other languages, and a far, far, far cry from what most people may think of when they hear "PHP". My last job used Node, the one before that used Python; I have personal preferences, but at the end of the day they're just tools, it's all fine. The "PHP: a fractal of bad design" blog post actually made a big impact on the community, and shocking number of the issues listed there have been solved, with rapid active progress ongoing. (Yes, I know, it still has issues, and people still hate it. No need to comment to let me know.)
And yet...
...there's a big chunk of the PHP community that just really isn't on board with any of this. Every time the core devs release a new language feature, vocal critics complain about how the language is becoming more "enterprisey" or "like Java". Even on the core dev team, when they vote about fixing some crazy broken feature of the language from the bad old days, a vocal minority is always against it. The language (thankfully) has not stayed still since 2002, but people are trying.
And of course, when we advertise to hire devs, if we say we're looking for "PHP devs", we end up flooded with applications from people who basically know how to install and configure plugins for PHP based CMSes, or from "senior devs" who have been hacking together procedural PHP scripts for 20+ years and have zero knowledge of software engineering principles, unit testing, etc. We've ended up hiring python devs to work on a php code base, not because no php devs are out there, but just because the community is so....weird. There are good engineers who happen to sometimes use PHP, but they rarely (if ever) identify as "PHP devs".
I dislike the JS ecosystem and it's constant churn and cult of the new, but sometimes you run across the reverse problem too.
Modern PHP is actually fine; it's largely avoided the issues perl has; adoption of the latest versions is quite high, and it's...fine. Not the best, not the worst, broadly comparable to other languages, and a far, far, far cry from what most people may think of when they hear "PHP". My last job used Node, the one before that used Python; I have personal preferences, but at the end of the day they're just tools, it's all fine. The "PHP: a fractal of bad design" blog post actually made a big impact on the community, and shocking number of the issues listed there have been solved, with rapid active progress ongoing. (Yes, I know, it still has issues, and people still hate it. No need to comment to let me know.)
And yet...
...there's a big chunk of the PHP community that just really isn't on board with any of this. Every time the core devs release a new language feature, vocal critics complain about how the language is becoming more "enterprisey" or "like Java". Even on the core dev team, when they vote about fixing some crazy broken feature of the language from the bad old days, a vocal minority is always against it. The language (thankfully) has not stayed still since 2002, but people are trying.
And of course, when we advertise to hire devs, if we say we're looking for "PHP devs", we end up flooded with applications from people who basically know how to install and configure plugins for PHP based CMSes, or from "senior devs" who have been hacking together procedural PHP scripts for 20+ years and have zero knowledge of software engineering principles, unit testing, etc. We've ended up hiring python devs to work on a php code base, not because no php devs are out there, but just because the community is so....weird. There are good engineers who happen to sometimes use PHP, but they rarely (if ever) identify as "PHP devs".
I dislike the JS ecosystem and it's constant churn and cult of the new, but sometimes you run across the reverse problem too.
I heard the "PHP is becoming like Java" argument in 2005 when PHP 5 came out. I'm surprised to hear it's still a thing.
Funny enough I heard the same thing about JavaScript about 5 years ago when ES6 came out.
Funny enough I heard the same thing about JavaScript about 5 years ago when ES6 came out.
> I'm surprised to hear it's still a thing.
Ha, if anything I think it's intensified. A current focus is on adding support for annotations (aka attributes from C#), which will be strictly opt-in and replace an ugly pattern currently widely used in PHP land of using docblocks to store them and then parsing them out at run time. "Hey, people keep storing these things in comments, lots of other languages have them as a real feature, let's do the same and make things saner and more efficient."
Simple right? But no, it's actually been quite controversial, and by no means just due to bikeshedding about syntax. Here's a selection of quotes (all highly upvoted) from a recent announcement on the PHP subreddit announcing that the feature has been accepted for PHP 8.0 and linking to a detailed document explaining the use case in painful detail:
"What problem is this trying to solve? I don’t think I’m a fan." "Not sure if I'm a fan. [...] IMO it got way out of hand in Java." "How about no? What does it solve that you can not already program with PHP. If other languages are any indication, its one of those changes that WILL get misused from here to high end." "yeah no thx"
Ha, if anything I think it's intensified. A current focus is on adding support for annotations (aka attributes from C#), which will be strictly opt-in and replace an ugly pattern currently widely used in PHP land of using docblocks to store them and then parsing them out at run time. "Hey, people keep storing these things in comments, lots of other languages have them as a real feature, let's do the same and make things saner and more efficient."
Simple right? But no, it's actually been quite controversial, and by no means just due to bikeshedding about syntax. Here's a selection of quotes (all highly upvoted) from a recent announcement on the PHP subreddit announcing that the feature has been accepted for PHP 8.0 and linking to a detailed document explaining the use case in painful detail:
"What problem is this trying to solve? I don’t think I’m a fan." "Not sure if I'm a fan. [...] IMO it got way out of hand in Java." "How about no? What does it solve that you can not already program with PHP. If other languages are any indication, its one of those changes that WILL get misused from here to high end." "yeah no thx"
Haha no. Php 5 has proper class definitions. Php 7 adds a spaceship operator, use declarations (yay Perl language features), return type declarations etc. Js was still prototype based the last time I've checked.
It was self inflicted damage.
PHP 5 felt like two distinct languages - PHP 4 and Java parts. PHP 4 was ok for its tasks, Java parts bolted on top, very unnatural, no continuation. In essence community was subverted. Other prominent examples - pulse audio and systemd. Compare it with Perls "bless" - looks so elegant and natural.
Some people do not buy that change, stick to origins and it makes sense. There was a conference talk "most programmers don't change their habits, wait until they die". It takes many years to burn and bury those who remember. It is said Moses wandered with his people for 40 years (until no those who were slaves left).
If Java was bolted on top of Ruby today I would not stay. At least because Java is better than Java bolted on Ruby.
You have valid point - stuck in the middle there is no way but forward, burn the past. They have point - someone destroyed the language they liked and you is one of them. No one shames bash scripts for lack of engineering principles, unit testing etc. Please do not disrespect them, it is not their fault.
PHP 5 felt like two distinct languages - PHP 4 and Java parts. PHP 4 was ok for its tasks, Java parts bolted on top, very unnatural, no continuation. In essence community was subverted. Other prominent examples - pulse audio and systemd. Compare it with Perls "bless" - looks so elegant and natural.
Some people do not buy that change, stick to origins and it makes sense. There was a conference talk "most programmers don't change their habits, wait until they die". It takes many years to burn and bury those who remember. It is said Moses wandered with his people for 40 years (until no those who were slaves left).
If Java was bolted on top of Ruby today I would not stay. At least because Java is better than Java bolted on Ruby.
You have valid point - stuck in the middle there is no way but forward, burn the past. They have point - someone destroyed the language they liked and you is one of them. No one shames bash scripts for lack of engineering principles, unit testing etc. Please do not disrespect them, it is not their fault.
Yeah a programming language can have such a positive momentum, but the community is also a thing. I think the currently popular programming languages have really healthy communities, go for linting, clean code and modern solutions.
I always avoided PHP but on one job I worked with it after the company was bought. So I had to maintain a billing script written in PHP to be called from the command line. It was running on a huge FreeBSD server that would fail booting oftentimes and in the script you had to change the start and end date each month manually. Of course there was no version control although I was told there was a second copy of that server in case this one failed completely. I wrote the guy (the then CTO) a few times emails with questions but he never responded. Eventually I ported the code to Go with unit tests. I get the point that there is PHP 7 with modern frameworks but those are useless without adopting modern coding and deployment practices.
I always avoided PHP but on one job I worked with it after the company was bought. So I had to maintain a billing script written in PHP to be called from the command line. It was running on a huge FreeBSD server that would fail booting oftentimes and in the script you had to change the start and end date each month manually. Of course there was no version control although I was told there was a second copy of that server in case this one failed completely. I wrote the guy (the then CTO) a few times emails with questions but he never responded. Eventually I ported the code to Go with unit tests. I get the point that there is PHP 7 with modern frameworks but those are useless without adopting modern coding and deployment practices.
My experience has been the opposite. I work in a PHP shop and with each new version update, a handful of us are excited about the new changes that get made to the language. Our DevOps team has been on top of keeping our servers running the latest production-ready versions of PHP. So many of the refinements are a welcome change. I'm eager for stronger type hinting and other features that are still coming down the pipe.
No, that's our experience too. We're excited by the changes, eager for each new release, and enjoy being able to write solid code without the language getting in the way (much). When 8.0 drops we'll probably have cake.
...the issue is the community, and (especially) the pool of applicants we get. It may be different where you are, but around here you advertise for a "senior backend dev", and you get a bunch of people with solid experience in, mostly, Python showing up, with maybe a sprinkling of .NET and Java. (Two of the biggest IT employers in town use Python, which skews things a bit, I know.) But you advertise for a "senior PHP dev", and you get all sorts, but (so far) no one we'd consider hiring. (Let me put it this way: The next time one of the "PHP devs" we shortlist turns out to have ever written a functioning unit test will be the first time. And these are people with years of experience, applying for a senior role...)
...the issue is the community, and (especially) the pool of applicants we get. It may be different where you are, but around here you advertise for a "senior backend dev", and you get a bunch of people with solid experience in, mostly, Python showing up, with maybe a sprinkling of .NET and Java. (Two of the biggest IT employers in town use Python, which skews things a bit, I know.) But you advertise for a "senior PHP dev", and you get all sorts, but (so far) no one we'd consider hiring. (Let me put it this way: The next time one of the "PHP devs" we shortlist turns out to have ever written a functioning unit test will be the first time. And these are people with years of experience, applying for a senior role...)
> it is not the notorious "write only" language that many troll it to be
I dispute that.
I have worked with many languages, and Perl has always been one of the hardest to remember due to non-standard symbol abuse and a few strange semantics.
There is a reason it has that reputation.
Even writing it isn’t easy. I can describe the Python syntax after years of not using it. Perl? No way I remember it.
I dispute that.
I have worked with many languages, and Perl has always been one of the hardest to remember due to non-standard symbol abuse and a few strange semantics.
There is a reason it has that reputation.
Even writing it isn’t easy. I can describe the Python syntax after years of not using it. Perl? No way I remember it.
Understood. I stated that to say my problems with perl is not the language itself. To say it is the "community" is not right either. But basically "what is left of the community" is the issue. Languages like python, ruby, perl, etc are only good (if you want to freelance and make money at least) at being a "skin" around a database. That also entails a knowledge of frontend frameworks and workflows as well. Yet the words "database", "javascript", or "webpack" are very rarely mentioned at any of the perl conferences in the last 5 years! In the case of webpack, that's probably never been mentioned.
Well, I've given talks on databases (Postgres), javascript (vue) and modern devops (k8s etc) at various Perl conferences in the last years, so I cannot agree.
In fact, I'm giving a small talk on Docker today at the Perl Conference in the Cloud, and also a lightning talk about a ~50 line tool to provide an async web server to post to Matrix. https://tpc20cic.sched.com/
Yes, there are a few people entrenched in old ways (and sometimes it pays off to not always use the newest tech), but there are also a lof of Perl devs doing current stuff.
In fact, I'm giving a small talk on Docker today at the Perl Conference in the Cloud, and also a lightning talk about a ~50 line tool to provide an async web server to post to Matrix. https://tpc20cic.sched.com/
Yes, there are a few people entrenched in old ways (and sometimes it pays off to not always use the newest tech), but there are also a lof of Perl devs doing current stuff.
> I have worked with many languages, and Perl has always been one of the hardest to remember due to non-standard symbol abuse and a few strange semantics.
For example?
For example?
I mean, the combinations of $%@ are really astoundingly bad. $ alone has so many different meanings and operations depending on context. You won't find that sort of thing in any other language. Not even PHP which for some bizarre reason brought $ along for the ride.
Here's a fun exercise, write a dictionary of arrays. Now write a dictionary of 2d arrays.
In any other language, that's hardly a challenge to both read and write such a structure. Not so with perl.
Here's a fun exercise, write a dictionary of arrays. Now write a dictionary of 2d arrays.
In any other language, that's hardly a challenge to both read and write such a structure. Not so with perl.
> Here's a fun exercise, write a dictionary of arrays.
Umm … ok:
my %dict = ( foo => [ 1, 2, 3 ], bar => [ 4, 5, 6 ], );
> Now write a dictionary of 2d arrays.
my %dict2d = ( foo => [ [1, 2, 3], [4, 5, 6] ], bar => [], );
It’s pretty much identical to JS. Not sure how that’s supposed to exemplify how hard it is to write Perl.
Umm … ok:
my %dict = ( foo => [ 1, 2, 3 ], bar => [ 4, 5, 6 ], );
> Now write a dictionary of 2d arrays.
my %dict2d = ( foo => [ [1, 2, 3], [4, 5, 6] ], bar => [], );
It’s pretty much identical to JS. Not sure how that’s supposed to exemplify how hard it is to write Perl.
I'm not the original comment author, neither am I fluent in Perl. But I suspect they meant nested hashes and not a hash whose values are arrays of arrays. As you point out, the latter is trivial.
To be clear, even a nested hash is all well as long as the depth and the keys are literals (as in your example). It is when keys are dynamic that things get unruly. And god forbid if the _depth_ of nesting is dynamic. All of these are trivial to implement in Python, Ruby, JS, PHP, ...
To be clear, even a nested hash is all well as long as the depth and the keys are literals (as in your example). It is when keys are dynamic that things get unruly. And god forbid if the _depth_ of nesting is dynamic. All of these are trivial to implement in Python, Ruby, JS, PHP, ...
%nested = (foo => { bar => { baz => "quux" } });
$nested->{foo}{bar}{baz}
$nested->{$x}{$y}{$z}
This is why we use strict! The extra arrow is unneeded, as you're working on the actual hash, not a reference to the hash. This is a compiler error with use strict though, so it's not something you would generally be bitten with when writing real code, just internet comments. :)
Whoops, good catch! I had references on the brain. For completeness, that makes it either
$nested{$x}{$y}{$z}
$nested = { … };
I think the point is not that Perl's rules don't make sense -- it's that they're much less obvious than those in many competing languages. In Python, lists are `l = [1, 2, 3]` and dicts are `d = {"key": val}`. Both structures can be nested without any change to the semantics.
> $ alone has so many different meanings and operations depending on context.
Used as a sigil, $ always tags a scalar, a single value.
Dereferencing a reference to scalar is rarely used and looks like either
Of those, the kinda fuzzy one is $ inside a regex. The rest follow consistent, simple rules. I’m not sure what you mean by different operations on $. Am I skipping a difficult case you have in mind?
Used as a sigil, $ always tags a scalar, a single value.
$foo = 3;
$bar = [qw/ apple orange banana /];
Dereferencing a reference to scalar is rarely used and looks like either
$$baz = $quux;
${$baz} = $quux;
Of those, the kinda fuzzy one is $ inside a regex. The rest follow consistent, simple rules. I’m not sure what you mean by different operations on $. Am I skipping a difficult case you have in mind?
I think shells did $ for vars first, then Perl added @ and % for arrays and hashes (and then $ was refs)
> I mean, the combinations of $%@ are really astoundingly bad. $ alone has so many different meanings and operations depending on context. You won't find that sort of thing in any other language.
I kind of felt lost first getting started with Scala where I felt like there was symbol overload.
I kind of felt lost first getting started with Scala where I felt like there was symbol overload.
A classic (hope I didn't get it wrong):
print "[", +( join '', map { "-> $_" } @$_ ), "]" for @{$ref}The concatenation operator is . in Perl and ~ in Raku. You could write a normal, braced foreach loop with another one inside and not use $_.
> print "[", +( join '', map { "-> $_" } @$_ ), "]" for @{$ref}
Because computers are so slow, memory is so limited and disk space is so expensive the programmer absolutely had to write it in a single line in the most convoluted way possible? Yeah, that's definitely a language fault.
Because computers are so slow, memory is so limited and disk space is so expensive the programmer absolutely had to write it in a single line in the most convoluted way possible? Yeah, that's definitely a language fault.
This is pretty idiomatic Perl, and I've seen similar constructs countless times at work. You could indent the map body but it normally wouldn't be done for such a short expression. There is not much room for maneuver there if you don't want intermediate variables.
And this is a quick sample, there is much, much hairier stuff to be found in real code. "Knowing the language well" is seen as a virtue for many.
And this is a quick sample, there is much, much hairier stuff to be found in real code. "Knowing the language well" is seen as a virtue for many.
The problem is that it takes a lot of skill to write elegant Perl. The easy way is the one that produces write-only crap.
The problem with any language like this is that you have to work with others, and if others produce write only code that's your problem, too.
> perl has been the same since 2002
if you ignore perl 6 then you might as well ignore python 3. And even still, python 2 is dead. There are only a handful of languages as well maintained as Perl 5.
https://en.wikipedia.org/wiki/Perl_5_version_history
Perl maintains strict backwards compatibility. I can run code that was written decades ago. I really am curious what features you think Perl 5 lacks.
> Another issue is just the bit rot of cpan.
Sure. But NPM exists. There is unmaintained JS code that was created only 6 months ago. Github is littered with orphaned garbage. I could probably find a dozen or so packages within my company's node_modules folder. Perl is less used today so of course the packages are outdated. But in terms of purely giving a crap... no one gives a crap about NPM. No one. It's largely abandonware on the day it's created. I never really found that sentiment to be the case with CPAN. You had to make an effort to get a package out there. The care people put into packages like DBI was incredible, compared to anything I've seen on NPM.
I don't use Perl much these days. But the hate it gets on HN is insane. It's had a lot of what people consider "modern" features as far back as the 1990s. I really haven't seen a single thing Python, Ruby, or PHP have done that much better.
if you ignore perl 6 then you might as well ignore python 3. And even still, python 2 is dead. There are only a handful of languages as well maintained as Perl 5.
https://en.wikipedia.org/wiki/Perl_5_version_history
Perl maintains strict backwards compatibility. I can run code that was written decades ago. I really am curious what features you think Perl 5 lacks.
> Another issue is just the bit rot of cpan.
Sure. But NPM exists. There is unmaintained JS code that was created only 6 months ago. Github is littered with orphaned garbage. I could probably find a dozen or so packages within my company's node_modules folder. Perl is less used today so of course the packages are outdated. But in terms of purely giving a crap... no one gives a crap about NPM. No one. It's largely abandonware on the day it's created. I never really found that sentiment to be the case with CPAN. You had to make an effort to get a package out there. The care people put into packages like DBI was incredible, compared to anything I've seen on NPM.
I don't use Perl much these days. But the hate it gets on HN is insane. It's had a lot of what people consider "modern" features as far back as the 1990s. I really haven't seen a single thing Python, Ruby, or PHP have done that much better.
I haven't seen that much hate for Perl on HN. I personally used it for quite a while and liked it a lot. But I think it's reasonable to consider it a legacy language these days, next to Fortran, Ada and TCL.
Are these languages still used in some niches? Certainly, TCL is still big for scripting ASIC/FPGA design tools last I checked. Similarly Perl projects will still be used and maintained for a long time, it may well outlive us all.
But it's very hard to defend using Perl on a new project these days. I know I wouldn't. I have very little love for Python but I'd go with it instead of Perl almost every single time now. There was a time where CPAN was the killer feature of Perl. Now Python caught up while, as the parent points out, CPAN is slowly rotting due to unmaintained packages. NPM being a mountain of trash is entirely irrelevant frankly. And it's not like in its heydays every single CPAN package was a marvel of software engineering either.
>The care people put into packages like DBI was incredible, compared to anything I've seen on NPM.
See, even you use the past tense. There's no argument that DBI is great. That's not the point. Languages survive not because they're good or bad, but because they have community and corporate support. That's why PHP holds up pretty well while Perl slowly falls into irrelevance. We can lament it, we can try to fight it, but can't deny it.
Are these languages still used in some niches? Certainly, TCL is still big for scripting ASIC/FPGA design tools last I checked. Similarly Perl projects will still be used and maintained for a long time, it may well outlive us all.
But it's very hard to defend using Perl on a new project these days. I know I wouldn't. I have very little love for Python but I'd go with it instead of Perl almost every single time now. There was a time where CPAN was the killer feature of Perl. Now Python caught up while, as the parent points out, CPAN is slowly rotting due to unmaintained packages. NPM being a mountain of trash is entirely irrelevant frankly. And it's not like in its heydays every single CPAN package was a marvel of software engineering either.
>The care people put into packages like DBI was incredible, compared to anything I've seen on NPM.
See, even you use the past tense. There's no argument that DBI is great. That's not the point. Languages survive not because they're good or bad, but because they have community and corporate support. That's why PHP holds up pretty well while Perl slowly falls into irrelevance. We can lament it, we can try to fight it, but can't deny it.
Tcl is (last I knew) still remarkably big on “the edges” of networks: f5/a10 devices (iRules scripting[0]), used to be (is it still?) used for Cisco iOS scripting[1], was used as the glue language for Tealeaf session/network capture[2] (when it was deployed as on-premises installation ), and control language for Argonne National Lab cluster control[3]...
[0] https://devcentral.f5.com/s/articles/irules-concepts-tcl-the...
[1] https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ios_tcl/co...
[2] https://help.goacoustic.com/hc/en-us/articles/360043736414-P...
[3] https://www.mcs.anl.gov/~wozniak/papers/Swift_Tcl_2015.pdf
[0] https://devcentral.f5.com/s/articles/irules-concepts-tcl-the...
[1] https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ios_tcl/co...
[2] https://help.goacoustic.com/hc/en-us/articles/360043736414-P...
[3] https://www.mcs.anl.gov/~wozniak/papers/Swift_Tcl_2015.pdf
Also heavily used in banking and trading systems (Fidessa).
Also heavily used in software testing, including DejaGnu for Linux binutils.
[deleted]
[deleted]
> Perl maintains strict backwards compatibility. I can run code that was written decades ago.
I used to spout that off too, but I now think it is just a myth. When the leader/creator of the language abandons it and it sits there stagnate for years, what other "feature" can you advertise? I know, "strict compatibility"! I saw it as a feature as well and even used it as an excuse to not learn python.
But even worse it has tainted an entire generation of small business perl dev shops. They seem to think that they can't move to another language because every couple of years back compatibility in language X breaks and at the same time spout off how their perl CGI scripts from 1998 still work fine ("fine" because it hasn't been hacked yet). Ironically doing this all from their windows laptop that has broken compatibility through many release cycles.
Breaking compatibility and refactoring is a sign of health, not death! But now these old school dev shops have large customer bases on old perl who's customers are not used to paying for any kind "upgrade" (and now they never will be). Contrast that with every now and then on /r/django someone will post a question like "my development firm is wanting to charge me $3k to upgrade from django 1.2 to 2.0 before they will add any new features to my web shop. Is that a good deal?". Its just a fact of life now. Software needs to be upgraded. The only reason that perl apps aren't at the top of all security and sql injection attacks is because there are so few of them (combined with the fact that so much of "perl apps" are custom code from the ground up). Never upgrading your stuff is not a "feature".
It's the same with python 2.7 as well. That is because it is dead, it now has "strict compatibility"!
> I really am curious what features you think Perl 5 lacks.
That's a good question. Really, perl can do anything that python can. So what gives? I think the biggest thing that I struggle with just goes back to the "community". I'm trying to stay brief as not to out myself or my last company, but in most cases I was given requirements for a new project and I was off on my own. That's fine. But sometimes I'd be given requirements for a new project and then get micromanaged. As in literally told how to organize the entire project down to little bits like "when a user registers a new account, a function will return a random string 6 characters long and be sent via email to the user and this password will be stored in clear text". That is not the exact case, the real case belongs on codinghorror.com.
But the point I make is given requirements that break normal sane patterns, in python I could go to a mailing list or /r/python and post my issue and expect plenty of answers that I could then show my boss that he is not right. That does not exist in the perl world. I'm sure some perl guys will try to chime in and disagree but it is true. I have asked several question on /r/perl to get advice on really stupid architectural requirements but got 0 responses. The same goes for the perl mailing lists and irc. Its all dead. Many times I've posted to python lists pretending to be making a flask app or something just to get some advice on some webdev best practices, etc, not easy questions but just looking for a discussion. It's embarrassing on the perl side.
I used to spout that off too, but I now think it is just a myth. When the leader/creator of the language abandons it and it sits there stagnate for years, what other "feature" can you advertise? I know, "strict compatibility"! I saw it as a feature as well and even used it as an excuse to not learn python.
But even worse it has tainted an entire generation of small business perl dev shops. They seem to think that they can't move to another language because every couple of years back compatibility in language X breaks and at the same time spout off how their perl CGI scripts from 1998 still work fine ("fine" because it hasn't been hacked yet). Ironically doing this all from their windows laptop that has broken compatibility through many release cycles.
Breaking compatibility and refactoring is a sign of health, not death! But now these old school dev shops have large customer bases on old perl who's customers are not used to paying for any kind "upgrade" (and now they never will be). Contrast that with every now and then on /r/django someone will post a question like "my development firm is wanting to charge me $3k to upgrade from django 1.2 to 2.0 before they will add any new features to my web shop. Is that a good deal?". Its just a fact of life now. Software needs to be upgraded. The only reason that perl apps aren't at the top of all security and sql injection attacks is because there are so few of them (combined with the fact that so much of "perl apps" are custom code from the ground up). Never upgrading your stuff is not a "feature".
It's the same with python 2.7 as well. That is because it is dead, it now has "strict compatibility"!
> I really am curious what features you think Perl 5 lacks.
That's a good question. Really, perl can do anything that python can. So what gives? I think the biggest thing that I struggle with just goes back to the "community". I'm trying to stay brief as not to out myself or my last company, but in most cases I was given requirements for a new project and I was off on my own. That's fine. But sometimes I'd be given requirements for a new project and then get micromanaged. As in literally told how to organize the entire project down to little bits like "when a user registers a new account, a function will return a random string 6 characters long and be sent via email to the user and this password will be stored in clear text". That is not the exact case, the real case belongs on codinghorror.com.
But the point I make is given requirements that break normal sane patterns, in python I could go to a mailing list or /r/python and post my issue and expect plenty of answers that I could then show my boss that he is not right. That does not exist in the perl world. I'm sure some perl guys will try to chime in and disagree but it is true. I have asked several question on /r/perl to get advice on really stupid architectural requirements but got 0 responses. The same goes for the perl mailing lists and irc. Its all dead. Many times I've posted to python lists pretending to be making a flask app or something just to get some advice on some webdev best practices, etc, not easy questions but just looking for a discussion. It's embarrassing on the perl side.
> Breaking compatibility and refactoring is a sign of health, not death!
That is entirely dependent on what type of project it is, and what it's used for. Software that is not getting new features added and expected to work as it was and maybe get the occasional bug fix has no need for refactoring, and refactoring is almost definitely going to be detrimental before it possibly yields benefits.
A simple example of this is core Unix utilities, firmware, etc. When the scope is kept small, and the engineering is done well, those just work, and are expected to keep working. People aren't clamoring to refactor cp and mv. It is harder to keep these constraints sane as the code and project increases in size though.
Now, the ability to somewhat safely refactor is a sign of health, because it means there's high understanding of the scope of the code/project, and well known ways to test. That's a far cry from actually doing so, and I think you would be hard pressed to find a project that was undergoing a major refactor and breaking compatibility that I would look at and say "oh, they must be so healthy, because that's what healthy projects do, break backwards compatibility and refactor." The only reason to actually take on those tasks is because you have problems you think can't be fixes without them, which is not an indicator of healthiness.
> The only reason that perl apps aren't at the top of all security and sql injection attacks is because there are so few of them (combined with the fact that so much of "perl apps" are custom code from the ground up). Never upgrading your stuff is not a "feature".
Just because your experience is web apps doesn't mean that's all there is. Do user facing applications that process user input need a lot of updates to make sure they stay in-line with security needs? Yes. Is all software user facing? Does all software need to support something as complex as a browser? No. Different classes of software have different classes of requirements. Does "it will still run on a new interpreter 20 years later" sound interesting to someone doing web development? Probably not. Does it sound interesting to people running system software, that often pay hundreds of dollars per system just so they can run an OS that back-patches security problems so they have a stable running environment with minimal change for 5+ years at a time? Hell yes it does.
But that's okay, you want current, modern Perl web apps? Use Mojolicious. It has a well defined deprecation policy, and you're forced to update your code if you stay up to date with it and be secure, just as you would expect from any Modern web app that takes things seriously (because some problems well be architectural, and may require user changes to fully accommodate).
> But the point I make is given requirements that break normal sane patterns, in python I could go to a mailing list or /r/python and post my issue and expect plenty of answers that I could then show my boss that he is not right. That does not exist in the perl world.
I'm not really sure what this has to do with Perl or Python. This is security, systems, and web best practices, and the language is irrelevant to the example. You shouldn't need to go to /r/python to tell your boss that storing a password in plain text and with bad requirements for users is bad practice. Sure, it might work, but I think it's more indicative of cargo-cult behavior, and spreading it. If I'm building a Perl app, or a Haskell app, or Rust app, I should be able to pop into /r/python or anywhere else I expect someone might be around with experience, ask about best practices, and get a response that is not couched in "we just do X in flak/django whatever". If someone isn't explaining why storing passwords in plain text is bad, then they aren't really giving a good answer.
> The same goes for the perl mailing lists and irc. Its all dead.
That's now my experience. I don't bother going to IRC often, but I get helped whenever I do. IRC still seems to be the preferred medium for Perl devs to congregate and communicate. Not much else I can say about this, you didn't really provide much info other than it didn't help you and there's nobody there to help you, and my experience is different.
That is entirely dependent on what type of project it is, and what it's used for. Software that is not getting new features added and expected to work as it was and maybe get the occasional bug fix has no need for refactoring, and refactoring is almost definitely going to be detrimental before it possibly yields benefits.
A simple example of this is core Unix utilities, firmware, etc. When the scope is kept small, and the engineering is done well, those just work, and are expected to keep working. People aren't clamoring to refactor cp and mv. It is harder to keep these constraints sane as the code and project increases in size though.
Now, the ability to somewhat safely refactor is a sign of health, because it means there's high understanding of the scope of the code/project, and well known ways to test. That's a far cry from actually doing so, and I think you would be hard pressed to find a project that was undergoing a major refactor and breaking compatibility that I would look at and say "oh, they must be so healthy, because that's what healthy projects do, break backwards compatibility and refactor." The only reason to actually take on those tasks is because you have problems you think can't be fixes without them, which is not an indicator of healthiness.
> The only reason that perl apps aren't at the top of all security and sql injection attacks is because there are so few of them (combined with the fact that so much of "perl apps" are custom code from the ground up). Never upgrading your stuff is not a "feature".
Just because your experience is web apps doesn't mean that's all there is. Do user facing applications that process user input need a lot of updates to make sure they stay in-line with security needs? Yes. Is all software user facing? Does all software need to support something as complex as a browser? No. Different classes of software have different classes of requirements. Does "it will still run on a new interpreter 20 years later" sound interesting to someone doing web development? Probably not. Does it sound interesting to people running system software, that often pay hundreds of dollars per system just so they can run an OS that back-patches security problems so they have a stable running environment with minimal change for 5+ years at a time? Hell yes it does.
But that's okay, you want current, modern Perl web apps? Use Mojolicious. It has a well defined deprecation policy, and you're forced to update your code if you stay up to date with it and be secure, just as you would expect from any Modern web app that takes things seriously (because some problems well be architectural, and may require user changes to fully accommodate).
> But the point I make is given requirements that break normal sane patterns, in python I could go to a mailing list or /r/python and post my issue and expect plenty of answers that I could then show my boss that he is not right. That does not exist in the perl world.
I'm not really sure what this has to do with Perl or Python. This is security, systems, and web best practices, and the language is irrelevant to the example. You shouldn't need to go to /r/python to tell your boss that storing a password in plain text and with bad requirements for users is bad practice. Sure, it might work, but I think it's more indicative of cargo-cult behavior, and spreading it. If I'm building a Perl app, or a Haskell app, or Rust app, I should be able to pop into /r/python or anywhere else I expect someone might be around with experience, ask about best practices, and get a response that is not couched in "we just do X in flak/django whatever". If someone isn't explaining why storing passwords in plain text is bad, then they aren't really giving a good answer.
> The same goes for the perl mailing lists and irc. Its all dead.
That's now my experience. I don't bother going to IRC often, but I get helped whenever I do. IRC still seems to be the preferred medium for Perl devs to congregate and communicate. Not much else I can say about this, you didn't really provide much info other than it didn't help you and there's nobody there to help you, and my experience is different.
There are a lot of modules and historical code stuck in old paradigms, but those are useful in their own way for backwards compatibility. There's also newer Perl modules that see heavy use, like Type::Tiny, Mojolicious, etc. We do a lot of internal web-apps with Mojolicious at work, and our larger ones make heavy uses of websockets, async code, and in some cases Vue.js.
> The ORM and drivers for both postgresql and sqlite don't even support most of the features added in those systems since 2014.
The popular ORMs for Perl (DBIx::Class, etc) are fairly DB agnostic, so work with Postgres, MySQL, MSSQL, Oracle, etc. You aren't likely to see specific features for one DB in them because of that. What you gain is a consistent and advanced interface for interacting with databases which is mostly the same regardless of the back-end for that project.
There are newer, specialized modules such as Pg or Mojo::Pg to give you specific Postgres capabilities or to enable a more asynchronous model if that's what you're looking for.
Sounds like you had some bad experiences, and that sucks. Nobody will blame you for "jumping ship", but I would suggest you not think of it necessarily like that. You learn and code what you have to for work, and you learn and you code what you feel like or you think gives the most benefit personally. Those naturally change over time for a lot of people, and sometimes they are the same sets of items, and sometimes they aren't. If you ever want to play around with Perl again, even just for fun, it's there for you. It's not going anywhere. Perl doesn't have to be the language you write to make a living, or even the first one you reach for for certain projects, but it might still be a good option for some things, and there's no reason to discount it entirely if you still know how to use it and can find a use case for it.
For example, even if I stop using Perl primarily for development, I'm pretty sure it's going to be the tool I reach for when I need to quickly process some data for the foreseeable future. Just the fact I can pull in anything from CPAN to supplement a one-liner (or a one liner I've copied into a file and formatted to turn into a small script) makes it invaluable over just awk and sed.
> The ORM and drivers for both postgresql and sqlite don't even support most of the features added in those systems since 2014.
The popular ORMs for Perl (DBIx::Class, etc) are fairly DB agnostic, so work with Postgres, MySQL, MSSQL, Oracle, etc. You aren't likely to see specific features for one DB in them because of that. What you gain is a consistent and advanced interface for interacting with databases which is mostly the same regardless of the back-end for that project.
There are newer, specialized modules such as Pg or Mojo::Pg to give you specific Postgres capabilities or to enable a more asynchronous model if that's what you're looking for.
Sounds like you had some bad experiences, and that sucks. Nobody will blame you for "jumping ship", but I would suggest you not think of it necessarily like that. You learn and code what you have to for work, and you learn and you code what you feel like or you think gives the most benefit personally. Those naturally change over time for a lot of people, and sometimes they are the same sets of items, and sometimes they aren't. If you ever want to play around with Perl again, even just for fun, it's there for you. It's not going anywhere. Perl doesn't have to be the language you write to make a living, or even the first one you reach for for certain projects, but it might still be a good option for some things, and there's no reason to discount it entirely if you still know how to use it and can find a use case for it.
For example, even if I stop using Perl primarily for development, I'm pretty sure it's going to be the tool I reach for when I need to quickly process some data for the foreseeable future. Just the fact I can pull in anything from CPAN to supplement a one-liner (or a one liner I've copied into a file and formatted to turn into a small script) makes it invaluable over just awk and sed.
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 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
> A few years later one of the newer employees on the customer support team started spouting off about "python" and how it was so easy to learn. He was always blabbing about terms I'd never heard of like "generators", "list comprehensions", "decorators", etc. I looked them up and learned they were just abstract constructs with fancy names that are supported in most any language. So I just figured he was some idiot that didn't really know anything. Otherwise, why would you be blabbing about abstract constructs?
> I can understand how a 50 year old perl dev (the typical age) would hate javascript and instead put as much code in the back end using all kinds of horrid html templates and never ending form post/refresh/repopulate cycles... I can see the "why should I learn javascript if i know perl" ideology, but what blew me away is a constant "why should I learn SQL if I know perl" ideology. Yes I'm serious.
You don't see how this is the same thing?
> I can understand how a 50 year old perl dev (the typical age) would hate javascript and instead put as much code in the back end using all kinds of horrid html templates and never ending form post/refresh/repopulate cycles... I can see the "why should I learn javascript if i know perl" ideology, but what blew me away is a constant "why should I learn SQL if I know perl" ideology. Yes I'm serious.
You don't see how this is the same thing?
Not to speak for the OP, but I'm pretty sure that was the point -- he was making fun of himself, especially when he noted that the guy quickly moved on to Google and he himself later started working in Javascript!
> You don't see how this is the same thing?
No.. but feel free to explain.
With my friend that left for google, I was annoyed at him somehow thinking python was advanced just because he was using stuff you could do in any language only he thought more highly of it because of the names. He saw the light of having a clean syntax, I did not, but now I do.
If you look at the history of python, it is an "engineered" language. It was based off of ABC which was a product of a large team of engineers in the early 1980's. Also some of Modula-3 as well. ABC was based off of ALGOL 68 and Pascal. The point is, a lot of money flowed into the design of these languages and python borrowed largely off of that base.
I used to know perl's history quite well, but I'm fuzzy on that now (and stopped caring). I know Larry was quite skilled at whipping up compilers and parsers from scratch, and he was heavily involved in linguistics, but I feel he sort of just did his own thing. The reason to make perl6 in the first place was to make a "proper" language. All of the lexer and parser code in perl5 are purely custom and intertwined. There's no way to change the parser or add an AST without just starting from scratch. That is what perl6 tried to do. But with python, these steps were from the beginning in proper "layers" and that helped the language to evolve with the times better as well as just having a cleaner VM source code which was easier to work on (the trade off being it was slower than perl in many cases).
The end result is python is "syntax with training wheels", you can't deviate too far before it fails to compile. While perl will compile just about anything as long as your semi-colons aren't missing. For me that made python harder to learn. You couldn't just write anything and expect it to work. For me, I looked at the python docs a lot more than perl docs when learning it. There's no reason why you can't do while y = t.pop: ... in python other than it won't let you. That was something that made me put it off for a long time as it felt it was just full of more rules than syntax. I see the light now though. But the point of my rant here is not that python is beautiful code (which I've always found as an annoying "advantage"), but that the perl community it self if just out of touch with what the current market wants (and needs). And that was the point about the 50 year old perl dev I was making. You can certainly code like it is 1995, but it is not what most people want to pay for (and it certainly is not something we need more of).
No.. but feel free to explain.
With my friend that left for google, I was annoyed at him somehow thinking python was advanced just because he was using stuff you could do in any language only he thought more highly of it because of the names. He saw the light of having a clean syntax, I did not, but now I do.
If you look at the history of python, it is an "engineered" language. It was based off of ABC which was a product of a large team of engineers in the early 1980's. Also some of Modula-3 as well. ABC was based off of ALGOL 68 and Pascal. The point is, a lot of money flowed into the design of these languages and python borrowed largely off of that base.
I used to know perl's history quite well, but I'm fuzzy on that now (and stopped caring). I know Larry was quite skilled at whipping up compilers and parsers from scratch, and he was heavily involved in linguistics, but I feel he sort of just did his own thing. The reason to make perl6 in the first place was to make a "proper" language. All of the lexer and parser code in perl5 are purely custom and intertwined. There's no way to change the parser or add an AST without just starting from scratch. That is what perl6 tried to do. But with python, these steps were from the beginning in proper "layers" and that helped the language to evolve with the times better as well as just having a cleaner VM source code which was easier to work on (the trade off being it was slower than perl in many cases).
The end result is python is "syntax with training wheels", you can't deviate too far before it fails to compile. While perl will compile just about anything as long as your semi-colons aren't missing. For me that made python harder to learn. You couldn't just write anything and expect it to work. For me, I looked at the python docs a lot more than perl docs when learning it. There's no reason why you can't do while y = t.pop: ... in python other than it won't let you. That was something that made me put it off for a long time as it felt it was just full of more rules than syntax. I see the light now though. But the point of my rant here is not that python is beautiful code (which I've always found as an annoying "advantage"), but that the perl community it self if just out of touch with what the current market wants (and needs). And that was the point about the 50 year old perl dev I was making. You can certainly code like it is 1995, but it is not what most people want to pay for (and it certainly is not something we need more of).
> All of the lexer and parser code in perl5 are purely custom and intertwined.
I had given myself a torture by taking a look at perl5/toke.c [1]. Among dozens of lexical analyzers I've ever seen, it is the only tokenizer that uses a probablistic estimator to determine the extent of the current token (grep for the comment "this is terrifying, and it works"). Perl 5 is my go-to language for counterexamples in programming language grammers and syntaxes.
[1] https://github.com/Perl/perl5/blob/blead/toke.c
I had given myself a torture by taking a look at perl5/toke.c [1]. Among dozens of lexical analyzers I've ever seen, it is the only tokenizer that uses a probablistic estimator to determine the extent of the current token (grep for the comment "this is terrifying, and it works"). Perl 5 is my go-to language for counterexamples in programming language grammers and syntaxes.
[1] https://github.com/Perl/perl5/blob/blead/toke.c
Oh and I forgot to also say when comparing the languages, you have to also look at the authors too. Guido from the get go was more of a "software engineer" type whereas Larry seemed to be more involved in sysadmin and/or systems programming. I think the languages show that as well.
Pythons "there is only way" is too stiff for me. It may sound nice but in reality does not work, on top of my head - package managers, slots, itertools vs array comprehension, discouraged lambda, and whole python 2 or 3.
A sample of Google Python code I've tried to fix recently [1]. A ton of nothingness. You can produce it in any language.
You are too harsh on Perl design. I thought ruby was popular because it is great language. Nope. Cool kids moved to server side JavaScript. And tried to hide prototype oriented origins, they've added class friends privates now and a ton of other questionable features.
It is all about version 5 dead. I've red Perl 6 Apocalypses, I'd ship. Too bad there was no smooth transition path.
[1] https://github.com/GoogleCloudPlatform/gsutil/blob/master/gs...
A sample of Google Python code I've tried to fix recently [1]. A ton of nothingness. You can produce it in any language.
You are too harsh on Perl design. I thought ruby was popular because it is great language. Nope. Cool kids moved to server side JavaScript. And tried to hide prototype oriented origins, they've added class friends privates now and a ton of other questionable features.
It is all about version 5 dead. I've red Perl 6 Apocalypses, I'd ship. Too bad there was no smooth transition path.
[1] https://github.com/GoogleCloudPlatform/gsutil/blob/master/gs...
You can describe "Perl 6" as the dead name of the Raku Programming Language (https://raku.org using the #rakulang tag on social media). :-)
Thanks for sharing your experience.
I worked some years with Perl, and while it was fun most of the time, it had a lot of frustrating things that made it difficult to have consistent builds and dependency management. The "There's more than one way to do it" mantra is very damaging when all you want is a productive language to produce something, vs having fun implementing or tinkering with libraries in CPAN. There's a lot of research, including taking a look at the code to really know what the library does, to assemble programs in Perl.
Once you get over the initial conceptual barrier and remember how the sigils are used, and get used to the bless object system, it is fun to develop in it, on an intellectual level. But rather annoying on an "enterprise" level.
In the end, I find it very difficult to justify using Perl over almost any other language. Even PHP would be better for dev teams, due to the higher focus on productivity frameworks, even if the language holds no distinctive advantage over any other. I felt Perl is not really a professional language, but the product of a whimsical creator and community (which, by the way, is very welcoming and open).
I worked some years with Perl, and while it was fun most of the time, it had a lot of frustrating things that made it difficult to have consistent builds and dependency management. The "There's more than one way to do it" mantra is very damaging when all you want is a productive language to produce something, vs having fun implementing or tinkering with libraries in CPAN. There's a lot of research, including taking a look at the code to really know what the library does, to assemble programs in Perl.
Once you get over the initial conceptual barrier and remember how the sigils are used, and get used to the bless object system, it is fun to develop in it, on an intellectual level. But rather annoying on an "enterprise" level.
In the end, I find it very difficult to justify using Perl over almost any other language. Even PHP would be better for dev teams, due to the higher focus on productivity frameworks, even if the language holds no distinctive advantage over any other. I felt Perl is not really a professional language, but the product of a whimsical creator and community (which, by the way, is very welcoming and open).
Python? That doesn't make sense. Anyone who appreciates Perl would surely choose Ruby over Python.
If what you appreciated in Perl was how pragmatic and "batteries included" it was, then Python is pretty clearly the right choice these days. It's got all the packages you want and get stuff done. I don't like Python's syntax, I think it's filled to the brim with false good ideas, but it's so widely supported that there's not much competition these days.
Although I suppose the way things are headed in a few years that might become... JavaScript, of all things. The theory that the world truly ended in 2012 becomes more appealing every day.
Although I suppose the way things are headed in a few years that might become... JavaScript, of all things. The theory that the world truly ended in 2012 becomes more appealing every day.
As someone who has worked arguably a lot with Perl, Ruby and Python, I too choose Python.
Ruby is just as dead. Only thing it had going for it was Rails.
In Startup Land Rails is still thriving. Check out jobs on Angel.co and HN Who's Hiring.
Is there even a good alternative to Rails?
As far as I know, it's still the best option there is for quickly building a MVP on the web if one isn't building a SPA.
As far as I know, it's still the best option there is for quickly building a MVP on the web if one isn't building a SPA.
Is Rails quicker and easier than, say, Django? Sure. Is it quicker and easier by enough to make it worth having another language in your stack? Not really, IME.
Laravel[1] is pretty close, and PHP has some big advantages over Ruby for performance and deployment.
If you had told me 5 years ago that I'd be recommending PHP as an alternative vs. RoR I wouldn't have believed you, but the PHP world has improved in ways that I wouldn't have thought possible.
[1] https://laravel.com/
If you had told me 5 years ago that I'd be recommending PHP as an alternative vs. RoR I wouldn't have believed you, but the PHP world has improved in ways that I wouldn't have thought possible.
[1] https://laravel.com/
Laravel may be based on the idea of Rails but in terms of programmer happiness it doesn't come close. A typical file of idiomatic PHP code reads like stodgy old Java and contains about 60% blank lines and doc comments as recommended by PSRs. Rails, by contrast, is elegantly concise and has fantastic metaprogramming.
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 like $_, $. $/ $, $\ $" $; $: $# etc etc.
Any one with any engineering experience learns quick that features like that are an anti-pattern. They're super fragile. Some lines of code down stream are expecting one of those variables to have a certain value. A simple edit somewhere can break it all.
The only languages worse are sh and dos batch files.
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 like $_, $. $/ $, $\ $" $; $: $# etc etc.
Any one with any engineering experience learns quick that features like that are an anti-pattern. They're super fragile. Some lines of code down stream are expecting one of those variables to have a certain value. A simple edit somewhere can break it all.
The only languages worse are sh and dos batch files.
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
Perl was my first real language, too, but I haven't used it in years. Others complain about the sigils and referencing rules but I learned them early, when I was young, so I guess I didn't know any better.
I even had a job where we created a featureful website with just perl, DBI, and no framework except a simple module written by a programmer who left the company before I was hired. I look back to that job fondly, because everything seemed much simpler. Only bad thing about it was the paycheck. :)
I even had a job where we created a featureful website with just perl, DBI, and no framework except a simple module written by a programmer who left the company before I was hired. I look back to that job fondly, because everything seemed much simpler. Only bad thing about it was the paycheck. :)
[deleted]
A remarkably self-aware comment. Thank you for this.
Thank you for sharing this story, it's really eye-opening
Try go, you might like it. I did.
I was part of a team that wrote significant parts of Amazon's payment processing systems in Perl in the late 90s. I really loved the language. It's object system was so flexible and powerful. Once you understood how write idiomatic perl. It was a joy to use. I'm looking forward to trying out Perl 7.
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 figuring out what syntax you need to invoke something correctly is confusing mental overhead that you have to keep in mind for every function call
Basically the things I learned in perl were the least transferrable concepts of any programming language I've ever worked with. You learn Haskell, or Forth, or Lisp and you learn insights and patterns that you can use in any language. You learn perl, and you've learned nothing but Larry Wall.
And on top of that, the sigils, refs, and `wantarray` systems means that figuring out what syntax you need to invoke something correctly is confusing mental overhead that you have to keep in mind for every function call
Basically the things I learned in perl were the least transferrable concepts of any programming language I've ever worked with. You learn Haskell, or Forth, or Lisp and you learn insights and patterns that you can use in any language. You learn perl, and you've learned nothing but Larry Wall.
I think you should revisit perl.
My first job writing perl was in 2005 or 2006, and it was not a good language for an eager idiot without guidance. After a couple years, I started getting it, and it became one of my favorite languages.
I think it was my coworker who told me to read https://hop.perl.plover.com/ and it blew my mind and made me start to rethink how I was approaching code. With the languages that I'd been using previously, the game was to fit the problem into what the language wanted you to do. HOP would likely be boring to you now, and wouldn't do much for me, but at the time, it showed me that perl was a language in which the same problem could be solved in multiple different ways, and both be just as right as the other.
Fetishizing that freedom, just like anything else, leads to self indulgent trash. I've seen it in every language, but perl allows for so much freedom it is easy to misuse.
It clicked with me that the best perl code was code that did what I intuitively thought it should do when I used it, and did what I thought it would do when I looked at it. Perl, compared to every other language that I've used, gave me tools to accomplish that.
Perl's object system is Python's, just in its raw parts. I still miss aspects of Moose that are impossible or ugly to use in other languages. Regexps are easy to misuse, but grammars allowed me to cleanly express what something did better than I've been able to in any other language. Mixing in functional ideas, where appropriate, made my code easier to reason about, instead of the debugging hell that I've seen it add to languages like Java. When I learned the concepts from perl, I learned when to use them in other languages.
I don't use perl much anymore, and I don't think I would push it on a team, and I really don't think that it is a good language for beginning programmers, unless there are good mentors around. Most of the beautiful code that I've ever written has been in perl.
My first job writing perl was in 2005 or 2006, and it was not a good language for an eager idiot without guidance. After a couple years, I started getting it, and it became one of my favorite languages.
I think it was my coworker who told me to read https://hop.perl.plover.com/ and it blew my mind and made me start to rethink how I was approaching code. With the languages that I'd been using previously, the game was to fit the problem into what the language wanted you to do. HOP would likely be boring to you now, and wouldn't do much for me, but at the time, it showed me that perl was a language in which the same problem could be solved in multiple different ways, and both be just as right as the other.
Fetishizing that freedom, just like anything else, leads to self indulgent trash. I've seen it in every language, but perl allows for so much freedom it is easy to misuse.
It clicked with me that the best perl code was code that did what I intuitively thought it should do when I used it, and did what I thought it would do when I looked at it. Perl, compared to every other language that I've used, gave me tools to accomplish that.
Perl's object system is Python's, just in its raw parts. I still miss aspects of Moose that are impossible or ugly to use in other languages. Regexps are easy to misuse, but grammars allowed me to cleanly express what something did better than I've been able to in any other language. Mixing in functional ideas, where appropriate, made my code easier to reason about, instead of the debugging hell that I've seen it add to languages like Java. When I learned the concepts from perl, I learned when to use them in other languages.
I don't use perl much anymore, and I don't think I would push it on a team, and I really don't think that it is a good language for beginning programmers, unless there are good mentors around. Most of the beautiful code that I've ever written has been in perl.
Do you have a good link to learn about grammars in perl?
Start https://perldoc.perl.org/perlre.html#Extended-Patterns . I was trying to find an article from many years ago, but either my google skills fail me, or it is dead. Perl's regular expressions haven't been regular expressions for a long time. Beyond that, the ergonomics of perl make them much more useful for things like flow control than in other languages. It's similar to how you can do type matching in Java, but it's ugly, versus a language like Haskell where using type matching simplifies the code.
Perl 6 (as lizmat pointed out), has more powerful rules. I don't know a ton about them.
Perl 6 (as lizmat pointed out), has more powerful rules. I don't know a ton about them.
Perl does not have grammars (at least, not built-in). Raku (formerly known as Perl 6) does: https://docs.raku.org/language/grammar_tutorial
> Perl does not have grammars (at least, not built-in).
That's not true since v5.10 (2007). Here's a sample that matches a subset of LaTeX markup:
That's not true since v5.10 (2007). Here's a sample that matches a subset of LaTeX markup:
$matcher = qr{
(?&File)
(?(DEFINE)
(?<File> (?&Element)* )
(?<Element> \s* (?&Command)
| \s* (?&Literal)
)
(?<Command> \\ \s* (?&Literal) \s* (?&Options)? \s* (?&Args)? )
(?<Options> \[ \s* (?:(?&Option) (?:\s*,\s* (?&Option) )*)? \s* \])
(?<Args> \{ \s* (?&Element)* \s* \} )
(?<Option> \s* [^][\$&%#_{}~^\s,]+ )
(?<Literal> \s* [^][\$&%#_{}~^\s]+ )
)
}xms
it looks to me like HOP is mostly teaching traditional LISP concepts. I could write those same functions in Javascript, and they'd be more readable
With which JavaScript version? At the time HOP was written I remember JavaScript still doing all it's for loops in C-style and there was certainly no arrow syntax to make anonymous JS functions manageable.
There were also no functional methods available, as related by the restriction to C-style for loops. (Array Iteration methods didn't appear in the spec until 2009, so I don't see how you could have map or select or anything else functional).
There were also no functional methods available, as related by the restriction to C-style for loops. (Array Iteration methods didn't appear in the spec until 2009, so I don't see how you could have map or select or anything else functional).
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 with or without a buffer, etc. Perl instead has an obscure global variable that you have to look up/memorize, and it doesn't even have a sensible name like $STDOUT_BUFFERING, so readers who come across $| in a file have to look it up/recall from rote memorization, or hope it has a good comment above it.
$| 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 with or without a buffer, etc. Perl instead has an obscure global variable that you have to look up/memorize, and it doesn't even have a sensible name like $STDOUT_BUFFERING, so readers who come across $| in a file have to look it up/recall from rote memorization, or hope it has a good comment above it.
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.
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 use it, because it makes them feel cool.
Having two totally but pointlessly different syntaxes for the same thing doesn't absolve you from having to learn both syntaxes, because you'll still encounter other people's code that uses both of them -- it just gives you twice as much syntax to learn.
If there's a "sensible alternative", then why does there have to be a "senseless alternative" in the first place?
If hard-to-read-and-remember syntax exists, people WILL use it. And some people will make a POINT to use it, because it makes them feel cool.
Having two totally but pointlessly different syntaxes for the same thing doesn't absolve you from having to learn both syntaxes, because you'll still encounter other people's code that uses both of them -- it just gives you twice as much syntax to learn.
If there's a "sensible alternative", then why does there have to be a "senseless alternative" in the first place?
You have to bare in mind Perls roots are as an awk-like language for the command line. In those instances weird line noise syntax was the idiom and as Perl grew it moved away from that but without breaking compatibility by default.
This leads to serious Perl projects relying on the numerous headers (as described in the very article we are discussing) to ensure everyone applies a more modern coding style.
So you can absolutely stop people from using $|
The point of Perl 7 is to have sane defaults.
This leads to serious Perl projects relying on the numerous headers (as described in the very article we are discussing) to ensure everyone applies a more modern coding style.
So you can absolutely stop people from using $|
The point of Perl 7 is to have sane defaults.
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 older, 'worse' things.
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 older, 'worse' things.
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.
You are going to end up perpetually unhappy if you always assume that people designed things the way they did just because of stupidity / incompetence. Perhaps instead you should take a while to think about the reasons why they might have chosen their design. Even if you can't immediately think of a good reason, doesn't mean there wasn't one.
For this particular case, I'm not sure what drove the selection, but I would guess (since the decision would have been made many decades ago!) it was probably based around perl trying to operate similarly to other command line tools of that era, like awk, sed, (or even ed?), so that people could switch to perl and have a familiar environment? But I don't know, nor have I researched it. In any case, perhaps give the designers the benefit of the doubt before assuming their incompetence?
For this particular case, I'm not sure what drove the selection, but I would guess (since the decision would have been made many decades ago!) it was probably based around perl trying to operate similarly to other command line tools of that era, like awk, sed, (or even ed?), so that people could switch to perl and have a familiar environment? But I don't know, nor have I researched it. In any case, perhaps give the designers the benefit of the doubt before assuming their incompetence?
Yes, that is how Perl evolved. It's called "whipupitude" in The Land of Perl. Larry's initial goal was to create a better sed/awk for Unix.
...and how many of them were designed to be sprinkled liberally in the command line?
Python has a REPL but you couldn’t dump a Python one liner in your Bash pipeline.
Maybe a LISP might qualify but then you’re back to a language family that is unreadable to many and unknown to most (and I say this as someone who loves LISP)
When talking about the original design of Perl you can’t put it in the same category as Python, Pascal and the C-family of languages. Perl was born from an entirely different problem to solve and that’s why some of it’s historic features seem so alien to people outside of the Perl community.
Python has a REPL but you couldn’t dump a Python one liner in your Bash pipeline.
Maybe a LISP might qualify but then you’re back to a language family that is unreadable to many and unknown to most (and I say this as someone who loves LISP)
When talking about the original design of Perl you can’t put it in the same category as Python, Pascal and the C-family of languages. Perl was born from an entirely different problem to solve and that’s why some of it’s historic features seem so alien to people outside of the Perl community.
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 Perl ... thoroughly.
> Programming seems to be the only profession in which the neophyte 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"?
Yes. Yes I can[1]
[1]: https://how-to-play-electric-guitar.net/tab-symbols.html
The problem isn't merely that notation is easy/hard, but that people will not only pass judgement about a language (or any other idea), they will also work actively to convince others to agree with them, and oh yeah, that programmers are people too.
Yes. Yes I can[1]
[1]: https://how-to-play-electric-guitar.net/tab-symbols.html
The problem isn't merely that notation is easy/hard, but that people will not only pass judgement about a language (or any other idea), they will also work actively to convince others to agree with them, and oh yeah, that programmers are people too.
> programmers are people too
Are we really?
Are we really?
> 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.
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.
Restrict scale to pentatonic even for professionals (remove physical keys, holes etc). They would absolutely mess up otherwise.
But you would still have to master notation if you were to become an accomplished jazz musician, for example.
Sure. The context is "dumbed down to make it easier to learn" not dumbed down and forced on everyone. If you want to go full Brian Eno, you can. (https://public-media.si-cdn.com/filer/2b/e0/2be067d0-c428-40...)
> "Can you imagine a budding musician complaining that musical notation should be made "easier for beginners"?"
Yes, of course I can: https://en.wikipedia.org/wiki/Simplified_music_notation and from the linked website "is designed for learners in general".
> "worse, that he/she expects the language to be dumbed down to make it easier to learn."
And why should "simplify" have the connotation "dumbed down, for dumb people"? Everyone benefits from simpler things with fewer warts and fewer hazards.
Yes, of course I can: https://en.wikipedia.org/wiki/Simplified_music_notation and from the linked website "is designed for learners in general".
> "worse, that he/she expects the language to be dumbed down to make it easier to learn."
And why should "simplify" have the connotation "dumbed down, for dumb people"? Everyone benefits from simpler things with fewer warts and fewer hazards.
Perl is an old accordion.
If what you're saying is true, then why aren't similar criticisms raised against Ruby? Most of the same obscure variables are also present in Ruby.
"If hard-to-read-and-remember syntax exists, people WILL use it"
This statement doesn't appear to hold up under scrutiny.
"If hard-to-read-and-remember syntax exists, people WILL use it"
This statement doesn't appear to hold up under scrutiny.
I suspect that Ruby has almost no usage. I've only ever heard of using it in a handful of startups from the valley and it's only Ruby on Rails.
Wouldn't be surprised if Perl had a hundred or a thousand times more developers, it used to be popular in the 90 and 2000s. They are still alive today and commenting about it, even though they're probably working professionally in something else.
Wouldn't be surprised if Perl had a hundred or a thousand times more developers, it used to be popular in the 90 and 2000s. They are still alive today and commenting about it, even though they're probably working professionally in something else.
> If what you're saying is true, then why aren't similar criticisms raised against Ruby? Most of the same obscure variables are also present in Ruby.
Not with the sigil names, are they?
Not with the sigil names, are they?
Indeed, there are a lot of them actually https://ruby.fandom.com/wiki/Special_variable
Your boilerplate whataboutism confirms my point.
>This statement doesn't appear to hold up under scrutiny.
What scrutiny? I don't see any scrutiny. You just said that, without scrutinizing.
>This statement doesn't appear to hold up under scrutiny.
What scrutiny? I don't see any scrutiny. You just said that, without scrutinizing.
> If hard-to-read-and-remember syntax exists, people WILL use it. And some people will make a POINT to use it, because it makes them feel cool.
Just like every human language that ever existed. And last time I checked, programming languages aren't used or written by AI's or aliens.
Just like every human language that ever existed. And last time I checked, programming languages aren't used or written by AI's or aliens.
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...
[0] https://stackoverflow.com/questions/26127617/what-exactly-ar...
I take it you've never done much shell scripting? This part of perl's baggage comes from its roots as a "better" shell/awk/sed. I don't like it any more than you do, but I must say, I wish people would reserve some of the vitriol they have for perl for the shell. Because I gotta tell you Rabbi, perl is a hell of a lot better than shell scripts. And that's even if you compare perl4 (1991-1994 or so?) to the very latest bash or zsh.
edit:
BTW if $| is really at risk of clashing with a variable you defined... something else is wrong. :)
Compare that with the shell, where names like IFS can do unimaginable things if you don't know about them and set them by mistake. (Or maliciously; it's imported directly from the environment, and stuff like this is why shell scripts can basically never be given untrusted input, whereas perl, with the 'taint' option, can.)
Reflecting on all this it's pretty sad that newbies in 2020 are encouraged to learn bash, and continue creating arcane, unreadable, booby-trap-laden scripts in it, all the while looking down their nose at perl.
edit:
BTW if $| is really at risk of clashing with a variable you defined... something else is wrong. :)
Compare that with the shell, where names like IFS can do unimaginable things if you don't know about them and set them by mistake. (Or maliciously; it's imported directly from the environment, and stuff like this is why shell scripts can basically never be given untrusted input, whereas perl, with the 'taint' option, can.)
Reflecting on all this it's pretty sad that newbies in 2020 are encouraged to learn bash, and continue creating arcane, unreadable, booby-trap-laden scripts in it, all the while looking down their nose at perl.
That's not so much Perl hijacking a user space variable as Perl having some single character globals that have special behavior. Really, you usually learn about those early (sorting is common), and if you're using strict like you should be, if you define them and use them they will work as expected until you use a custom sort, in which case you'll track down the error.
In Perl, you learn pretty early that single character non-alphanumeric variables ($|, $_, @_ $@) are special and if you encounter them and don't know them, look them up. You also learn that $1 through $9 and $a and $b have special uses, so don't use those without knowing what you're doing either.
> utterly confounding the first time one accidentally runs into it.
Yeah, but every language has some of those. Who remembers "Unexpected T_PAAMAYIM_NEKUDOTAYIM" in PHP? Or giant template error messages in C++? Or just plain segfaults? All paradigms and the languages within them have their own trade-offs and gotchas, and part of learning the language is learning those.
In Perl, you learn pretty early that single character non-alphanumeric variables ($|, $_, @_ $@) are special and if you encounter them and don't know them, look them up. You also learn that $1 through $9 and $a and $b have special uses, so don't use those without knowing what you're doing either.
> utterly confounding the first time one accidentally runs into it.
Yeah, but every language has some of those. Who remembers "Unexpected T_PAAMAYIM_NEKUDOTAYIM" in PHP? Or giant template error messages in C++? Or just plain segfaults? All paradigms and the languages within them have their own trade-offs and gotchas, and part of learning the language is learning those.
Developers spend most of their time reading other peoples code, so yes, one does have to learn the less sensible alternatives, if you choose this tool. It's called historical baggage for a reason.
With any luck Perl 7 with phase out the archaic linenoise features. This is overdue IMO.
I'm no fan of Perl, but you can use $OUTPUT_AUTOFLUSH instead if you "use English;". So this isn't really a Perl language thing; it's a style thing. Other languages can be made to look really bad with poor style. The question then becomes what is culturally accepted, and what is not.
`use English;` as a directive feels like the programming equivalent of someone on TV saying "ye ye ye can you say that in English!?"
Only, it's the programmer saying it this time, not the layman. Perl is a 10x engineer.
Only, it's the programmer saying it this time, not the layman. Perl is a 10x engineer.
The problem is that nobody ever tells you these things, the documentation doesn’t cover them and as a result everyone still uses the terrible original syntax.
What do you mean the documentation doesn’t cover them?
https://perldoc.perl.org/perlvar.html#SPECIAL-VARIABLES
https://perldoc.perl.org/perlvar.html#SPECIAL-VARIABLES
One can also:
use IO::Handle;
STDOUT->autoflush(1);
STDERR->autoflush(1);TMTOWTDI!
TIMTOWTDIBSCINABTE (pronounced "tim toady bicarbonate").
"There’s more than one way to do it, but sometimes consistency is not a bad thing either."
"There’s more than one way to do it, but sometimes consistency is not a bad thing either."
TIMTOWTDIBSCINABTE
(for those unfamiliar: https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to...)
(for those unfamiliar: https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to...)
$| is related to pipes. Much of the sigils are like this.
It suddenly makes sense and isn't so bad.
The $ is a sigil, so it appears before variables like $var, so it's just saying | it out. When typed at the beginning of a one liner it becomes quite obvious what you want. This is clearly not a feature for a large project, but a quick UNIX style one off awk-like script.
The $ is a sigil, so it appears before variables like $var, so it's just saying | it out. When typed at the beginning of a one liner it becomes quite obvious what you want. This is clearly not a feature for a large project, but a quick UNIX style one off awk-like script.
In Perl `$` is strictly a scalar variable though this can be a reference to an array, hash or object as they are stored as references. Not to be confused with `$` in PHP which simply denotes a variable of any kind. In Bash `$` denotes the value of a variable.
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.
Have you ever read O'Reilly's "Mastering Regular Expressions" by Friedl? He does a deep dive into the weird guts of regex modifiers.
I was obsessed with that book one summer and wrote a bunch of parsers after learning incremental techniques (/o I think), and then 8 months later I could no longer remember how anything that I wrote worked. Lol me.
I was obsessed with that book one summer and wrote a bunch of parsers after learning incremental techniques (/o I think), and then 8 months later I could no longer remember how anything that I wrote worked. Lol me.
Friedl's masterpiece was my introduction to server-side programming in 2000. I'd been doing front-end for a few years with Dreamweaver and I was looking-up it's find & replace features in "Dreamweaver Bible 8" where regexes were mentioned as the ultimate weapon. "Mastering Regular Expressions" was referenced in a footnote and fortunately my local library had a copy. My mind was blown. Regex symbols were just so powerful and the examples were mainly written in Perl which added even more power to them. The book was part of O'Reilly's Perl bookshelf so in addition to Friedl's book I bought the other Perl classics - "Programming Perl", "Perl Cookbook", "Mastering Algorithms with Perl" and "Learning Perl". With CPAN downloaded to my local disk I felt like a hitch-hiker setting out on a journey around the world needing nothing more than Perl in my backpack. Those were the days. Now I have to download 200Mb of node_modules before I can get started.
Recently I found some old floppy drives at the back of a drawer. I manager to find an usb disk drive, inserted the floppy, what do I find? Sure enough, Perl code I've written back in 2000! Indeed, those were the days :)
If it was back-end website code it probably used Lincoln Stein's CGI.pm module which was used everywhere though it was a bit of a beast with frequent security updates. I later progressed to CGI::Application for an app which ran a business for 12 years before I converted it to Rails. I always thought Mojolicious was a great Perl web framework but unfortunately it landed just as Rails was picking-up steam.
FWIW, this is the default in Raku regular expressions.
Oh, thank you, didn't know that!
Raku is Perl programming language so that makes sense.
If you're interested in improved regular expressions, I wuold suggest you have a look at Raku's regular expressions and grammars (formerly known as Perl 6): https://docs.raku.org/language/regexes
Agreed. Regex is a “part of the language” not a bolt on library like you have in Python. It’s one of those cases where you don’t even know how crap regex is in another language if you’ve never used Perl.
I mentioned Boost's Regex in C++ (boost is essentially a different language), but I didn't bother to mention my experiments with regex in C, for example:
http://web.archive.org/web/20160308115653/http://peope.net/o...
I mean, you can do it, it just lacks elegance. And TBH, I still prefer C for lots of things.
http://web.archive.org/web/20160308115653/http://peope.net/o...
I mean, you can do it, it just lacks elegance. And TBH, I still prefer C for lots of things.
You should check out janet-lang.org. It's got built in peg parsing.
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.
I only used Ruby briefly over 20 years ago so I can't comment.
I do recommend Haskell. (But do not go into regexes first!)
But even though it has a similar powerful set of operations for regular expressions, people mostly don't use it, because there are better ways to deal with text.
But even though it has a similar powerful set of operations for regular expressions, people mostly don't use it, because there are better ways to deal with text.
Funny you should mention Haskell as it was used to bootstrap one of the early versions of Perl 6 if I remember.
You would like Crystal, it has similar regexes
> You learn perl, and you've learned nothing but Larry Wall.
Yes, this is why it's nice. You don't have to worship at the foot of an industry which slavishly tries to implement a misunderstanding of a system some dude made up 40 years ago to get around problems in other systems some other dudes made up before that. It's weird on purpose. And it's backwards-compatible-crufty on purpose.
Today I can run Perl code written two decades ago, but with the latest interpreter. I don't think any other interpreted language can do that, can they? (Bourne shell?)
Yes, this is why it's nice. You don't have to worship at the foot of an industry which slavishly tries to implement a misunderstanding of a system some dude made up 40 years ago to get around problems in other systems some other dudes made up before that. It's weird on purpose. And it's backwards-compatible-crufty on purpose.
Today I can run Perl code written two decades ago, but with the latest interpreter. I don't think any other interpreted language can do that, can they? (Bourne shell?)
Not a Microsoft fan, but simple C / Windows API code from 25 years ago would likely compile and run on Windows 10 unchanged.
My limited experience with Swift suggests that even 25 hours ago could be a tall order...
My limited experience with Swift suggests that even 25 hours ago could be a tall order...
Moreover, a Windows .exe compiled 25 years ago will also likely just run.
25 years ago is 1995, and around the release of Windows 95, the first 32-bit version of Windows.
A .exe compiled 25 years ago would probably be a 16-bit executable, and Windows stopped supporting Win16 code in Windows 7. WINE theoretically supports it, but 16-bit userspace code and a 64-bit kernel do not mix well.
A .exe compiled 25 years ago would probably be a 16-bit executable, and Windows stopped supporting Win16 code in Windows 7. WINE theoretically supports it, but 16-bit userspace code and a 64-bit kernel do not mix well.
> the first 32-bit version of Windows.
Windows NT was released in July, 1993. Almost exactly two years before Windows 95.
In 1997 I joined a company where I was doing Win32 coding, on a Windows NT code base that dated back to 1995. The code base also had parts targeting Windows CE client devices. (The company was an extremely early adopter of that platform; they might have done some of the development before CE was officially released in 1996. Anyway, that's another 32 bit Windows from almost 25 years ago, and less of a hack than 95.)
Windows NT was released in July, 1993. Almost exactly two years before Windows 95.
In 1997 I joined a company where I was doing Win32 coding, on a Windows NT code base that dated back to 1995. The code base also had parts targeting Windows CE client devices. (The company was an extremely early adopter of that platform; they might have done some of the development before CE was officially released in 1996. Anyway, that's another 32 bit Windows from almost 25 years ago, and less of a hack than 95.)
I don't think that's true. The 32-bit versions of Windows still run 16-bit binaries.
Just run a 20 year old binary and worked fine; I'ld lie if I said it didn't impressed me
Eh, simple C code with X11/Motif will compile fine under Unix too.
TCL, but 7.x code may have flaws.
JavaScript probably can, or at least mostly. That's where a lot of its problems come from, historical baggage.
JavaScript didn't exist 25 years ago.
(The first version was released in September 1995, but wasn't JavaScript until Dec 4, 1995.)
(The first version was released in September 1995, but wasn't JavaScript until Dec 4, 1995.)
> 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.
Have you even seen what Javascript is calling OOP? Or the weirdness around "this" keyword? They finally have a "class" keyword, but it's just syntax sugar on top of the weird prototype hashes they have always used.
Lots of languages have weird OOP systems. C++, in particular, if you really want to dive into that. Maybe Java and Ruby are somewhat sane. But I'd prefer not to use either of those, myself.
Have you even seen what Javascript is calling OOP? Or the weirdness around "this" keyword? They finally have a "class" keyword, but it's just syntax sugar on top of the weird prototype hashes they have always used.
Lots of languages have weird OOP systems. C++, in particular, if you really want to dive into that. Maybe Java and Ruby are somewhat sane. But I'd prefer not to use either of those, myself.
OOP will rot your teeth.
The Moose library is a pretty advanced OO library that was inspired by Common Lisp's CLOS & Smalltalk I think. Most Perl developers I know use a large amount of libraries as the language itself is lacking in many areas. A lot of people are fine with that, but I prefer kitchen-sink languages which are fairly opinionated.
At least one of the inspirations of Moose, was the object system of Perl 6 at the time (now Raku https://raku.org using the #rakulang tag on social media). To create a Point class that has an x and a y attribute, you'd write:
class Point {
has $.x;
has $.y;
}
Point.new(x => 42, y => 666);Forgot about the inspiration from P6 (Raku). Thanks for mentioning Liz!
I'm sorry, Moose is a pig. Its startup time is atrocious. Its run time overhead is non-trivial. People who use Moose in my experience just showboat that they can do OO. Does it help? Maybe. But what it surely does is it makes a program run and startup significantly slower.
Things have moved on. Moose is a bit of kitchen sink. These days you would generally choose Moo first unless you really needed the meta object features. Or to get incremental Moo(se) features you’d use Role::Tiny, Class::Method::Modifiers And Type::Tiny
> And on top of that, the sigils, refs, and `wantarray` systems means that figuring out what syntax you need to invoke something correctly is confusing mental overhead that you have to keep in mind for every function call
That's just badly written libraries that exist in pretty much every ecosystem. By now it seems we have settled that after a couple of args the way to pass multiple arguments is via a hash.
That's just badly written libraries that exist in pretty much every ecosystem. By now it seems we have settled that after a couple of args the way to pass multiple arguments is via a hash.
I speak as someone who has programmed in Perl for over 20 years and at one point was the top poster on Perlmonks.
The wantarray feature is a problem with Perl, and not libraries. It has nothing to do with how you pass your arguments, but rather how the data comes back. Every single function has to deal with the potential of context. Every choice you make has downsides. The choices made around wantarray tend to age poorly. And many Perl programmers are deeply confused about the difference between these lines:
The wantarray feature is a problem with Perl, and not libraries. It has nothing to do with how you pass your arguments, but rather how the data comes back. Every single function has to deal with the potential of context. Every choice you make has downsides. The choices made around wantarray tend to age poorly. And many Perl programmers are deeply confused about the difference between these lines:
my $bar = foo();
my ($baz) = foo();
This is why Raku doesn't have contexts in that sense. All a subroutine or method can ever return, is a single object. Such an object can be a List or an Array, but it is still a single value.
Whether context is good or bad, a success or a mistake, there's no denying it is either one of the most or the most important idea in Perl.
That you can not really know how it works and still get by in Perl without problems 95% is a testament to Perl trying to make life easier for the programmer, as well as one of the things that contributes most to people not understanding Perl or viewing it as inconsistent and confusing.
That said, I don't really think you can remove it from Perl without making it a drastically different language. Context pervades almost everything, and is how many idiomatic statements actually function (e.g. assigning a hash to another hash is really just list context read from a hash and list context write to a hash).
That you can not really know how it works and still get by in Perl without problems 95% is a testament to Perl trying to make life easier for the programmer, as well as one of the things that contributes most to people not understanding Perl or viewing it as inconsistent and confusing.
That said, I don't really think you can remove it from Perl without making it a drastically different language. Context pervades almost everything, and is how many idiomatic statements actually function (e.g. assigning a hash to another hash is really just list context read from a hash and list context write to a hash).
> Perlmonks.
Perlmonks, in my view, is one of the main reasons Perl community went nowhere. The answer to a question should not be, excuse my french, an exercise in who can swing their dick in the most intricate and convoluted way while accidentally answering the question in the most obfuscated way possible.
Perlmonks, in my view, is one of the main reasons Perl community went nowhere. The answer to a question should not be, excuse my french, an exercise in who can swing their dick in the most intricate and convoluted way while accidentally answering the question in the most obfuscated way possible.
Return a reference to a hash. You are done.
Perl’s core object system isn’t really an object system, it’s a toolkit for building object systems. Of course this leads to too many ways to do it, so if starting fresh just use Moo
I think that criticism that by learning perl one doesn't get any transferable concepts is bit unfair. Though I no longer program in perl, some of the things I learnt using perl has been useful later too. To list here are some of the "concepts" that I learnt using perl: regexes, some aspects of *nix system programming (fork, zombies, signal handling etc.), modular code organisation (writing/using perl modules), code documentation (aka PODs) imbibing importance of documenting the code.
True learning some other language (say Java) would make familiar with other concepts (say OOP) but perl has its fair share of concepts that one can pick by programming using it.
On the subject of transferrable knowledge, Perl was the first language I learned, and I was always a little bit confused about why every language I learned since then didn't have pronouns, until finally magrittr came along in R and made perfect sense to me, since "." in magrittr/dplyr feels a lot like "$_" (or "@_") in Perl.
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!
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 don’t think one can call a blessed hash (or scalar for the fancy folks) an object _system_.
Perl first, then JavaScript.
Did you know JavaScript classes are blessed hashes?
They even take about the same amount of syntax. ("__proto__" vs "blessed", "prototype" vs "bless").
Old JavaScript made the blessing crude and obvious.
Modern JavaScript lets you hide it in a "class" decleration. Which you can also do in Perl if you want (though you'll need to choose a module for this, and people generally prefer a different approach to dressing up objects in Perl.)
There's still a blessed hash under the hood which you can see and kind of have to be aware of... in both languages.
Perl first, then JavaScript.
Did you know JavaScript classes are blessed hashes?
They even take about the same amount of syntax. ("__proto__" vs "blessed", "prototype" vs "bless").
Old JavaScript made the blessing crude and obvious.
Modern JavaScript lets you hide it in a "class" decleration. Which you can also do in Perl if you want (though you'll need to choose a module for this, and people generally prefer a different approach to dressing up objects in Perl.)
There's still a blessed hash under the hood which you can see and kind of have to be aware of... in both languages.
Perl and JavaScript both give you a minimally specified set of tools you can use to build your own more advanced object system.
IMO, that's why both languages have been able to be extended and adapt so much.
If you look at tools like Moo and Moose in Perl and the different coding paradigms that evolved in JS before the "class" keyword was standardized, this is pretty clearly evident.
JS has had the advantage of a standards committee pushing new language features aggressively. Perl has moved more slowly, keeping a majority of functionality in libraries.
IMO, that's why both languages have been able to be extended and adapt so much.
If you look at tools like Moo and Moose in Perl and the different coding paradigms that evolved in JS before the "class" keyword was standardized, this is pretty clearly evident.
JS has had the advantage of a standards committee pushing new language features aggressively. Perl has moved more slowly, keeping a majority of functionality in libraries.
> Did you know JavaScript classes are blessed hashes?
> They even take about the same amount of syntax. ("__proto__" vs "blessed", "prototype" vs "bless").
omg, I totally forgot that (I left day-to-day JS use a good decade ago, sorry!).
> They even take about the same amount of syntax. ("__proto__" vs "blessed", "prototype" vs "bless").
omg, I totally forgot that (I left day-to-day JS use a good decade ago, sorry!).
Traditional JavaScript has a notoriously poor object system yes. If those are the only two languages you know then I guess Perl's object system doesn't seem so bad, but that shouldn't be a defense of either language.
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.
Yes. I was thinking mainly of Perl's symbol table which I believe is also how OO is implemented in Python.
My understanding was that Perl's OO system was directly inspired by Python's. I can't find a source on that though.
Other way round I think.
Nope. http://www.perl.com/pub/a/2007/12/06/soto-11.html
> I don’t really know much about Python. I only stole its object system for Perl 5. I have since repented.
> I don’t really know much about Python. I only stole its object system for Perl 5. I have since repented.
Very similar story here; I barely write any Perl nowadays but am still very fond of it.
I especially like the sigils - they serve in a way as a primitive type system and actually convey useful information when reading code. I suspect people who complain about them are the same who dislike strong typing.
Interestingly, like you, nowadays I am very fond of Scala.
I especially like the sigils - they serve in a way as a primitive type system and actually convey useful information when reading code. I suspect people who complain about them are the same who dislike strong typing.
Interestingly, like you, nowadays I am very fond of Scala.
I also quite enjoyed perl. There are a lot of us that cut their teeth on perl and know it well, even if we are currently working in other languages. We also tend to de-emphasize it on our resumes for obvious reasons. But if I had a contract opportunity to spend months or years on a large perl codebase, refactoring it or porting it to something else, I'd probably snap it up in a heartbeat.
This seems to be a common experience - people say it felt powerful and modern in the 90s, because it was. For those who started programming in the 00s and 10s it looks clunky and weird compared to the other options.
That doesn't add up because today's most popular languages - JS, Java, Python, PHP and Ruby - were also released in the 90s.
Perl 5.0 was released towards the end of 1994.
Python 1.2 was released in 1995.
The first public release of Java as 1.0 was in 1996.
JavaScript appeared in 1995 as well, but the first ECMAScript standard didn't appear until 1997.
First release of PHP was in 1995, same with Ruby.
Perl pre-dates the initial release of all those languages and was already up to its fifth major version by that time.
Python 1.2 was released in 1995.
The first public release of Java as 1.0 was in 1996.
JavaScript appeared in 1995 as well, but the first ECMAScript standard didn't appear until 1997.
First release of PHP was in 1995, same with Ruby.
Perl pre-dates the initial release of all those languages and was already up to its fifth major version by that time.
To be honest Perl 5 isn't really like Perl 4. They are quite different languages - Perl 4 didn't have objects, and Perl 5 places heavy emphasis on them.
Up to you to decide when you think it started, but I'd say the current language we think of as "Perl" started with the release of Perl 5.
Up to you to decide when you think it started, but I'd say the current language we think of as "Perl" started with the release of Perl 5.
Most Perl 4 runs under Perl 5, and most Perl 5 written in the early years did not place heavy emphasis on objects. When I started in Perl, it was common to write code in such a way that it would run under either because it might have to.
Today, objects are used heavily. And furthermore the way we write those classes has changed a lot since Moose and friends became popular. As a result most Perl code bases written in the last dozen years look less like early Perl 5 than early Perl 5 looked like Perl 4.
Perl 4 and Perl 5 are more of a continuum than different languages.
Today, objects are used heavily. And furthermore the way we write those classes has changed a lot since Moose and friends became popular. As a result most Perl code bases written in the last dozen years look less like early Perl 5 than early Perl 5 looked like Perl 4.
Perl 4 and Perl 5 are more of a continuum than different languages.
And even in that case it predates all the other languages except Python by almost a year (Python 1.0 came out in January 1994).
It does add up because Perl was released in 80's and became popular in the 90s, when the other newer languages you listed were designed and released. In the early-mid 90's, "CGI"/"CGI scripts" was synonymous with Perl - it was the backend tech
Perl was released in 1987. The languages released in the 90s all stole Perl/Awk's good idea (have an associative array/hash map/dict type as a builtin data type) but had much nicer syntax.
I stuck with Perl even when Ruby came along and offered to be the next best thing because Ruby didn't have a use strict equivalent. Having to declare variables before use is a good thing.
Perl5 was released in October 1994. That's the version which competes with Python, Ruby and PHP because it introduced OOP.
There's a subtle difference between being released in the 90s and maturing in the 90s.
PHP was a reimplementation of Perl by someone who didn't understand why Perl did things the way they did and so ended up creating a vastly inferior language. Other than maintaining some legacy projects, I've not touched PHP in over a decade and I'm glad to avoid it. Perl is a tool I still return to for some tasks (one was a bizarre management request for a spreadsheet of all the Java classes in a large project which took fifteen minutes to create a Perl script to generate and ten of that fifteen minutes was looking at documentation for Perl modules I hadn't used in a long time).
Yes and No. PHP (Perl for Home Pages) main starting point for popularity was that it was easy to make into an Apache module that could be used on shared hosting. Perl's Apache module was a single interpreter for the whole server. Great for business sites and such, not good when you have multiple unrelated users using the same server. PHP was just something that you could turn on and uses on your shared hosting.
According to Wikipedia PHP stands for "Personal Home Page".
Yes, the memory isolation model of mod_php was the crucial factor in beating the competition. With mod_perl you had to write your Perl modules to a specification so that globals were not accessible by other hosts. That was too much of a risk for shared hosting providers. The situation is muddied, however, in that a lot of shared hosts only allow PHP as a cgi which, in theory, puts it on a level playing-field with Perl. However, in practice, Perl only has one PHP-alike templating framework - HTML::Mason - and that requires mod_perl to perform decently. So PHP's other advantage is that its templating engine is simply faster.
Yes, the memory isolation model of mod_php was the crucial factor in beating the competition. With mod_perl you had to write your Perl modules to a specification so that globals were not accessible by other hosts. That was too much of a risk for shared hosting providers. The situation is muddied, however, in that a lot of shared hosts only allow PHP as a cgi which, in theory, puts it on a level playing-field with Perl. However, in practice, Perl only has one PHP-alike templating framework - HTML::Mason - and that requires mod_perl to perform decently. So PHP's other advantage is that its templating engine is simply faster.
As far as i know Java and PHP became popular later in the 90s / early 2000s. Javascript was browser only until 2010, Ruby only became popular after Rails came out mid-2000s. There is a decade gap there.
> Javascript was browser only until 2010
Depending on how you look at it you are at least a decade too late: we Java folks had the Rhino Javascript engine back in the late 1990ies, and it had an interpreted mode since 1998: https://en.wikipedia.org/wiki/Rhino_(JavaScript_engine)
I think it is even mentioned in the Javascript in a Nutshell book by David Flanagan (I haven't read it since then but I studied that book as I wrote a map rendering system in Javascript back in school in 2005.)
Depending on how you look at it you are at least a decade too late: we Java folks had the Rhino Javascript engine back in the late 1990ies, and it had an interpreted mode since 1998: https://en.wikipedia.org/wiki/Rhino_(JavaScript_engine)
I think it is even mentioned in the Javascript in a Nutshell book by David Flanagan (I haven't read it since then but I studied that book as I wrote a map rendering system in Javascript back in school in 2005.)
True, I played with Rhino, Jack / JSGI early on, and did a couple projects with Aptana Jaxer around 2009. It was not really an option most developers would even consider, though.
Node came out in 2009, and writing server-side JS was still a fringe practice for a couple more years, so 2010 is me being generous to avoid comments on the exact timeline ;) It really picked up mainstream adoption around 2011-2012.
Node came out in 2009, and writing server-side JS was still a fringe practice for a couple more years, so 2010 is me being generous to avoid comments on the exact timeline ;) It really picked up mainstream adoption around 2011-2012.
Was Rhino ever anything other than a minefield that you were essentially pigeonholed into using for compatibility reasons or something similar? I have used it before but only because we had specific technical requirements that demanded we run Javascript on a server-side JVM implementation.
"Server-side JavaScript" was a feature of Netscape web servers in 1996.
At the end of the 90s Javascript was used to write a part of Dreamweaver and I mean the app itself, not the Javascript/HTML interface. So the language as always existed independently of browser implementations.
Perl pretty much felt clunky and weird as soon as I discovered Scheme in 1996 or so.
I was on one of several CAD teams at Intel in the 90's and huge parts of pre and post-silicon Itanium simulation flows for timing, layout and verification were written in Perl. (Not even Perl 5.6 so we hit the 2GB file limit often!) ... Not the tools themselves, but the control flows and asset managers. The other processors still used Tcl on HPUX/Solaris/AIX so Perl on Linux was like nice warm sheets by comparison.
> The other processors still used Tcl on HPUX/Solaris/AIX so Perl on Linux was like nice warm sheets by comparison.
I would agree, but I don't think you meant it the same way I would: I prefer nice cold sheets when I sleep, and I much prefer Tcl to Perl!
I would agree, but I don't think you meant it the same way I would: I prefer nice cold sheets when I sleep, and I much prefer Tcl to Perl!
Perl was a great fun scripting language back in the day of CGI and "webmaster@".
It died a noble, honorable death. RIP.
It died a noble, honorable death. RIP.
It's not even close to dead.
While you can FIND Perl jobs, it is effectively dead for most of the hiring market. It will never truly disappear. COBOL is not dead either. Is it really something that we think of when we talk about modern software engineering? Not really.
How much production software is started from scratch every day using the language?
I started my career in Perl and I still have fond memories of working with it up to late 2000's, but by that time the writing was solidly on the wall.
Dead in this context means "niche".
How much production software is started from scratch every day using the language?
I started my career in Perl and I still have fond memories of working with it up to late 2000's, but by that time the writing was solidly on the wall.
Dead in this context means "niche".
True. If you search Indeed.co.uk there are more jobs which mention Perl than Golang.
[deleted]
I hear Perl has weak typing with implicit type conversion. The only other language I know that has a powerful implicit type conversion system is C++. How does implicit type conversion work in Perl?
Conversion is done based on operator, and Perl has different operators for string and numeric operations. For example, == and eq are different operators, with the former doing numeric equivalence comparison, and the latter doing string equivalence comparison. The implicit conversion done to operands in each case is well defined and obvious.
Edit: Whoops, had operators reversed because I explained them after the fact. Fixed!
Edit: Whoops, had operators reversed because I explained them after the fact. Fixed!
There is also a concept of "context" in Perl.
An operation may be evaluated in list or scalar context. For example, if you evaluate an array in list context, you get the members of the array, however, in scalar context, you get the number of elements in the array.
This idea is generalized to discuss different evaluation contexts for scalars. You might hear people discussing how a value behaves in boolean or string context. It's also common to talk about casting as "-ification", for example casting something to boolean context is "boolification".
By default, undefined values convert to empty string and 0. However, this can be made to generate a warning or even a fatal exception by setting the appropriate pragmas.
An operation may be evaluated in list or scalar context. For example, if you evaluate an array in list context, you get the members of the array, however, in scalar context, you get the number of elements in the array.
This idea is generalized to discuss different evaluation contexts for scalars. You might hear people discussing how a value behaves in boolean or string context. It's also common to talk about casting as "-ification", for example casting something to boolean context is "boolification".
By default, undefined values convert to empty string and 0. However, this can be made to generate a warning or even a fatal exception by setting the appropriate pragmas.
Generally in Modern Perl-style programming, strict and warnings are enabled, so implicit type conversion is not used as much these days. Warnings or errors are emitted.
I've found this greatly increases reliability.
An example is that I enabled those on the W3C checkers and a serious latent bug was discovered and fixed, even on code I wasn't familiar with.
I've found this greatly increases reliability.
An example is that I enabled those on the W3C checkers and a serious latent bug was discovered and fixed, even on code I wasn't familiar with.
United States District Court filing system for court cases is written in perl. Horrible language filled with one liners that only makes sense in the mind of the now retired and gone programmers. Sadly, I do not know why we cannot pursue other technologies. Perl is a trap... buyers will be stuck for 30 years. Like a mortgage, but without equity or returns.
You might want to go ahead and inform those investors who bought Amazon or Booking.com stock in the early 2000s that their orders of magnitudes of returns were really no such thing.
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 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.
I wrote a quick perl script earlier today to push crt.sh results for a bunch of domains into slack.
Took about 30 minutes, far less time than messing about with why pip has broken on my desktop yet again:
Took about 30 minutes, far less time than messing about with why pip has broken on my desktop yet again:
Traceback (most recent call last):
File "/usr/local/bin/pip", line 11, in <module>
sys.exit(main())
File "/usr/local/lib/python3.5/dist-packages/pip/_internal/cli/main.py", line 73, in main
command = create_command(cmd_name, isolated=("--isolated" in cmd_args))
File "/usr/local/lib/python3.5/dist-packages/pip/_internal/commands/__init__.py", line 96, in create_command
module = importlib.import_module(module_path)
File "/usr/lib/python3.5/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 986, in _gcd_import
File "<frozen importlib._bootstrap>", line 969, in _find_and_load
File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 673, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 665, in exec_module
File "<frozen importlib._bootstrap>", line 222, in _call_with_frames_removed
File "/usr/local/lib/python3.5/dist-packages/pip/_internal/commands/search.py", line 18, in <module>I understand no one wants to deal with unexpected issues, especially when you're trying to get something done. Why not use virtual environments? You keep packages out of your system's python, and if you run into issues like above you can just recreate it:
b5n:~/venv_dir$ python3 -m venv im_a_venv
b5n:~/venv_dir$ . im_a_venv/bin/activate
(im_a_venv)b5n:~/venv_dir$ pip install requests
(im_a_venv)b5n:~/venv_dir$ pip freeze > requirements.txt
(im_a_venv)b5n:~/venv_dir$ deactivate
b5n:~/venv_dir$ python3 -m venv another_venv
b5n:~/venv_dir$ . another_venv/bin/activate
(another_venv)b@b5n:~/venv_dir$ pip install -r requirements.txtThe reason I use linux and perl (or sometimes bash) - it just works, I get the least number of surprises. Dependencies in perl are handled by my OS same as everything else, I don't need to maintain multiple package managers, I just bash out the script and move on
I don't write software as an end goal, I write software to accomplish my end goal.
I don't write software as an end goal, I write software to accomplish my end goal.
While experienced python devs will say, yeah that'd how you should do it. The problem is that python by default isn't using virtualenvs. Consider rust or is where you need to specify global installs.
I spent 15 seconds trying to figure out how that 'Perl code' runs...
> 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 Perl that is super flexible and had a free version (more recently renamed to community edition since it detached a bit from their enterprise version).
It served us well enough that I have deployed it again on my current job when a similar but smaller need arose (both jobs in tourism industry). It's a pretty big and complex thing but does it's job well once configured correctly which does take a bit of work.
> 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.
That can possibly be the case here since it is "old" (changelog lists the first public beta at 2002) but has had pretty much continuous development until this day. Any company trying to develop something like this these days would probably choose something else but I guess they're a Perl shop now.
[0] - https://github.com/OTRS/otrs
[1] - https://otrs.com/
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 Perl that is super flexible and had a free version (more recently renamed to community edition since it detached a bit from their enterprise version).
It served us well enough that I have deployed it again on my current job when a similar but smaller need arose (both jobs in tourism industry). It's a pretty big and complex thing but does it's job well once configured correctly which does take a bit of work.
> 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.
That can possibly be the case here since it is "old" (changelog lists the first public beta at 2002) but has had pretty much continuous development until this day. Any company trying to develop something like this these days would probably choose something else but I guess they're a Perl shop now.
[0] - https://github.com/OTRS/otrs
[1] - https://otrs.com/
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 with the technical founder and he started the pre-decessor of OTRS in the 90s while working at SUSE, and yeah of course it was in Perl!
I must say that working on the quite significant OTRS code base, with proper code conventions, 'modern' perl5 is not so bad. But when using third party libraries sometimes you'd see arcane language usage and there seems lots of magic involved...
Also, the technical founder started https://zammad.org -- the same idea but started in 2012 or so. So now it's Ruby!
Modern perl5 is ok. But the ecosystem is slowly deteriorating.
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 with the technical founder and he started the pre-decessor of OTRS in the 90s while working at SUSE, and yeah of course it was in Perl!
I must say that working on the quite significant OTRS code base, with proper code conventions, 'modern' perl5 is not so bad. But when using third party libraries sometimes you'd see arcane language usage and there seems lots of magic involved...
Also, the technical founder started https://zammad.org -- the same idea but started in 2012 or so. So now it's Ruby!
Modern perl5 is ok. But the ecosystem is slowly deteriorating.
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.
Nice, thanks for the link and for your contributions to OTRS, it has improved workflows tremendously on both companies I've set it up on. I've messed around on some of the source and template files for some dirty hacks over the years and did get the impression of it being very well structured and with pretty clear separation of concerns even though I'm not a Perl coder.
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 programmers, the will create a new team to rewrite it badly because now they have no other choice. And of course the new folks are going to screw up, but that’s just expected.
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 programmers, the will create a new team to rewrite it badly because now they have no other choice. And of course the new folks are going to screw up, but that’s just expected.
> 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.
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.
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.
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.
> Python, Javascript, or C#
Those are all pretty basic Algol-family languages (at least if we're talking vaguely modern Javascript). If you were thrown in to J or Forth or Erlang you might have a different experience.
Those are all pretty basic Algol-family languages (at least if we're talking vaguely modern Javascript). If you were thrown in to J or Forth or Erlang you might have a different experience.
Funny enough, Erlang is my preferred language (or at least one of them).
I don't know if I'd necessarily call the JS in question "modern", though. It's running on RhinoScript, which needless to say ain't exactly the latest hotness. Still, the platform in question does happen to support/encourage AMD modules (with some special comments for certain components), so I guess it could be worse.
I don't know if I'd necessarily call the JS in question "modern", though. It's running on RhinoScript, which needless to say ain't exactly the latest hotness. Still, the platform in question does happen to support/encourage AMD modules (with some special comments for certain components), so I guess it could be worse.
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.
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?!!
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.
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.
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.
Lots of security patches and infrastructure are held hostage by breaking changes to APIs. Eventually you have to upgrade, and the longer you have put it off the more painful it will be.
And as we've seen with old video games, there are lots of timing problems that you simply never encounter on the original hardware but are impossible to ignore on recent vintage hardware.
And as we've seen with old video games, there are lots of timing problems that you simply never encounter on the original hardware but are impossible to ignore on recent vintage hardware.
There are plenty of silly reasons to rewrite a piece of code, but language preference has to be one of the worst.
Now that I think about it, that's actually a decent hiring test:
Tell the candidate part of their job will be maintaining a small Perl codebase. If they can't deal with that without throwing a fit, I have no interest in working with them.
It's a sharp tool, if you're not careful someone might get hurt. But professionals deal with sharp tools all the time, especially when it's the best tool for the job.
Now that I think about it, that's actually a decent hiring test:
Tell the candidate part of their job will be maintaining a small Perl codebase. If they can't deal with that without throwing a fit, I have no interest in working with them.
It's a sharp tool, if you're not careful someone might get hurt. But professionals deal with sharp tools all the time, especially when it's the best tool for the job.
the will create a new team to rewrite it badly because now they have no other choice
Given Perl’s legendary code-opacity and maintenance challenges, this kind of seems inevitable. After all, if you could at least read and decipher the old code, maybe you could reproduce it!
Given Perl’s legendary code-opacity and maintenance challenges, this kind of seems inevitable. After all, if you could at least read and decipher the old code, maybe you could reproduce it!
Lots of new things. Perl is an immensely powerful language. If you know how to write code well, it will be fully comprehensible by even casual programmers.
Many orgs ship perl based tools as current, up-to-date products. Mellanox OFED is one I was using earlier today.
My own github[1] has a plethora of perl projects.
[1] https://github.com/joelandman
Many orgs ship perl based tools as current, up-to-date products. Mellanox OFED is one I was using earlier today.
My own github[1] has a plethora of perl projects.
[1] https://github.com/joelandman
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.
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.
Hmm ... don't conflate the presentation UI with the underlying language. I wrote my companies website (2 jobs ago) in Mojolicious (perl web framework), with a responsive UI, based in part upon bootstrap. Very modern (for the time) UI. All backed by a very fast implementation.
IMDB seems plenty fast to me. UI isn't great, but that's more of a presentation layer design thing than a language thing.
IMDB seems plenty fast to me. UI isn't great, but that's more of a presentation layer design thing than a language thing.
I am not actually talking about the quality of the UI - I am just pointing out that the UI seems to have been the same for years now, and I would think a rewrite from Perl would have changed that. Yes, you can totally swap out the backend, but IMDB codebase is old. HTML and the sprinkled JS (if you look at page source) is probably baked in deep.
Nearly everything at Fastmail is in Perl. Cyrus, which is the mail storage engine, is in C (and open-source), but everything else is Perl.
OpenBSD uses Perl actively.
https://marc.info/?l=openbsd-misc&m=159041121804486&w=2
https://marc.info/?l=openbsd-misc&m=159041121804486&w=2
The primary use case of Perl is systems automation. Personally I prefer Node.js but most Linux distributions come with a Perl interpreter already installed and not Node. If you are working in an enterprise environment and for security reasons are not allowed to install software, which is common, you can still perform automation with Perl scripts.
Yes. You’ll be surprised. Some of the biggest tech companies still use Perl in their critical components in production, and some of the initiatives are in recent years.
I think the US Courts still use Perl for Pacer (https://www.pacer.gov/psco/cgi-bin/links.pl) and it seems to be used by the US Cours as well: https://ecf.azd.uscourts.gov/cgi-bin/ShowIndex.pl
> Are there actually people that are still deploying new things in Perl?
Anecdote: I found this Perl image-hosting package a couple years ago as a self-hosted alternative to sites like Imgur, and I think it's great: https://framagit.org/fiat-tux/hat-softwares/lutim/tree/maste...
Anecdote: I found this Perl image-hosting package a couple years ago as a self-hosted alternative to sites like Imgur, and I think it's great: https://framagit.org/fiat-tux/hat-softwares/lutim/tree/maste...
> Are there actually people that are still deploying new things in Perl?
See https://news.ycombinator.com/item?id=23593835
See https://news.ycombinator.com/item?id=23593835
IIRC Craigslist was written in Perl but that's the only high traffic site that comes to mind.
The Amazon retail site is written in perl (at least the presentation layer still is, you can find mason references still in the HTML source if you go looking, don't know how much else behind it is in perl).
https://metacpan.org/pod/Mason (if you're not familiar with Mason)
https://metacpan.org/pod/Mason (if you're not familiar with Mason)
Actually, that's Mason 2. Amazon use(s|d) the OG Mason - https://metacpan.org/release/HTML-Mason
Duck Duck Go and Booking.com were/are Perl backends.
The fashion retailer Net-A-Porter has been a Perl shop since 2000. Haven't checked if that's still the case. They used to employ quite a few leading lights in the UK Perl community a few years ago.
I think they still write everything in Perl, and they employ Larry Wall (or they did several years ago, last I heard)
duckduckgo, as far as I recall.
imdb.com is perl.
Most of the ad network backend sites are perl, including a lot of Yahoo.
Most of the ad network backend sites are perl, including a lot of Yahoo.
I used to work for a company that used Perl as their primary language.
The codebase was millions of lines long, modules (pm files) with like 1000 methods and 10,000 lines, a total mess and it had 0 unit tests too. Almost beyond salvageable. Left a bit of a sour taste.
They're trying to migrate to AWS but AWS don't even natively support Perl in their libraries. There's a few third party libraries in CPAN but nothing as comprehensive as what's available with official libraries for other languages.
Nothing against the language but I don't know why you wouldn't use literally anything else nowadays. Python or PHP, JavaScript or even Ruby if you're looking for a dynamically typed language. AWS don't even support Perl.
The codebase was millions of lines long, modules (pm files) with like 1000 methods and 10,000 lines, a total mess and it had 0 unit tests too. Almost beyond salvageable. Left a bit of a sour taste.
They're trying to migrate to AWS but AWS don't even natively support Perl in their libraries. There's a few third party libraries in CPAN but nothing as comprehensive as what's available with official libraries for other languages.
Nothing against the language but I don't know why you wouldn't use literally anything else nowadays. Python or PHP, JavaScript or even Ruby if you're looking for a dynamically typed language. AWS don't even support Perl.
Perl used to have one of the most extensive module libraries. One of the things I miss about Perl was it’s more sensible module namespace convention (Eg Net::... for networking related) vs the more hip but confusing and hard to discover naming of node modules.
Yes, the hierarchical namespace for modules was super nice. Migrating to a flattened package structure of npm was a disappointment. I ended up encoding the same type of structure in internal npm package names, e.g. "@myorg/net-aws-.." and "@myorg/file-..."
Keep in mind TDD wasn't really invented yet, so it's understandable.
Also, CPAN had better libraries than pip did all the way up until I last used Perl in 2015. Ofc, it depends on what you're doing. My point is, there was a reason to use Perl once upon a time ago.
The alternatives back then were PHP, C, C++ (the old bad kind), BASIC, assembly, FORTRAN, and others like Smalltalk. Seeing this, it's understandable why Java took the world by storm the same way Perl did.
Also, CPAN had better libraries than pip did all the way up until I last used Perl in 2015. Ofc, it depends on what you're doing. My point is, there was a reason to use Perl once upon a time ago.
The alternatives back then were PHP, C, C++ (the old bad kind), BASIC, assembly, FORTRAN, and others like Smalltalk. Seeing this, it's understandable why Java took the world by storm the same way Perl did.
I don't know about TDD specifically but we have the Perl community to thank for setting the bar for rigorous testing back in the ealry 2000s with the numerous Test:: modules on CPAN.
Perl and CPAN definitely do not get enough flowers for their contribution to TDD.
Last Perl shop I worked at was newer than the company you described but well on its way toward being like this.
Since Perl code is often very compact, it probably needs a higher comment to code ratio than most other languages, but you don't see that either.
Since Perl code is often very compact, it probably needs a higher comment to code ratio than most other languages, but you don't see that either.
Your opinion on Perl is based on one code base you worked at on one job?
Honestly that's more than most I think. I've written tens of thousands of lines of perl professionally and I generally share the same opinion.
I've been writing (Modern) Perl for about 3.5 years and I disagree that Perl necessarily tends to unreadable code. I really don't think that's true at all.
To quote myself from a recent discussion:
I think some languages do make it easy to write convoluted code, but through judicious use of coding standards (including a helping of common sense [don't be clever where you can at all avoid it, which IME is ~~almost~~ all the time], code linters, and so on) I think how you use a language plays a huge part in code maintainability.
For instance, I've heard PHP get shit on pretty badly all around the web, but I've worked at PHP shops that had nice, clean codebases, and my current Perl codebase is, in many ways, nicely structured. That's not to say there aren't some hairy codepaths that could use refactoring, but I really think that kind of thing, again, can happen in almost any language.
To quote myself from a recent discussion:
I think some languages do make it easy to write convoluted code, but through judicious use of coding standards (including a helping of common sense [don't be clever where you can at all avoid it, which IME is ~~almost~~ all the time], code linters, and so on) I think how you use a language plays a huge part in code maintainability.
For instance, I've heard PHP get shit on pretty badly all around the web, but I've worked at PHP shops that had nice, clean codebases, and my current Perl codebase is, in many ways, nicely structured. That's not to say there aren't some hairy codepaths that could use refactoring, but I really think that kind of thing, again, can happen in almost any language.
I think a useful concept is that a project will have a "discipline budget", just like the "language strangeness budget". Yes, if you're careful with your self-restraint and code reviews, you can write good, clean, maintainable code in a language that doesn't give you a lot of support for that. But if you do that then you're expending your limited supply of discipline, and will have less to spend on other aspects of the project like not scaling prematurely, not using cool-but-unnecessary tech...
Very interesting thought! I think I'll steal it.
Strongly agreed. It’s much more about the team, the conventions used, the organization of the codebase, and the coding culture of the team, than it is about a specific language.
True, but the cultures that grow up around a specific language tend to encourage certain conventions, standards of organization, and team coding cultures.
Under that standard it’s true, but it’s also true for virtually any language and is therefore not a good defense of whether or not a language lends itself to unreadable code.
There are a couple of points in there:
1. You can use virtually any language to write clean code
Not sure if I agree with this, though it may well be true. I just know there are some things like Brainfuck where it's designed to be impossible. I realize that language is created specifically for the purpose of making a coder say "WTF", but perhaps there are other languages that are not designed to be so that are really nearly impossible to write good code in.
2. Perl lends itself to unreadable code
If you stick to Modern Perl you still might end up with things like `wantarray` in your code so I guess this is kind of true. You need to be judicious in your use of code.
Some languages lend themselves more easily to writing clean code, like I feel about Go or if you hate the Go type system, Ruby. Even in Ruby I feel like metaprogramming is ripe for misuse.
It's a tough thing to talk about. I don't feel like I wholeheartedly disagree with your sentiment which seems to be "some languages lend themselves to bad code" and subsequently that Perl lends itself to bad code but there is plenty of ambiguity in these thoughts.
1. You can use virtually any language to write clean code
Not sure if I agree with this, though it may well be true. I just know there are some things like Brainfuck where it's designed to be impossible. I realize that language is created specifically for the purpose of making a coder say "WTF", but perhaps there are other languages that are not designed to be so that are really nearly impossible to write good code in.
2. Perl lends itself to unreadable code
If you stick to Modern Perl you still might end up with things like `wantarray` in your code so I guess this is kind of true. You need to be judicious in your use of code.
Some languages lend themselves more easily to writing clean code, like I feel about Go or if you hate the Go type system, Ruby. Even in Ruby I feel like metaprogramming is ripe for misuse.
It's a tough thing to talk about. I don't feel like I wholeheartedly disagree with your sentiment which seems to be "some languages lend themselves to bad code" and subsequently that Perl lends itself to bad code but there is plenty of ambiguity in these thoughts.
In my 30 years (yes) working with Perl (4->5.32), I have never, once, used wantarray. Perl does not lend itself to bad code. Bad coders, people whom cannot use or articulate good practice in coding or documentation, lend themselves to write bad code, in any language.
I used it for automation of my calculations in grad school. For data analysis. For monitoring.
In my subsequent day jobs, I used it to develop shipping products. No one really should care what language something is written in, if it does the job well.
Most recently (a few weeks ago), I used it as the driver for creating and submitted 10's of thousands of jobs for COVID19 research the team I am working with[1][2].
For the above project, I had to forward port 12 year old C++ code to make use of modern C++ based boost libraries. Took a bit of time to fix this. But the perl code, ran perfectly, and quickly[3].
Anyone trying to portray things otherwise, likely has a longstanding axe they like to grind. Language advocacy can be done without attempting to tear down other languages. Though those who argue against perl often bring up the same, old, tired, and incorrect points.
I'll keep using perl thank you. And Julia. And C. Each has their domain of applicability. Most people know and understand this.
[1] https://community.hpe.com/t5/advantage-ex/how-my-supercomput...
[2] https://community.hpe.com/t5/advantage-ex/the-story-of-how-i...
[3] https://scalability.org/2020/04/fun-and-topical-hpc-project-...
I used it for automation of my calculations in grad school. For data analysis. For monitoring.
In my subsequent day jobs, I used it to develop shipping products. No one really should care what language something is written in, if it does the job well.
Most recently (a few weeks ago), I used it as the driver for creating and submitted 10's of thousands of jobs for COVID19 research the team I am working with[1][2].
For the above project, I had to forward port 12 year old C++ code to make use of modern C++ based boost libraries. Took a bit of time to fix this. But the perl code, ran perfectly, and quickly[3].
Anyone trying to portray things otherwise, likely has a longstanding axe they like to grind. Language advocacy can be done without attempting to tear down other languages. Though those who argue against perl often bring up the same, old, tired, and incorrect points.
I'll keep using perl thank you. And Julia. And C. Each has their domain of applicability. Most people know and understand this.
[1] https://community.hpe.com/t5/advantage-ex/how-my-supercomput...
[2] https://community.hpe.com/t5/advantage-ex/the-story-of-how-i...
[3] https://scalability.org/2020/04/fun-and-topical-hpc-project-...
Yeah, I've got a Perl codebase that's conservatively tens of thousands of lines, and it's honestly a struggle to write anything in it that isn't a big ball of mud. There's about 50 different ways to do anything in the language, the syntax is infuriatingly obtuse, and you can't rely on any documentation because it will recommend doing things that experts don't recommend doing.
The system is from like 2013 and still going, but I really wish I could rewrite it in a language I can actually train people on in a reasonable amount of time. It took the one junior I have about 6 months to get to the point where he could read the syntax without tearing his hair out. It's not really built to create maintainable structures.
The libraries and stuff are full of opinionated little "gotchas." As an example, the Test::Simple module will throw errors if you use a number to title a test which is infuriating when you're writing a test which tests all the numbers in the space of acceptable or possible inputs.
The system is from like 2013 and still going, but I really wish I could rewrite it in a language I can actually train people on in a reasonable amount of time. It took the one junior I have about 6 months to get to the point where he could read the syntax without tearing his hair out. It's not really built to create maintainable structures.
The libraries and stuff are full of opinionated little "gotchas." As an example, the Test::Simple module will throw errors if you use a number to title a test which is infuriating when you're writing a test which tests all the numbers in the space of acceptable or possible inputs.
Perl's syntax is really confusing.
Especially for example how variables have symbols for different types ($ for scalars, % for hashes, @ for arrays). And if you want to for example pass an array to a function you have to send it manually referenced with like method(\@myArray) which then inside the method is contained in a $scalar.
Compared to Python for example where you'd literally just pass the array to the method like method(array).
Especially for example how variables have symbols for different types ($ for scalars, % for hashes, @ for arrays). And if you want to for example pass an array to a function you have to send it manually referenced with like method(\@myArray) which then inside the method is contained in a $scalar.
Compared to Python for example where you'd literally just pass the array to the method like method(array).
For many years Perl subroutines didn't even have method signatures so you had to unroll @ on the first line of every sub. I think even today it may still be considered experimental. Jeez!
The reason for the @_ is that it is a simple way to get both pass by value and pass by reference semantics.
The values in @_ are aliased to the values in the subroutine call.
Most of the time, you want pass by value semantics, so you unpack the array and copy the values into function variables. If you want to modify an argument, it's typically passed in as a reference, and you can mess with it that way.
However, there are times when it would be horribly inefficient to make those copies, or when you need to do some magic (generally best avoided in 99.999% of your code), that this makes possible.
Also, since Perl functions are always variadic, it means that it's easy to work with a variable list of arguments in a function. For example, if you are expecting a list of key value pairs for your function, you can simply write:
The values in @_ are aliased to the values in the subroutine call.
Most of the time, you want pass by value semantics, so you unpack the array and copy the values into function variables. If you want to modify an argument, it's typically passed in as a reference, and you can mess with it that way.
However, there are times when it would be horribly inefficient to make those copies, or when you need to do some magic (generally best avoided in 99.999% of your code), that this makes possible.
Also, since Perl functions are always variadic, it means that it's easy to work with a variable list of arguments in a function. For example, if you are expecting a list of key value pairs for your function, you can simply write:
my %args = @_
Yeah it's pretty archaic. Shortest hand way of doing it is like this:
sub method {
my ($self, $a, $b, $c) = @_;
}
$self is only for OOP so not needed in a regular subroutine.
> Compared to Python for example where you'd literally just pass the array to the method like method(array).
How does one tell Python to pass the contents of said array as distinct parameters to the function, instead of as a lone array parameter?
In Perl, that's the difference between foo(@bar) and foo(\@bar) or foo(1, 2, 3) vs foo([1, 2, 3]).
How does one tell Python to pass the contents of said array as distinct parameters to the function, instead of as a lone array parameter?
In Perl, that's the difference between foo(@bar) and foo(\@bar) or foo(1, 2, 3) vs foo([1, 2, 3]).
> How does one tell Python to pass the contents of said array as distinct parameters to the function, instead of as a lone array parameter?
With an asterisk: method(*array)
With an asterisk: method(*array)
Right, which I sorta kinda get why coming from C - a *something is the thing pointed to by that something.
How is that more understandable than @ vs \@ without knowing the language? My guess is it isn't.
How is that more understandable than @ vs \@ without knowing the language? My guess is it isn't.
Python is "relatively" consistent about * and being used to expand or contract arrays and dicts, respectively.
But the more important bit is just that you don't have to prefix variables with @ and $. Python is optimized for writing code that acts on variables, while perl is optimized for code that acts on strings. While strings are certainly a common data type, most code isn't modifying strings directly. So optimizing for that case doesn't make a lot of sense.
a, *, b = [1,2,3,4]
def foo(*args):
bar(*[1,2,3])
But the more important bit is just that you don't have to prefix variables with @ and $. Python is optimized for writing code that acts on variables, while perl is optimized for code that acts on strings. While strings are certainly a common data type, most code isn't modifying strings directly. So optimizing for that case doesn't make a lot of sense.
As someone who learned python first - the idea that `myfn(@xs)` would call `myfn(1,2,3)` is... unnerving. Implicitly splicing in arguments makes me wonder what other kind of syntactic oddities are going over my head in my code.
a = [1]
def f(b):
f(*a)
def f(b):
print(b)
f(*a)
I can say the same thing about a legacy Java codebase that I had to work with at a big "enterprise" software company a few years ago. The code was so convoluted, with some files over 12k lines long. You can write spaghetti code in any language.
How much and what kind of experience do you think someone should have with a language before beginning to form an opinion?
They mention aws library support as another major concern too.
> There's a few third party libraries in CPAN but nothing as comprehensive as what's available with official libraries for other languages.
That is true. This alone might be a good reason to look elsewhere for new projects.
However, for existing Perl codebases, PAWS is comprehensive and popular library, and is generated from the official botocore: https://github.com/pplu/aws-sdk-perl
That is true. This alone might be a good reason to look elsewhere for new projects.
However, for existing Perl codebases, PAWS is comprehensive and popular library, and is generated from the official botocore: https://github.com/pplu/aws-sdk-perl
> There's a few third party libraries in CPAN but nothing as comprehensive
There's 194,000 modules, which is probably the most of any language:
https://www.cpan.org/
> Nothing against the language but I don't know why you wouldn't use literally anything else nowadays.
Gee, let me see:
- Perl's Mojolicious web framework is probably the most powerful today.
https://mojolicious.org/
- Perl has moderate static typing with use strict;
- Perl allows forward references, unlike Javascript or Python.
The question is why would I use anything but Perl?
There's 194,000 modules, which is probably the most of any language:
https://www.cpan.org/
> Nothing against the language but I don't know why you wouldn't use literally anything else nowadays.
Gee, let me see:
- Perl's Mojolicious web framework is probably the most powerful today.
https://mojolicious.org/
- Perl has moderate static typing with use strict;
- Perl allows forward references, unlike Javascript or Python.
The question is why would I use anything but Perl?
It is alive and kicking in the bioinformatics community!
I still think Perl is a much better tool for what some bash and python scripts are doing. Maybe Perl7 will remove some stigma and allow for people to use the tool instead of it being instantly dismissed.
I still think Perl is a much better tool for what some bash and python scripts are doing. Maybe Perl7 will remove some stigma and allow for people to use the tool instead of it being instantly dismissed.
Yep, I know of one company still actively using Perl for a large part of its infrastructure. It has its use cases.
One that is definitely still using Perl in a very big way is https://www.ariba.com/
Ariba isn't a household name, but it has deep and widespread connections to thousands of the largest companies in the world.
Ariba isn't a household name, but it has deep and widespread connections to thousands of the largest companies in the world.
Are they named after a very large tropical rainforest?
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).
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).
I'm working through the Llama book, seems like a fun alternative to Python.
Perl is used extensively in the enterprise solutions we deliver for our client.
I write new things in Perl all the time. Deploying highly functional backend services using Mojolicious, a framework which is VERY actively developed.
My full-time job is working a codebase where the back-end is entirely written in perl. Codebase was started around 2014. This was probably a bad decision, the founder was a perl guy.
Perl is not bad but no new codebases should ever be written in it imo. It's to easy to shoot yourself in the foot unless you know perl REALLY well. Moose is ok but a far-cry from any modern OOP system.
Perl is not bad but no new codebases should ever be written in it imo. It's to easy to shoot yourself in the foot unless you know perl REALLY well. Moose is ok but a far-cry from any modern OOP system.
Yes, I manage a set of tools and libraries written in perl that are pretty large and service the whole company. That said we're re-writing them all to Python so more people can contribute... Saddens me a little I like Perl, but I'll get over it.
yes, definitely. If you are manipulating text, Perl is great.
A lot of Debian's packaging tools are written in Perl.
Yes. The entire backend to my startup is Perl 5 (Mojolicious) + postgresql (albeit the postgresql part is obviously more important).
I do.
Efficient, cheap and stable. Ported to about everywhere.
Efficient, cheap and stable. Ported to about everywhere.
What do you mean by efficient and cheap? It doesn't fare well in https://benchmarksgame-team.pages.debian.net/benchmarksgame/... at least.
There’s something fishy about that report. It says it is presenting the fastest programs, but when I click through to “all perl programs”, there are faster (often by 1-2 orders of magnitude) programs / runs:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
For instance, the page you linked has “pidigits” at the top, and says node is faster, 2.58s vs 3.61.
2.58s is the slowest run of the fastest pidigits on the node page, but one of its runs took 1.04 seconds.
The perl page lists a 1.24 second run for “pidigits 2”.
The reported numbers in the language comparisons don’t seem to be averages.
All the pidigits programs list the same output, so presumably, they’re running with the same ‘N’.
Between the variance and inexplicable stats being applied to the results, I’m not sure what to conclude from these numbers.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
For instance, the page you linked has “pidigits” at the top, and says node is faster, 2.58s vs 3.61.
2.58s is the slowest run of the fastest pidigits on the node page, but one of its runs took 1.04 seconds.
The perl page lists a 1.24 second run for “pidigits 2”.
The reported numbers in the language comparisons don’t seem to be averages.
All the pidigits programs list the same output, so presumably, they’re running with the same ‘N’.
Between the variance and inexplicable stats being applied to the results, I’m not sure what to conclude from these numbers.
> There’s something fishy about that report.
No, there really isn't.
> 2.58s is the slowest run of the fastest pidigits on the node page, but one of its runs took 1.04 seconds.
Notice column N — 2,000 6,000 10,000.
That's a command line argument passed to each program, controlling how many digits of pi are generated — the workload.
So, 2.58s for 10,000 digits and 1.04s for 6,000.
(And as it says, there can be a cold caches effect on the first measurements.)
No, there really isn't.
> 2.58s is the slowest run of the fastest pidigits on the node page, but one of its runs took 1.04 seconds.
Notice column N — 2,000 6,000 10,000.
That's a command line argument passed to each program, controlling how many digits of pi are generated — the workload.
So, 2.58s for 10,000 digits and 1.04s for 6,000.
(And as it says, there can be a cold caches effect on the first measurements.)
Nodejs is very fast, because it uses an an engine that has had multiple millions of dollars thrown at it to make it fast. Most interpreted languages don't fare well against it.
Perl fares somewhat favorably against Python, Ruby and PHP though. Those are what I would consider equivalent languages to compare against to get a general idea of its speed.
Perl fares somewhat favorably against Python, Ruby and PHP though. Those are what I would consider equivalent languages to compare against to get a general idea of its speed.
>multiple millions of dollars
I can pretty much assure you the accumulated dollars invested over the years in making JS fast is likely to be closer to multiple billions combined.
I can pretty much assure you the accumulated dollars invested over the years in making JS fast is likely to be closer to multiple billions combined.
You don't hear about it, but Perl has had many millions thrown at it too.
JS is probably closer to billions.
Not just orders of magnitude more money, but more importantly the large number of incredibly talented people working full time on JavaScript, in many different companies and research institutions, collaborating together. JavaScript benefits from an overwhelming network effect and critical mass of tools and developers, that Perl just can't touch, and never will.
Unfortunately it does not change bad parts.
Depends on what you mean by "fare well". Even in those benchmarks, Perl seems to have a lower memory footprint than Node.js in most of the results.
It's also worth noting that three of the examples (pidigits, reverse-complement, fasta) don't seem to do any multiprocessing in Perl whereas they do in Node.js. At least for reverse-complement and fasta, it should be possible to rewrite those to use multithreading (like the Node.js versions do).
It's also worth noting that three of the examples (pidigits, reverse-complement, fasta) don't seem to do any multiprocessing in Perl whereas they do in Node.js. At least for reverse-complement and fasta, it should be possible to rewrite those to use multithreading (like the Node.js versions do).
> should be possible to rewrite those
Until someone does…
Until someone does…
What do you mean by cheap? Also, perl is incredibly inefficient: it's even slower than Python.
Also, how is Perl any less stable than other languages? Are you saying the language doesn't change much or that it doesn't crash?
Also, how is Perl any less stable than other languages? Are you saying the language doesn't change much or that it doesn't crash?
On my 4-core i7 Macbook Pro:
time ./startup_time.pl 0.016s
time ./startup_time.py 0.295s
time ./parse_log.pl 0.683s
time ./parse_log.py 1.534s
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, '<', 'logs1.txt';
while (<$fh>) {
chomp;
say if /\b\w{15}\b/;
}
close $fh;
#!/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='')
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='')
With pre-compiled regex the Python version comes down to 1.483s on my machine which is still considerably slower than Perl. I wrote versions of these using substring `index` instead of a regex and Perl was still the clear winner:
time ./index.pl 0.258s
time ./index.py 0.609s
I'd be curious on your take of my code below, I have python and perl as dead even if you don't print and ignore pythons startup time.
Well, the two ifs you hedge to qualify Python's parity are pretty damning in themselves, no? Let's stop beating about the bush - if you want to perform a common text-processing job like parsing a log file Perl is hands down faster than Python.
Python caches patterns, you almost never need to re.compile unless you’re a library or have a specific use case involving lots of unique patterns.
The issue here is that pythons regex engine has overhead, and with lots of sequential calls with small strings like that the overhead adds up.
If you batch lines together in chunks you’ll see a huge improvement in speed, but the point is that it’s not “Python vs Perl” it’s “pythons regex engine vs Perl’s regex engine”. Which is about a contrived Perl-biased benchmark if ever there was one.
The issue here is that pythons regex engine has overhead, and with lots of sequential calls with small strings like that the overhead adds up.
If you batch lines together in chunks you’ll see a huge improvement in speed, but the point is that it’s not “Python vs Perl” it’s “pythons regex engine vs Perl’s regex engine”. Which is about a contrived Perl-biased benchmark if ever there was one.
Running a different test the slowest part of the python script is the startup time, otherwise they're identical:
[admin@localhost ~]$ time ./test.py
real 0m0.295s
user 0m0.158s
sys 0m0.138s
[admin@localhost ~]$ time ./test.pl
real 0m0.164s
user 0m0.158s
sys 0m0.006s
#!/usr/bin/env perl
use 5.16.3;
open my $fh, '<', 'logs1.txt';
while (<$fh>) {
chomp;
if (/\b\w{15}\b/) {}
}
close $fh;
#!/usr/bin/env python
import re
regex = re.compile(r'\b\w{15}\b')
with open('logs1.txt', 'r') as fh:
for line in fh:
if regex.search(line):
continueI took some similar benchmarks recently: https://code.ivysaur.me/interpreter-binary-perf
Perl5 won the dec2bin benchmark.
The other thing I learned was that PHP's binary/decimal functions are two orders of magnitude slower, despite its core interpreter performance being best-in-class.
Perl5 won the dec2bin benchmark.
The other thing I learned was that PHP's binary/decimal functions are two orders of magnitude slower, despite its core interpreter performance being best-in-class.
On the other hand PHP has a PCRE jit option which manages to beat even Perl's regex implementation.
Yes but you can use that jit also with perl5.
https://metacpan.org/pod/re::engine::PCRE2
It has even less backcompat problems than the native regex.
It has even less backcompat problems than the native regex.
> it's even slower than Python.
It's faster at some things and slower at others. It's fairly similar in speed profile to Python in my eyes.
> Are you saying the language doesn't change much or that it doesn't crash?
Both is probably what was meant. They are literally changing the major version so they can change some backwards compatibility, as Perl has made strong backwards compatibility a goal and selling point for decades. You can take a script written in 2000, and it will likely run without problem if you run it on a Perl 5.30, released last year.
It's faster at some things and slower at others. It's fairly similar in speed profile to Python in my eyes.
> Are you saying the language doesn't change much or that it doesn't crash?
Both is probably what was meant. They are literally changing the major version so they can change some backwards compatibility, as Perl has made strong backwards compatibility a goal and selling point for decades. You can take a script written in 2000, and it will likely run without problem if you run it on a Perl 5.30, released last year.
- Efficient: from prototype to deployment, it's a matter of days. The choice of styles let people use paradigms they are familiar with, meaning they do things quickly.
- Cheap: it does not cost much to hire someone to write perl. If they don't know how yet, the choice in style let them be efficient quickly. The code to be deployed is very lightweight, both in CPU and RAM usage.
- Stable: no API break. No new module that reinvent the wheel and breaks your codebase. Unit testing is about everywhere in cpan. Code written 20 years ago still run fine.
- Cheap: it does not cost much to hire someone to write perl. If they don't know how yet, the choice in style let them be efficient quickly. The code to be deployed is very lightweight, both in CPU and RAM usage.
- Stable: no API break. No new module that reinvent the wheel and breaks your codebase. Unit testing is about everywhere in cpan. Code written 20 years ago still run fine.
The reason that code written 20 years ago still runs fine is that they rolled back 20 years of changes!
This is a pointless attack. The modules available on CPAN usually have a strong emphasis on backwards compatibility.
> Also, perl is incredibly inefficient: it's even slower than Python.
That's debatable for single-threaded workloads (they're typically pretty comparable in my observation), and highly unlikely for multi-threaded workloads (Python has a global interpreter lock whereas Perl does not AFAICT; you can work around that in Python, but it typically involves spawning entirely separate processes, thus introducing IPC overhead that wouldn't be present in a Perl equivalent).
Looking at some comparative benchmarks (https://benchmarksgame-team.pages.debian.net/benchmarksgame/...), Perl seems to be faster in a slight majority of cases, and in nearly all cases has a lower memory overhead. Not that benchmarks really matter anyway, given that they're usually a poor indicator of real-world performance, but still.
That's debatable for single-threaded workloads (they're typically pretty comparable in my observation), and highly unlikely for multi-threaded workloads (Python has a global interpreter lock whereas Perl does not AFAICT; you can work around that in Python, but it typically involves spawning entirely separate processes, thus introducing IPC overhead that wouldn't be present in a Perl equivalent).
Looking at some comparative benchmarks (https://benchmarksgame-team.pages.debian.net/benchmarksgame/...), Perl seems to be faster in a slight majority of cases, and in nearly all cases has a lower memory overhead. Not that benchmarks really matter anyway, given that they're usually a poor indicator of real-world performance, but still.
I believe MoveGB is running a perl backend.
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.
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'm not anywhere retiring yet, but when Python came around the corner, I thought, well it's as well-suited as Perl for larger things (i.e. not one-liners for text processing - those are a reason for keeping Perl around) but with a cleaner structure.
And that was at a time where you still (occasionally) had to write your own string replacement function that a weirdo company-specific BASIC dialect didn't have.
There's never been a language that I thought of as "Python, but with a cleaner structure", even though Go may be something like "Java 1.2 but with a cleaner structure and a fast toolchain"
And that was at a time where you still (occasionally) had to write your own string replacement function that a weirdo company-specific BASIC dialect didn't have.
There's never been a language that I thought of as "Python, but with a cleaner structure", even though Go may be something like "Java 1.2 but with a cleaner structure and a fast toolchain"
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.
TIMTOWTDI="There is more than one way to do it"
[deleted]
Feel the same about the above.
I would add that Perl is still the best for one liners since you don't need to "import" key packages to do basic work e.g. you can regexes in a Perl one liner with no imports.
I would add that Perl is still the best for one liners since you don't need to "import" key packages to do basic work e.g. you can regexes in a Perl one liner with no imports.
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.
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.
> ask us
What's the best way to do that these days? IRC was the most active Perl place back in the day and the best place to get help, where's the best place for people to ask for help these days?
What's the best way to do that these days? IRC was the most active Perl place back in the day and the best place to get help, where's the best place for people to ask for help these days?
Once this is out, I'll be interested in any well written guides or books, it has always felt like "the one that got away" to me.
Back in 2002 I had to choose between learning between Python and Perl for a project, but "everybody knew" Perl 5 was soon going to be replaced by a new shiny different Perl 6, so I chose Python.
It will be interesting to see where Perl can live and gain new users nowadays. Python has so much become the "default scripting language", and has so many bindings and libraries.
Back in 2002 I had to choose between learning between Python and Perl for a project, but "everybody knew" Perl 5 was soon going to be replaced by a new shiny different Perl 6, so I chose Python.
It will be interesting to see where Perl can live and gain new users nowadays. Python has so much become the "default scripting language", and has so many bindings and libraries.
I think you can learn most/all of Perl 5.32 with http://modernperlbooks.com/books/modern_perl_2016/ , and it appears this is, initially, going to be 5.32 with some saner defaults. So you could really start now, given that.
> This beloved guide is now completely updated for Perl 5.22.
I've been working with Perl since about 5.20 and am on 5.31 or 5.32 and haven't noticed many breaking changes FWIW.
> This beloved guide is now completely updated for Perl 5.22.
I've been working with Perl since about 5.20 and am on 5.31 or 5.32 and haven't noticed many breaking changes FWIW.
The 2016 edition covers most of what's in 5.32; if I were to do an update for Perl 5.32, I'd include postfix dereferencing and the built-in function signature mechanisms now that they're very stable and supported.
The Osborne effect for languages. Now there's no risk in announcing version 7 since effectively everyone who was going to choose Perl already chose Python (or Javascript).
https://en.wikipedia.org/wiki/Osborne_effect
https://en.wikipedia.org/wiki/Osborne_effect
There's also the Ozzy Osbourne effect for programming languages:
I've listened to preachers
I've listened to fools
I've watched all the dropouts
Who make their own rules
One person conditioned to rule and control
The media sells it and you live the role
Mental wounds still screaming
Driving me insane
I'm going off the rails on a crazy train
I'm going off the rails on a crazy trainI already have Preparing for Perl 7 on LeanPub (https://leanpub.com/preparing_for_perl7)
Much as people complain about Perl, it is the language which I use when I want to have something which will run 10-20 years from now.
I recently wrote a consistency checker for file archives (so that I know when bitrot sets in) in Perl, precisely because I want it to be usable for a long time (https://github.com/jwr/ccheck).
Very happy to see a path forward for Perl 5.32.
I recently wrote a consistency checker for file archives (so that I know when bitrot sets in) in Perl, precisely because I want it to be usable for a long time (https://github.com/jwr/ccheck).
Very happy to see a path forward for Perl 5.32.
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/
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
Yes, dependencies are a bit of a problem (I tried to use as few as possible in ccheck), but I'd say that the general culture of CPAN is to keep things long-term and prevent breakage, so my experience has been fairly good over the last 25 years. Something I can't say for node.js.
I don't understand what you mean exactly – couldn't you use any language, even javascript, exactly the same version as you use right now, in 2100? Why not?
Edit: nice tool, by the way!
Edit: nice tool, by the way!
Have you tried? :-) Especially in the JavaScript world, things evolve so quickly, that they become obsolete within single years. If you use node and npm, within months.
To put this in contrast, Perl 5.001 was released on March 13, 1995 — that's more than 25 years ago, and code written in it will largely run fine today.
To put this in contrast, Perl 5.001 was released on March 13, 1995 — that's more than 25 years ago, and code written in it will largely run fine today.
Perl is still unmatched for one-liners, and by extension, one-liners that graduate to short scripts.
Yes, of all the Perl books in my collection Tim Maher's "Minimal Perl" (Manning) is still the one I dip into regularly.
Thinking about this some more, I now feel really sad for anyone who doesn't use perl (i.e., almost everyone). Its immense power at the command line is something they'll never experience. Nothing today even comes close.
Even sadder that no-one will probably now start their programming career, as I did, with Perl as their first language. I feel honoured. At the time it was a toss-up between Java, which my house-mate was using every day to write banking apps at work, or Perl - that funky linguistic creation which granted you magical powers. No contest.
Perl has these tiny neat features that I still miss in other languages. Like unless (opposite of if), and postfix syntax.
print "It worked!\n" unless $error;
print "Item: $_\n" foreach @items;Ruby has some of these, too, thanks to its Perl heritage.
puts "It worked!" unless error
i = 0; puts "Item: #{i+=1}" while i < 5
items.each {|i| puts "Item: #{i}"}Until some joker writes an unless/else block. Gah. I hope someone implements an elsunless keyword /s
I've never been a fan of unless blocks (as opposed to the unless postfix, which is a bit easier to swallow). The lower precedence spelled out boolean operators (not/and/or) mean you can just use if not instead, which is just as readable in most cases and isn't confusing in the else case.
e.g.
e.g.
unless ( $foo ) { }
if ( not $foo ) { }yeah I tend to avoid unless - definitely in blocks, but it's ok for some postfixes
I find this:
I agree that unless/else blocks are quite unhelpful. The double negative doesn't help.
That said I am guilty of writing some unless/else blocks, but the reason is always performance. "unless ($x)" is faster than "if (!$x)". Only one opcode faster, but in something optimised for speed that's a few percent, and therefore a goal, especially if there are many of them. For something like "++$y unless $flag" it's more than a few percent.
As with many other things in Perl, and other languages in the "slow" class (Python, Ruby etc), there are no dataflow optimisations. Things like "my $x; $x = 1" are slower than "my $x = 1;". Yet still there are times when something is worth doing faster, without the big jump of rewriting in a different language.
That's completely different from the "fast" languages, like C, C++, C#, and nowadays JavaScript. I've come to appreciate that I wish all languages did trivial dataflow optimisations and inlining, even if they are in every other respect interpreted languages, because absence of dataflow motivates people to write uglier and more difficult to understand code in tight hotspots, when code clarity would be really valuable.
error "The eggs are not in their basket"
unless $eggs_in_basket;
error "The eggs are not in their basket"
if !$eggs_in_basket;
I agree that unless/else blocks are quite unhelpful. The double negative doesn't help.
That said I am guilty of writing some unless/else blocks, but the reason is always performance. "unless ($x)" is faster than "if (!$x)". Only one opcode faster, but in something optimised for speed that's a few percent, and therefore a goal, especially if there are many of them. For something like "++$y unless $flag" it's more than a few percent.
As with many other things in Perl, and other languages in the "slow" class (Python, Ruby etc), there are no dataflow optimisations. Things like "my $x; $x = 1" are slower than "my $x = 1;". Yet still there are times when something is worth doing faster, without the big jump of rewriting in a different language.
That's completely different from the "fast" languages, like C, C++, C#, and nowadays JavaScript. I've come to appreciate that I wish all languages did trivial dataflow optimisations and inlining, even if they are in every other respect interpreted languages, because absence of dataflow motivates people to write uglier and more difficult to understand code in tight hotspots, when code clarity would be really valuable.
Yeah, I hear you. I actually use `doit() unless $something;` quite often, but then change it to `doit() if ! ($something || $something_else )` immediately the need arises. That is I always think about it when I"m writing an unless statement.
I spent much of my career working primarily in Perl. Now I use it when messing around with older codebases, but not for new work. However, I still use it pretty often for one-liners because of these neat features. For instance:
perl -E 'say for grep {/o/} @ARGV' one two threeI hate unless! It always makes me stop and think a few times, causing double or even triple negatives in my brain. What's wrong with something like "print this if not $error"?
Maybe that's because I'm not a native English speaker?
Maybe that's because I'm not a native English speaker?
I am not native English speaker but I like it in ruby, helps with double not:
if not not_implemented
unless not_implementedWell, print this if not $error doesn't work in most modern languages either. It's
if not error:
print thisI miss those too and I'm constantly annoyed Python doesn't have more one liner support.
My very first program was:
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?
perl -e 'print int rand(10);'
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?
> PHP went directly from 5 to 7, and isn’t it time to steal something from that community?
:D
:D
There was a php6... we just do not talk about it. There is a perl 6 also.
There was a perl 6, but it is no longer perl, though it's still 6.
No, there isn't. Perl 6 got renamed to Raku (https://raku.org using the #rakulang tag on social media). There's a weekly blog post should you want to stay up-to-date: https://rakudoweekly.blog
I love perl, so I’ll definitely spend some time tonight trying to find out more about the plans. From just this article, it’s hard to see how this is different than just making ‘use v5.34;’ flip some switches. That’s just business as usual in modern perl, even if it changed more things than normal. Still, if bumping the major version gets people to take another look at it, it will be a good thing. And maybe there are bigger plans post-7.0 and this is just to ease the initial move.
They are making some space for (controlled) breaking changes. It also sends a message that Perl has a clear path going forward. I'll consider it for my next projects, especially the automation ones.
Great. Perl is not my favorite language, but the things its good at and the body of nifty code out there deserve more recognition than they get. Hopefully this will remove some of the discouragements to curiosity that have kept people from looking harder at perl to see if it fits their problems or their mind better than other tools.
I write perl professionally as of June 2020 (and I have been writing software in Perl since 1999). Never felt the need to use Python, or any other language for anything I do.
People who use my (mostly) Perl based software on AWS and GCP Marketplaces today are somewhat surprised and/or even taken aback when they find out it is written in Perl. So, I try not to mention that.
People who use my (mostly) Perl based software on AWS and GCP Marketplaces today are somewhat surprised and/or even taken aback when they find out it is written in Perl. So, I try not to mention that.
There used to be a big Python/Perl debate. I'm not sure I could have predicted how well that would turn out for Python, and how poorly for Perl. Readability and ease of use matters?
I think it was really Perl 6 that killed it. Perl had a significant lead over Python, and the Perl 6 announcement just sucked the life out of it.
It wasn't the language, it was Numpy. Everything that is built on top of Numpy is what made Python so popular.
And I guess Perl also never had its Django (or Rails).
And I guess Perl also never had its Django (or Rails).
In my opinion, those are results of Perl losing mindshare. Numpy is not exactly hard (R has a significant fraction built in, and there's an old standard library for Scheme, of all things, that is very similar). Perl was perhaps the leading language for websites, but the Perl 5/6 situation just confused everybody as it dragged on, which made Python and Ruby libraries seem more attractive.
> And I guess Perl also never had its Django (or Rails).
It’s got two of them - Catalyst (older still works fine) and Mojo - newer and shinier.
I think python is a better fit for mathematical work. I like to say that python helps you think more like the computer does, and that perl helps the computer think more like you.
It’s got two of them - Catalyst (older still works fine) and Mojo - newer and shinier.
I think python is a better fit for mathematical work. I like to say that python helps you think more like the computer does, and that perl helps the computer think more like you.
Catalyst was no match for Rails. Mojolicious could have been had Miyagawa's PSGI/Plack appeared on the scene half a decade earlier.
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.
I honestly think the Perl community's attachment to Catalyst contributed to Perl5's demise. Mojolicious was a much better bet for the future of Perl.
I've only done a little bit of mojolicious, but it's quite nice. The Mojo::UserAgent / Mojo::Dom tools are certainly great for writing web scrapers.
So it's the Osborne effect? Where you stop using Perl 5 because you're waiting for Perl 6 (announced in 2000, released never? As Raku? As a rolling release? The history appears confusing in Wikipedia.)
https://en.wikipedia.org/wiki/Osborne_effect
https://en.wikipedia.org/wiki/Osborne_effect
Perl 6 was released as language spec and on the Rakudo implementation; the rename to Raku was kind of a backformation from the name of the Rakudo implementation, but it was after the first stable release.
Perl 6 had its first official release in December 2015. It has since been improved, mainly in performance and in async / event driven capabilities. It got renamed to Raku last year (https://raku.org using the #rakulang tag on social media). You can check out the Rakudo Weekly News if you want to stay up-to-date: https://rakudoweekly.blog
What was the 2010 Rakudo Star release then? Is 2015 language spec stability?
Universities switched from teaching Java and Scheme to teaching Python.
Probably because Python resembles pseudo-code.
Anecdotally I've heard from a few people who said Python was the first language where ideas just made sense to them. An "easy to learn" language, in other words.
(I can't relate to that and don't know why Python is thought of that way. As far as I can tell, beneath the syntax (which is prettier than Perl), Python is a messy language with even messier standard library.)
Probably because Python resembles pseudo-code.
Anecdotally I've heard from a few people who said Python was the first language where ideas just made sense to them. An "easy to learn" language, in other words.
(I can't relate to that and don't know why Python is thought of that way. As far as I can tell, beneath the syntax (which is prettier than Perl), Python is a messy language with even messier standard library.)
I worked on Perl for a while, liked it. Back in 2008/9, the only option for Perl on Windows was Activestate Perl, whose community version was missing lot of features that would have made it much less painful(I am thinking of PPM particularly). That was one of the biggest gripes I had with Perl. We moved everything to Python as soon as we could get comfortable with it and haven't looked back since.
Regarding Perl's one liners, I feel they are what makes Perl very useful, but my preference is AWK over Perl for that.
Regarding Perl's one liners, I feel they are what makes Perl very useful, but my preference is AWK over Perl for that.
I actually found ActiveState and ppm to be fairly useful when I was doing cross system Perl around the same time. You could get the same ActiveState versions for Linux and Windows and have a more consistent environment. In the few cases ppm didn't have what I needed, I would just use a CPAN client. Pretty sure I even got the CPAN client compiling some libs for windows (which took a bit of work, but wasn't impossible).
I even used that setup to package a couple Perl scripts with all their modules into PAR archive executables, circa 2011 I think.
> Regarding Perl's one liners, I feel they are what makes Perl very useful, but my preference is AWK over Perl for that.
I love the ability to pull in a CPAN module or two to really kick up a one-liner a notch without making it too long. Also, I like creating an alias to perl that loads up a few useful libs and the main project lib and putting it in the project path so I can use a one liner like a REPL and run small queries, reports, or even do complex DB queries/updates with it using DBIx::Class and all the helper methods I've created for this project's schema.
I even used that setup to package a couple Perl scripts with all their modules into PAR archive executables, circa 2011 I think.
> Regarding Perl's one liners, I feel they are what makes Perl very useful, but my preference is AWK over Perl for that.
I love the ability to pull in a CPAN module or two to really kick up a one-liner a notch without making it too long. Also, I like creating an alias to perl that loads up a few useful libs and the main project lib and putting it in the project path so I can use a one liner like a REPL and run small queries, reports, or even do complex DB queries/updates with it using DBIx::Class and all the helper methods I've created for this project's schema.
According to the Modern Perl author, Five things Perl (Still) Gets Right:
* Compatibility
* Quality
* Usability
* Scalability
* Availability
https://pragprog.com/titles/swperl/
* Compatibility
* Quality
* Usability
* Scalability
* Availability
https://pragprog.com/titles/swperl/
Mostly the last one. It's included by default with most linuxes and cygwin. So even if your boss hates you and doesn't let you install anything you can still write scripts.
Are they still renaming Perl 6? I think it is a tad confusing to have 5 and 7 being so similar, and the 6 in between so radically different. I can't be the only one.
It's explained in the announcement. Perl 6 was already renamed to Raku, but calling the new Perl version Perl 6 would be confusing, so they are directly jumping to 7. They even show other examples of version jumps.
Perl 6 was renamed to Raku in October 2019.
Ah, I am glad the name change happened. I got side tracked before it came to a conclusion. I'm guessing if it didn't happen then, it surely would have to be changed now because of this new version, which looks like far less of a fork in the road.
I know some people aren't fans of Perl5, but it's what I learned and I wasn't all that excited to have to toss everything I knew (and my reference books) just because of a new version number. If Perl6 turns out to be complementary as people were saying/hoping, maybe Perl7 is where we get to see the interplay.
I know some people aren't fans of Perl5, but it's what I learned and I wasn't all that excited to have to toss everything I knew (and my reference books) just because of a new version number. If Perl6 turns out to be complementary as people were saying/hoping, maybe Perl7 is where we get to see the interplay.
Perl 6 has been renamed to Raku (https://raku.org using the #rakulang tag on social media). You can run Perl inside of it if you want to, with the Inline::Perl5 module. Check out the Rakudo Weekly News https://rakudoweekly.blog if you want to stay up-to-date!
I'm surprised to see .pm6 extension still being used, at least on the rakudo documentation page. Do those contain Raku code, or Perl?
These would contain Raku code. But as with Perl, the core developers value backward compatibility much. Since many versions of Raku in use do not know of the new .rakumod extension yet, the old extension is used for many modules still.
This is probably going to change in the next language revision of Raku. See https://github.com/Raku/problem-solving/blob/master/solution... for the nitty gritty.
This is probably going to change in the next language revision of Raku. See https://github.com/Raku/problem-solving/blob/master/solution... for the nitty gritty.
[deleted]
Just to be clear to everyone: this doesn't break anything. If you continue to use Perl version 5, you're fine. If you want to upgrade your major version of Perl, then of course you need to know what that means.
To clarify this: if v5.32 can run your code, you should be safe. There have been various small changes in Perl 5 that might not handle something you wrote in 1995.
This is possibly a stupid comment, but I'd love a modern language whose expected lifetime is 100 years. A language whose specification details how it can be run for 100 years on changing hardware + operating systems, and is built with the least amount of, and easiest to perform, maintenance in mind.
Those languages kind of exist, but not expressly written as such. C will outlive us all.
Those languages kind of exist, but not expressly written as such. C will outlive us all.
You guys are just now getting to Perl 7? I'm already on Perl 11. http://perl11.org/
The Perl 11 initiative was started by some individuals in the Perl community, but it never gained much traction outside of the group around the ones that started it. It has been dormant for at least 8 years now.
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 :-)
I am not yet 30. My first job was all Perl.
I really hope this bumps Perl back into the niches where it excels. Because there are definitely areas where it is the sharpest and best tool for the job.
I really hope this bumps Perl back into the niches where it excels. Because there are definitely areas where it is the sharpest and best tool for the job.
Developers in their teens say: Wow, Raku! https://raku.org (formerly known as Perl 6)
I'm in my late 40s and say "Wow, Raku!".
I haven't used it for anything work related yet, but working with it is mind expanding and makes me a better programmer in whatever environment I work in.
The type system, multiple dispatch, literate programming support, and command line scripting features are simply amazing.
I haven't used it for anything work related yet, but working with it is mind expanding and makes me a better programmer in whatever environment I work in.
The type system, multiple dispatch, literate programming support, and command line scripting features are simply amazing.
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?
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?
I believe it's not radical at all compared to the Perl 6 idea. It's basically "strict Perl 5" if I'm reading it right.
If Larry had said from the start "Let's make a new language and call it Raku" we would have had Perl 6 long ago, it would have been called Perl Enterprise Edition in the business world, and you'd never have heard of Python or PHP because everyone would be using Perl. Oh well, better late than never.
If Larry had said from the start "Let's make a new language and call it Raku" we would have had Perl 6 long ago, it would have been called Perl Enterprise Edition in the business world, and you'd never have heard of Python or PHP because everyone would be using Perl. Oh well, better late than never.
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.
I still use Perl every now and again for powerful one-liners and I'm really glad it's around. Here is a bash function I use which takes args and merges and deduplicates PATH-like expressions:
merge-args ()
{
perl -e 'print join ":", grep {!$h{$_}++} split ":", join ":", @ARGV' "$@"
}
export PATH="$(merge-args "${SCRIPT_DIR}"/clang-tidy-ex /usr/local/opt/llvm/bin "${INSTALL_DIR}"/{,samples/}bin "${PATH}")"
ASAN_OPTIONS="$(merge-args "${ASAN_OPTIONS}" detect_leaks=1 check_initialization_order=1 detect_stack_use_after_return=1 strict_init_order=1 strict_string_checks=1 detect_odr_violation=0)"
A pure bash alternative for comparison.
merge-args() {
local res
for i; do
case ":${res}:" in
*:"$i":*)
;;
*)
res=${res+$res:}$i
esac
done
echo $res
}That is pretty neat, I did not know that 'for i' on it's own could iterate the args like that.
I had hope there would be a merging (with some compatibility layers and wrapper binaries) allowing to use Raku the same way Perl 5 was used (should not have been _that_ hard, just adding familiar options and special variables)... Now I'm seeing this goes in a total different direction.
Perhaps. Meanwhile, the most recent release of the Inline::Perl5 module of Raku allows one to have code blocks written in Perl inside Raku code, and vice-versa. And of course be able to use any CPAN module from Raku: https://modules.raku.org/dist/Inline::Perl5:cpan:NINE
Nice! I didn't know. But it still does not bring back the classic usage in Perl 5 style, that made intensive use of runtime options as shorthands for looping on all lines of a file etc.
To be on topic:
Perl7 is basically the idea to modernize saner settings by default. And breaking backcompat where it hurts. But it's far off a modern perl, like cperl is. They failed to fix the worst historical design mistakes. The hashes, the OO, types, @_, attrs before signatures (which was a major breaking change, but they excused themselves by claiming it was experimental), and many more.
https://github.com/perl11/cperl/issues/414
Instead they are breaking indirect method calls. Thanksfully this will be not POSIX, so nobody will use it.
Perl7 is basically the idea to modernize saner settings by default. And breaking backcompat where it hurts. But it's far off a modern perl, like cperl is. They failed to fix the worst historical design mistakes. The hashes, the OO, types, @_, attrs before signatures (which was a major breaking change, but they excused themselves by claiming it was experimental), and many more.
https://github.com/perl11/cperl/issues/414
Instead they are breaking indirect method calls. Thanksfully this will be not POSIX, so nobody will use it.
This article touches on something that I really enjoyed about (the early days) of Perl 5, and I think it may body well for the future of the language.
You could write Perl 5 like it was just a better Perl 4. All of the craziness with modules and references was hidden to you if you wanted to write a Perl 4-esque script that needed to talk to a database or do something else that you could find a module in for in CPAN.
The people would wrote those modules, God help them, I don't know how they managed to write the executable line noise that was in the source, but I didn't care. I could get my job done with a few simple `use` statements.
You could write Perl 5 like it was just a better Perl 4. All of the craziness with modules and references was hidden to you if you wanted to write a Perl 4-esque script that needed to talk to a database or do something else that you could find a module in for in CPAN.
The people would wrote those modules, God help them, I don't know how they managed to write the executable line noise that was in the source, but I didn't care. I could get my job done with a few simple `use` statements.
This is great news! I was really excited about Perl 6, until I realized it was a different language, and it never quite jelled into a usable thing. So I kept using Perl 5. I write mostly modern Perl code, so this is exactly what I wanted.
I learned Perl back in the late 90's when it was the best way to do web programming. As a C programmer, it was a breath of fresh air. It was a higher-level C for me and I used it for prototyping all kinds of things before writing the production level C code. Nowadays, I still use it for system maintenance and prototyping. It's a great language and very powerful tool.
I learned Perl back in the late 90's when it was the best way to do web programming. As a C programmer, it was a breath of fresh air. It was a higher-level C for me and I used it for prototyping all kinds of things before writing the production level C code. Nowadays, I still use it for system maintenance and prototyping. It's a great language and very powerful tool.
No idea when it was the last time you tried jelling. But Raku is very much a usable thing nowadays and is used in production: https://raku.org
That's good to know. I will definitely check it out. Thanks!
What project, if you were starting now from the scratch, would you use Perl for?
Any project that runs on a computer (not a microcontroller) that doesn't need a hardware accelerated multimedia. But even if the later you can always use sdl2.
My last three perl projects (not counting throwaway minor scripts): The control interface of a galvanic vestibular stimulator for VR motion sickness. A GUI for doing the required quirky edits to text files for text to speech smoothness. A comment system for a static website.
My last three perl projects (not counting throwaway minor scripts): The control interface of a galvanic vestibular stimulator for VR motion sickness. A GUI for doing the required quirky edits to text files for text to speech smoothness. A comment system for a static website.
The proposed defaults are a good idea, and I hope some or most of 5.32 long standing experimental features become core features (or just go away entirely).
But I'm afraid that the badly needed core C code refactoring and restructuring is being left out, and that will make it very hard to introduce new features into the language.
I also had this secret hope that Perl 7 would be a tidier, simplified Perl 5 with little or no relation to Perl 6. Less confusing syntax would go in sync with the refactoring of the core to create a smaller language that could perform better and be easier for beginners to learn.
But I'm afraid that the badly needed core C code refactoring and restructuring is being left out, and that will make it very hard to introduce new features into the language.
I also had this secret hope that Perl 7 would be a tidier, simplified Perl 5 with little or no relation to Perl 6. Less confusing syntax would go in sync with the refactoring of the core to create a smaller language that could perform better and be easier for beginners to learn.
> I also had this secret hope that Perl 7 would be a tidier, simplified Perl 5 with little or no relation to Perl 6.
That's what the article says.
> could perform better
Perl's performance is not an issue.
That's what the article says.
> could perform better
Perl's performance is not an issue.
I've had to write some Perl in my latest project. Coming back to a language 20 years later at 37 years old was very interesting. I'm not a fan of the language but I can see why people like it.
The largest issue I've had is that even though the ecosystem gives you the ability to write code resembling best practices, I don't see a lot of Perl programmers that do it. Coming onto a project it didn't make sense to catch a whole team up on 20 years of best practices. So I went about writing code that would never be accepted on most of my other teams.
The largest issue I've had is that even though the ecosystem gives you the ability to write code resembling best practices, I don't see a lot of Perl programmers that do it. Coming onto a project it didn't make sense to catch a whole team up on 20 years of best practices. So I went about writing code that would never be accepted on most of my other teams.
Perl 6 with parrot VM was expecting release in 2004, we had some portion of our code in perl. other portions were in php4. chose ruby due to rails announcement in 2004.
will wait for actual release will try on some pet project
will wait for actual release will try on some pet project
Perl 6 actually got released in December 2015. Meanwhile it got renamed to Raku (https://raku.org using the #rakulang tag on social media). You don't have to wait anymore to be able to use it on a pet, or even a business project. Check out the Rakudo Weekly News if you want to stay up-to-date: https://rakudoweekly.blog
Maybe someone here is the right person interested in this: I've been working on making Perl more suitable for functional programming[1]. This project still needs a lot of manpower to become something good. I need people to work with me on this, I won't continue alone. Please give me feedback about where I should be going with it, or tell me if you're interested in joining the effort.
[1] https://metacpan.org/pod/FunctionalPerl
[1] https://metacpan.org/pod/FunctionalPerl
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 even has a slight smell of perl anymore, which is strange seeing as 90% of our company codebase was perl 15 years ago.
*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 even has a slight smell of perl anymore, which is strange seeing as 90% of our company codebase was perl 15 years ago.
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.
In my opinion, the failure is in the timing of the process, and keeping the Perl community involved in the process.
Wow, I haven't written any perl since
checks
5.27 pm today.
checks
5.27 pm today.
Thus the embarrassment of Perl 6 is erased from history.
Perl 6 may be erased. But the Raku Programming Language (https://raku.org, using the #rakulang tag on social media) rose from its ashes.
Perl 5 was great. Written so many things in it. Looking forward to 7. Maybe time to start doing new things in perl?
Why does this happen so often to certain language version numbers? ECMAScript 4, PHP 6, and now Perl 6.
Second system syndrome
Netscape 5, Windows Longhorn
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.
> > use utf8;
> there’s still much to be done to make Unicode the default
Why's that? If that's something someone with zero Perl experience can easily understand. Isn't this only about the source code? Or does this mean all strings are unicode?
> there’s still much to be done to make Unicode the default
Why's that? If that's something someone with zero Perl experience can easily understand. Isn't this only about the source code? Or does this mean all strings are unicode?
This[1] explains it. Essentially, to support unicode probably, you have to do extra work in your own code. (How do you handle invalid unicode? Should regex character classes match the unicode versions, or just the ascii versions? etc.) Additionally, certain builtin functions don't already support unicode, and modifying them to do that would be a breaking change. For more info, see the py2->py3 unicode change, and how much of a mess that caused.
1. https://stackoverflow.com/questions/6162484#6163129
1. https://stackoverflow.com/questions/6162484#6163129
People just keep wasting their precious lives on archaic stuff that has no future. Perl is dead. If these smart minds want to contribute to humanity, they should abandon this sunken ship and move to something more meaningful.
> Perl is dead.
Seems like DuckDuckGo didn't get the memo.
Seems like DuckDuckGo didn't get the memo.
Perl5 was the first language in which I actually did some substantial projects. It was also heavily used in scientific computing (esp. genetics) until python came along.
Perl readability is rivaled only by c++ template code!
What is there to gain in calling it Perl 7? It seems needlessly disruptive, rather than just calling it 5.34 or whatever is next.
It's reclaiming the Perl name since Perl 6 has abandoned its connection to Perl and is claiming to be a completely separate unconnected language.
This is the logical conclusion to this divergence and will mean that going forward people wont think Perl 6 is the newest version of Perl. That problem would still exist if you leave Perl at 5.35 since search engines are still happily returning pages for Perl 6 even though it's no longer a thing.
This is the logical conclusion to this divergence and will mean that going forward people wont think Perl 6 is the newest version of Perl. That problem would still exist if you leave Perl at 5.35 since search engines are still happily returning pages for Perl 6 even though it's no longer a thing.
It is to resolve question of Perl 5 continuity. Something that Python 3 has not accomplished.
Need a comprehensive, up-to-date, yet brief, status of what happened to Perl 6 and where it stands in today's s/w tech.
Perl 6 is basically a totally different language than any other Perl, and it took a very long time to go from announcement (2000) to release (2015). It was renamed to Raku last year.
String parsing - Perl5's forte - is still dog slow with Perl6/Raku and year after year we hear that will change in the future. Don't hold your breath.
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/
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.
On my 4-core i7 Macbook Pro parsing a 20Mb log file with a regex takes 9.4 times longer with Raku than Perl5. That's unacceptable. Adding Moose to Perl5 reduces the differential to 7.1 which is still huge.
Perl 6 had its first release in December 2015. Since then, it has been renamed to Raku (https://raku.org using the #rakulang tag on social media). It has monthly releases and a weekly blog: https://rakudoweekly.blog
It supports an improved regex syntax, grammars, Unicode NFG (Normalization Form Grapheme, think "\r\n" as a single codepoint), a gradual type system, async execution of code, junctions, event driven execution, set operations...
Hope this was short enough.
It supports an improved regex syntax, grammars, Unicode NFG (Normalization Form Grapheme, think "\r\n" as a single codepoint), a gradual type system, async execution of code, junctions, event driven execution, set operations...
Hope this was short enough.
Glad to hear it. Perl 6 was some kind of twisted complexity pornography.
This is fantastic news! I'm glad perl 5 is evolving again.
In some companies, they have huge projects written in Perl
Reasonable since "perl6" issue is solved. Everyone may move forward.
Perl is alive!
After a million years, it is finally out!
Finally!
tl;dr - Perl 7.0 is going to be v5.32 but with different, saner, more modern defaults.
Perl was great 20 years ago for basic scripts. Where is it still used today who hasn't transitioned to Python/etc?
Perl was great 20 years ago for basic scripts. Where is it still used today who hasn't transitioned to Python/etc?
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.
The only thing I've noticed that's lacking is decent protobuf support.
I think what you're looking for is this: https://metacpan.org/pod/Google::ProtocolBuffers::Dynamic
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)
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)
Most of Perl's virtues were inherited by Ruby, not Python. Hell, Python doesn't even have a regex operator.
This is just bad maintenance. Just pick all the stuff people are complaining about and fix it!
1. Improve threads
2. Improve C API support
3. Give local::lib, cpanm by default ... multiple perl versions by default
4. Give direct support for coroutines / async await
5. Mark experimental features as non-experimental (attributes, signatures)
6. Pick an OO system, package system
7. Make switch cool again
8. Get more core modules or remove some. Give more visibility to cool perl modules. like PDL or something.
9. Improve GUI toolkit, Web Deployment and Web Assembly support
10. Improve look and feel of community sites
Heck break some backwards compatibility with Perl4, get rid of format.
1. Improve threads
2. Improve C API support
3. Give local::lib, cpanm by default ... multiple perl versions by default
4. Give direct support for coroutines / async await
5. Mark experimental features as non-experimental (attributes, signatures)
6. Pick an OO system, package system
7. Make switch cool again
8. Get more core modules or remove some. Give more visibility to cool perl modules. like PDL or something.
9. Improve GUI toolkit, Web Deployment and Web Assembly support
10. Improve look and feel of community sites
Heck break some backwards compatibility with Perl4, get rid of format.
Just a little note, Perl 5 actually has (in my opinion) excellent coroutines in the form of the "Coro" module hierarchy. Good enough to run a web service on.
it's likely a lot easier to do all that in the perl7 branch, so that backwards-incompatible changes can be made if needed.
It's not my understanding that the "Perl 7" idea suddenly gives license to be backwards incompatible. Instead, features that have been made available and gated in previous releases can be made default in a new major version.
yes, that's how they are starting off perl7, but the mere fact that it is given a different major version number gives them the social license to break stuff.
>get rid of format.
You shut your mouth. I can't even count th number of my scripts that'd break. I like format for output.
You shut your mouth. I can't even count th number of my scripts that'd break. I like format for output.
One more: add a proper exception handling setup.
Yeah that too! People keep saying perl is a bad language or something and the other languages can't even get implementing closures right.
I've always liked the references syntax, probably the most complained about feature. Its just pointer thinking. You could probably collapse `$array[$x]->{"foo"}->[0]` to `$array[$x]{"foo"}[0]` and save some keystrokes.
I've always liked the references syntax, probably the most complained about feature. Its just pointer thinking. You could probably collapse `$array[$x]->{"foo"}->[0]` to `$array[$x]{"foo"}[0]` and save some keystrokes.
> probably collapse $array[$x]->{foo}->[0] to $array[$x]{foo}[0] ...
Yup, one's been able to collapse exactly like that for more than twenty years.
https://metacpan.org/source/LWALL/perl5.002b3/pod/perlref.po...
That's from 5.002, from last century, and it wasn't introduced on 5.002.
Beginning from v5.20, one's also been able to use the postfix dereference syntax, turning:
say join "\t", @{ $foo->{bar}[0]{quux} }
into:
say join "\t", $foo->{bar}[0]{quux}->@*;
Whether that's better or worse, it's debatable.
Yup, one's been able to collapse exactly like that for more than twenty years.
https://metacpan.org/source/LWALL/perl5.002b3/pod/perlref.po...
That's from 5.002, from last century, and it wasn't introduced on 5.002.
Beginning from v5.20, one's also been able to use the postfix dereference syntax, turning:
say join "\t", @{ $foo->{bar}[0]{quux} }
into:
say join "\t", $foo->{bar}[0]{quux}->@*;
Whether that's better or worse, it's debatable.
You're right! I always preferred the explicit arrow because it reminded me of C. Dammit now I want to write perl. I miss autovivification so much. Most people hate the pointer syntax and call it unreadable. I think there should be a perl tricks page that lists all these tricks.
This is planned.
Amazing. I literally first installed this on my laptop over 10 years ago. (Using Parrot)
If it was using Parrot, you probably installed Perl 6 (at the time, now known as Raku).
Ah you're right, it was 6. Amazing to see Perl still going after all this time!
This feels like a last ditch attempt to save a dying language. (https://i.imgflip.com/4676mf.jpg)
I wonder what exactly does Perl bring to the table as a language, why would one consider choosing it over other languages.
Regular expressions as a first class language feature.
Ruby also has this.
Ruby really is Perl done right. I can't really see any argument for Perl over Ruby as a language.
Speed. I moved mostly to Ruby years ago, but when doing lots of text processing, a trivial script in Perl runs a lot faster than a similar trivial script in Ruby.
You should see some of the atrocities I had to debug at aol because of regex abuse.
People are interested in using it and people are interested in developing it, so it continues to be used and developed.
I got my start with Perl; I wrote a book about it, I spoke at every conference, I did training, I maintained the Emacs mode. I started working at Google and, forced to use static languages, found them to be just as productive as Perl. And, they eliminated a lot of problems with Perl -- libraries were resolved at compile-time, and I just ended up with a binary that could be run anywhere (no @INC madness); types were checked at compile-time, so silly errors that required extensive unit testing in Perl could just be automatically underlined by my editor and fixed before I even saved the file.
Something else that bothered me was how much mindshare the dynamic languages were competing for among themselves. I would prefer to write a Perl program over a Java program any day... but Perl did not seem to be fighting with the Javas and C++s of the world, instead it was always trying to take on Python and Ruby. And Python and Ruby were like that too -- every Ruby programmer was out to kill Perl because they didn't like Matt's Script Archive. (Nobody wrote 1990s Perl in the 2000s, so it was kind of a strawman.) You ended up with a bunch of like-minded people fighting for the small attention share of "we don't really care about runtime performance", and all the factions were just too small to take on the larger issue of entrenched static languages. Java and C++ never felt like they had to take features or ideas for Perl, Python, or Ruby. So it all seemed kind of pointless.
With all that in mind, I do think Perl failed to "win". It is a neat programming language, but probably too complicated for beginners and not productive enough for people that have gotten comfy with C++/Java/Go, which are pretty darn productive these days. Meanwhile, Python found its niche pretty much everywhere -- you can program microcontrollers with it, you can write a video sharing website with it, you can do data science with it -- and it's a great introduction to programming for beginners. And, Javascript kind of came out of nowhere to conclusively "win" the dynamic language war (because a dynamic language needs a runtime, and guess what runtime exists on pretty much every computer and phone around these days?)
TL;DR: I kind of agree that the programming language wars have been fought and lost by Perl. That doesn't stop people from wanting to make it better, or to continue to use what they know. You can make lots of great things with it, so people continue to use and improve it.
I got my start with Perl; I wrote a book about it, I spoke at every conference, I did training, I maintained the Emacs mode. I started working at Google and, forced to use static languages, found them to be just as productive as Perl. And, they eliminated a lot of problems with Perl -- libraries were resolved at compile-time, and I just ended up with a binary that could be run anywhere (no @INC madness); types were checked at compile-time, so silly errors that required extensive unit testing in Perl could just be automatically underlined by my editor and fixed before I even saved the file.
Something else that bothered me was how much mindshare the dynamic languages were competing for among themselves. I would prefer to write a Perl program over a Java program any day... but Perl did not seem to be fighting with the Javas and C++s of the world, instead it was always trying to take on Python and Ruby. And Python and Ruby were like that too -- every Ruby programmer was out to kill Perl because they didn't like Matt's Script Archive. (Nobody wrote 1990s Perl in the 2000s, so it was kind of a strawman.) You ended up with a bunch of like-minded people fighting for the small attention share of "we don't really care about runtime performance", and all the factions were just too small to take on the larger issue of entrenched static languages. Java and C++ never felt like they had to take features or ideas for Perl, Python, or Ruby. So it all seemed kind of pointless.
With all that in mind, I do think Perl failed to "win". It is a neat programming language, but probably too complicated for beginners and not productive enough for people that have gotten comfy with C++/Java/Go, which are pretty darn productive these days. Meanwhile, Python found its niche pretty much everywhere -- you can program microcontrollers with it, you can write a video sharing website with it, you can do data science with it -- and it's a great introduction to programming for beginners. And, Javascript kind of came out of nowhere to conclusively "win" the dynamic language war (because a dynamic language needs a runtime, and guess what runtime exists on pretty much every computer and phone around these days?)
TL;DR: I kind of agree that the programming language wars have been fought and lost by Perl. That doesn't stop people from wanting to make it better, or to continue to use what they know. You can make lots of great things with it, so people continue to use and improve it.
Perl lost the war because it didn't turn-up for the battle. In the 2000s it went into a kind of COVID19 self-isolation phase. First there was Parrot - a half-assed attempt to create a CLR for dynamic languages. When that failed the MoarVM adventure began. There were about 3 implemetations of Perl6 in development simultaneously (MoarVM, JVM & Rakudo) as Perl5 hemorrhaged mindshare. All-in-all it took 15 years to produce a 1.0 which was so dog-slow for Perl's common use-case it was unusable ... and still is.
Yeah, Perl 6 was certainly A Thing. I am not sure practicing Perl programmers cared much about it. I went to the talks and thought "neat" but it didn't really seem like "welp, this is taking forever, I'm switching to Python." Maybe if everyone working on Perl 6 decided to work on data science tooling instead, Perl would have "beaten" Python in that area and things would be different, but the world doesn't really work that way, so I don't think Perl 6 really mattered in terms of Perl fading away. A lot of people learned a lot of things about language design, and that will no doubt benefit the entire field for many years to come. (Look at "Go 2" versus "Perl 6", for example.)
On some level, everything is like that. Perl was a better awk/grep and was successful in replacing those tools. Then one day, someone decided to use it for CGI, and it got a huge popularity boost. But the people that decided to use it for CGI could have easily used something else, and it would have probably worked fine and Perl never would have been popular. It was just random chance that they picked Perl and made it popular. I feel like everything works that way. Javascript is popular for web UIs because someone decided to add it to a popular web browser. There is always some intrinsic randomness that plays a part in gaining mindshare. A bad tool with a good mindshare can do well, and a great tool with no boost can languish in obscurity. Perl benefited a lot from luck, but rolling the dice doesn't last forever.
On some level, everything is like that. Perl was a better awk/grep and was successful in replacing those tools. Then one day, someone decided to use it for CGI, and it got a huge popularity boost. But the people that decided to use it for CGI could have easily used something else, and it would have probably worked fine and Perl never would have been popular. It was just random chance that they picked Perl and made it popular. I feel like everything works that way. Javascript is popular for web UIs because someone decided to add it to a popular web browser. There is always some intrinsic randomness that plays a part in gaining mindshare. A bad tool with a good mindshare can do well, and a great tool with no boost can languish in obscurity. Perl benefited a lot from luck, but rolling the dice doesn't last forever.
If mod_perl had been designed more like mod_php Perl's web frameworks (Catalyst, HTML::Mason, Dancer & Mojolicious) might have had a chance of competing with PHP and Rails. PSGI could have helped Perl compete with Ruby/Rails but PSGI came too late.
Perl 6 is still very much a thing, but it's called Raku now (https://raku.org using the #rakulang tag on social media). It has a weekly blog post https://rakudoweekly.blog should you care to want to stay up-to-date!
To my knowledge, only 2 implementations were ever in development simultaneously: Niecza and Rakudo.
Niecza focused on producing a Perl 6 on the .Net infrastructure. Rakudo is based on NQP (Not Quite Perl) and initially ran on Parrot, then also added the JVM as a backend, and then later added MoarVM as a backend.
Niecza sadly stopped being developed as its main developer developer decided it wouldn't be able to come to a full release (around 2012/2013).
So to say that "about 3 implemetations of Perl6 in development simultaneously" is incorrect, and then to name MoarVM, JVM and Rakudo as the three is even more incorrect.
Perl 6 got renamed to Raku in 2019. Since the first release in December 2015, it has become about two orders of magnitude faster.
You can check out the Rakudo Weekly News should you wish to stay up-to-date on developments in the Rakudo world: https://rakudoweekly.blog
Niecza focused on producing a Perl 6 on the .Net infrastructure. Rakudo is based on NQP (Not Quite Perl) and initially ran on Parrot, then also added the JVM as a backend, and then later added MoarVM as a backend.
Niecza sadly stopped being developed as its main developer developer decided it wouldn't be able to come to a full release (around 2012/2013).
So to say that "about 3 implemetations of Perl6 in development simultaneously" is incorrect, and then to name MoarVM, JVM and Rakudo as the three is even more incorrect.
Perl 6 got renamed to Raku in 2019. Since the first release in December 2015, it has become about two orders of magnitude faster.
You can check out the Rakudo Weekly News should you wish to stay up-to-date on developments in the Rakudo world: https://rakudoweekly.blog
Of you're depending on a meme rather than making a valid point, I wonder what you are bringing to this particular table.
If it works, it works...
I landed my first devops position around the 2010 era as well and being the only one on the team that really knew how to "program", I spammed out tons of perl scripts and web apps. A few years later one of the newer employees on the customer support team started spouting off about "python" and how it was so easy to learn. He was always blabbing about terms I'd never heard of like "generators", "list comprehensions", "decorators", etc. I looked them up and learned they were just abstract constructs with fancy names that are supported in most any language. So I just figured he was some idiot that didn't really know anything. Otherwise, why would you be blabbing about abstract constructs? He quickly landed a job at google and I left and started freelancing only picking up perl jobs. Because perl was "dying" and this being after 2012, there were several companies with large perl bases that couldn't find local employees so were forced to allow remote workers.
This is where stuff started going wrong. I went through many jobs/gigs my first couple of years. I quickly noticed that companies that had large perl code bases were all founded pre-2005. This meant it was crap perl, in most cases not even using CPAN but having home grown ORM's and web frameworks and a scrict hate of javascript. So it mostly sucked and was slow going. In one case I was literally fired after a couple of months from this one company that specialized in phone billing accounting software (all perl powered) because I was "too slow". The owner told me he should have never hired someone with less than fifteen years experience with perl and bid me farewell. I almost busted out laughing as for the entire two months I was only doing javascript front end work since the other perl guys there hate javascript. Even the owner of the company had no clue how his own software worked. This was a theme that repeated it self else where as well.
Fast forward a few more years and I had landed a good remote job, still in perl but offered more freedom in the dev cycle. I got good with react and vue.js as it greatly speed up the dev time for all the heavy interactive apps I was tasked with. But I continued to struggle against others in the perl community. I can understand how a 50 year old perl dev (the typical age) would hate javascript and instead put as much code in the back end using all kinds of horrid html templates and never ending form post/refresh/repopulate cycles... I can see the "why should I learn javascript if i know perl" ideology, but what blew me away is a constant "why should I learn SQL if I know perl" ideology. Yes I'm serious. In so many other cases devs were fine with just doing "select *" on tons of tables and stuffing all that in a hash/dictionary of column name matching keys. Databases were big, scripts and page load times would grow to minutes or even hours. Sometimes exhausting the machine's ram and crashing everything. Everyone was fine with it, management just acted like it's how things work. Meanwhile as a co-worker, I'm left digging through pages of perl code that could have just been a single SQL query trying to figure out why some numbers are wrong in an invoice report. It was a continual issue.
Another issue is just the bit rot of cpan. The ORM and drivers for both postgresql and sqlite don't even support most of the features added in those systems since 2014. So even though postgresql is the most advanced DB out there, you are stuck with no ability to use any of the fancy native array or json types or even the "natural" join syntax (and many other things), neither good support for foreign keys in sqlite either.
I've thrown my hands up and jumped ship. It's sad too. I liked many in the community and like Larry Wall as well and have had dinner with him on several occasions. But I can't keep my sanity and stay with perl. I can read perl fine, it is not the notorious "write only" language that many troll it to be. But the issue is the community and those using perl daily are fine with being stuck in 1995. Larry Wall stopped adding features to perl in 2002 (?) and moved to perl 6 which.... well how do you even describe that? The point is, perl has been the same since 2002, mean while python has had continual development and features added every year since then. I'm just done.