Perl 7 is going to be Perl 5.32, mostly(perl.com) |
Perl 7 is going to be Perl 5.32, mostly(perl.com) |
Perl was great 20 years ago for basic scripts. Where is it still used today who hasn't transitioned to Python/etc?
The only thing I've noticed that's lacking is decent protobuf support.
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.
You shut your mouth. I can't even count th number of my scripts that'd break. I like format for output.
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.
sub foolTwice() { return perl5(); }
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.
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)
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.
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
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 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.
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.
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.
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.
That's what the article says.
> could perform better
Perl's performance is not an issue.
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.
will wait for actual release will try on some pet project
*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.
In my opinion, the failure is in the timing of the process, and keeping the Perl community involved in the process.
checks
5.27 pm today.
> 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?
Seems like DuckDuckGo didn't get the memo.
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 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.
Look at how easily raku binds to a python charting module in this article: https://www.perl.com/article/plotting-with-perl-6/
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.
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.
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.
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.
Funny enough I heard the same thing about JavaScript about 5 years ago when ES6 came out.
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.
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 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.
For example?
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.
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.
explicit function signatures for one!
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.
> 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.
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 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?
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).
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).
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.
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.
$_ the topic
$/ result of the last match
$! the last exception caught
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. :)
> 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.
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.
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 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.
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.
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?
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.
> 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.
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 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.
Edit: nice tool, by the way!
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.
print "It worked!\n" unless $error;
print "Item: $_\n" foreach @items; puts "It worked!" unless error
i = 0; puts "Item: #{i+=1}" while i < 5
items.each {|i| puts "Item: #{i}"}e.g.
unless ( $foo ) { }
if ( not $foo ) { } perl -E 'say for grep {/o/} @ARGV' one two threeMaybe that's because I'm not a native English speaker?
if not not_implemented
unless not_implemented if not error:
print this 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?
:D
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.
And I guess Perl also never had its Django (or Rails).
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.)
Regarding Perl's one liners, I feel they are what makes Perl very useful, but my preference is AWK over Perl for that.
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.
* Compatibility
* Quality
* Usability
* Scalability
* Availability
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.
Those languages kind of exist, but not expressly written as such. C will outlive us all.
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 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.
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?
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.
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)"
merge-args() {
local res
for i; do
case ":${res}:" in
*:"$i":*)
;;
*)
res=${res+$res:}$i
esac
done
echo $res
}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.
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.
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.
$| 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.
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?)
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.
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.
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!
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.
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 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!
It died a noble, honorable death. RIP.
Edit: Whoops, had operators reversed because I explained them after the fact. Fixed!
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.
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.
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> 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.txtMy 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/
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.
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.
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.
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.
IMDB seems plenty fast to me. UI isn't great, but that's more of a presentation layer design thing than a language thing.
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...
https://metacpan.org/pod/Mason (if you're not familiar with Mason)
Most of the ad network backend sites are perl, including a lot of Yahoo.
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.
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.
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.
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 194,000 modules, which is probably the most of any language:
> 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.
- 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?
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.
Ariba isn't a household name, but it has deep and widespread connections to thousands of the largest companies in the world.
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).
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.
Efficient, cheap and stable. Ported to about everywhere.
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?
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"
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.
...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...)
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.
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.
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...
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.
> 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!).
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.
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.
I don't write software as an end goal, I write software to accomplish my end goal.
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".
Perl is everywhere, it's just not widely publicised because of the stigma attached to the language.
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();
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, 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.
[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
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.
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.
class Point {
has $.x;
has $.y;
}
Point.new(x => 42, y => 666);Perl 6 (as lizmat pointed out), has more powerful rules. I don't know a ton about them.
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
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).
> I don’t really know much about Python. I only stole its object system for Perl 5. I have since repented.
My limited experience with Swift suggests that even 25 hours ago could be a tall order...
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 version was released in September 1995, but wasn't JavaScript until Dec 4, 1995.)
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.
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.
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).
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.
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.
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.)
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.
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.)
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.
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.
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).
Until someone does…
time ./startup_time.pl 0.016s
time ./startup_time.py 0.295s
time ./parse_log.pl 0.683s
time ./parse_log.py 1.534s
#!/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='')
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.
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.
- 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.
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.
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.
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.
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.
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, ...
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 kind of felt lost first getting started with Scala where I felt like there was symbol overload.
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.
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.
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.
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.
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.
Demand in this case, will likely create its own supply.
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.
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.
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.
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!
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.
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.
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.
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...
Food for thought.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
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.
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.
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.
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
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 :-)
So it happened once but it took up about 25% of the last 20 years.
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.
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.
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.
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.
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.
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-...
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.
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.)
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.
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.
It has even less backcompat problems than the native regex.
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.
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.
I only used Ruby briefly over 20 years ago so I can't comment.
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.
%nested = (foo => { bar => { baz => "quux" } });
$nested->{foo}{bar}{baz}
$nested->{$x}{$y}{$z}
$nested{$x}{$y}{$z}
$nested = { … };
#!/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='')
time ./index.pl 0.258s
time ./index.py 0.609s
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.
[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):
continuePerl generally outperforms python in core language features.
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.
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?
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.
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.
"If hard-to-read-and-remember syntax exists, people WILL use it"
This statement doesn't appear to hold up under scrutiny.
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.
[0] https://stackoverflow.com/questions/26127617/what-exactly-ar...
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.
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.
Only, it's the programmer saying it this time, not the layman. Perl is a 10x engineer.
use IO::Handle;
STDOUT->autoflush(1);
STDERR->autoflush(1);"There’s more than one way to do it, but sometimes consistency is not a bad thing either."
(for those unfamiliar: https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to...)
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 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 = @_
sub method {
my ($self, $a, $b, $c) = @_;
}
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]).
With an asterisk: method(*array)
How is that more understandable than @ vs \@ without knowing the language? My guess is it isn't.
def f(b):
print(b)
f(*a)
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.
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.
Not with the sigil names, are they?
>This statement doesn't appear to hold up under scrutiny.
What scrutiny? I don't see any scrutiny. You just said that, without scrutinizing.
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?
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.
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.
Are we really?
You mean like string instrument tab coloured by finger instead of sheet music? Yes, exactly like that.
Restrict scale to pentatonic even for professionals (remove physical keys, holes etc). They would absolutely mess up otherwise.
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.
