P.S. I am student and I have no real perspective on what is going on in industry right now.
It's not "cool", it's not "sexy", but there package collection (http://cpan.org/) is __huge__.
I find it unlikely that new people will suddenly rediscover perl, in the golang/node.js/python-centric state the world is in. But the people who love it, do continue to love it, and do continue to do useful and essential things with it.
The author cites a couple of issues as the motivation behind the release.
The Comprehensive Perl Archive Network (CPAN) currently has 186,953 Perl modules in 35,278 distributions, written by 13,095 authors, mirrored on 248 servers.
I think it cannot compete with Python at its current state. This has nothing to do with the language (I consider Perl to be vastly superior) but rather its ecosystem and lack of momentum.
Concerning scientific programming, PDL used to be among the first choices but I'm not even sure if it's being used in bioinformatics anymore.
Its last nail in the coffin was missing the DevOps hype-train (Puppet, Chef...)
So even though the language is awesome I wouldn't recommend a developer in 2017 to learn it
In this specific case, these are contradictory.
Perl and Python had roughly the same amount of corporate backing (almost none) and Perl had a huge head start.
If Perl as a language would be "vastly superior", Python would have never developed its ecosystem and wouldn't have ever gathered enough momentum.
I know that "readable" is a subjective trait, but Python is 1 cm away from being pseudocode.
And when a programming language is basically the thing we write when we don't have any tools to assist us, that says a lot about the language's syntactic quality, including its readability.
Both the data science libraries and Google's backing come from this. And to be honest, I don't really see how Google's backing mattered that much... 99% of the popular Python libraries have nothing to do with Google, especially Django.
Both are false. Data science libraries are quite new development that happened because Python got popular, not the other way around. Backing by Google (whatever you mean) was irrelevant, as the main selling points for Python dozen years ago was simple and readable syntax and nice web toolkits (a movement that followed Ruby with its RoR).
> If Perl6 hadn't taken 15 years to complete Perl's popularity might be different.
Perl6 didn't compete for popularity with Perl, because it was essentially non-existent back then. Perl popularity decline cannot be attributed to Perl6.
The thing is, Perl is a very complex language, but has competiton that is simpler grammar-wise and similarly powerful and expressive: Python and Ruby. It's easier for newcommers to learn Python or Ruby than Perl, so they rarely dig into Perl. This means that the number of people leaving the language (a normal thing for any language) is not matched by the number of young programmers, which leads straight to decline.
Python began to pick up momentum around 2000. It was able to break out of the "scripting" niche because it had good OO support and encouraged a consistent style that made it easy for several developers to work on a large project.
Rails probably marked the tipping point, but it wasn't just the framework. A lot of Perl programmers found out they liked Ruby. You're right that Perl 6 was part of the problem; it might be where Ruby is today if it had come out in 2003.
On the other hand, Ruby probably wouldn't exist if Perl 5 had a better object system.[1] It's "Ruby on Rails" because DHH fell in love with Ruby.[2] The creators of Django learned Perl before falling in love with Python.[3] So that has something to do with the languages too.
[1] http://www.linuxdevcenter.com/pub/a/linux/2001/11/29/ruby.ht...
[2] https://www.quora.com/Why-did-David-Heinemeier-Hansson-choos...
[3] http://www.akitaonrails.com/2008/01/01/chatting-with-adrian-...
There are many languages that are "better" than JavaScript for example, yet not many that enjoy its share of success.
Perl and Python are perfectly comparable regarding origin, corporate backing, marketing, platform restrictions, etc. Javascript isn't.
Perl and Python were both started by a BDFL, acquired a grass-roots community that promoted them and never really had 1 major corporate backer or sponsor that outshined all the others. They also didn't become the main or even the only suppported language for a platform.
They had a really similar trajectory, just with different peaks. Perl peaked earlier and IMO lower.
Perl doesn't have anything like Python's GIL. People have other complaints about threading in Perl, but you can count on things running in parallel more often.
I believe Larry Wall is correct that he borrowed more from Lisp than Guido did. Perl built in functions are also often modeled after POSIX functions (that may not mean a lot to you, but I like it).
On the other hand, Perl 5 doesn't have anything like Python's "yield", and the closest it gets to list comprehensions is a Lisp-style "map" that is NOT lazily evaluated. And I've never managed to get a job where I was expected to write Perl (I've written Perl utilities at plenty of jobs, but Perl was never on the official job description).
My only points of reference are POSIX being a UNIX system specification which defines both a C language reference and system userspace specification. I also have a vague notion of POSIX specifying the fundamental behavior of shells.
I'm just not quite sure which point of reference to apply.
They're good for when you want something more than what the coreutils give you, but don't want to compile some C.
If you want to fork a process, you use the function "fork". If you want to call exec, Perl has it. You can even have the parent process wait on the child's pid.
This isn't a big deal to everyone, but I like POSIX, and I like knowing that if I want to do something new, there's a good chance I can start with "how would I do it in C on a POSIX system?" I have many complaints about Java, and one is that their original standard library appears to have been modeled on early versions of MFC, even though Sun had access to a superior API, since they had plenty of experience with shipping a POSIX operating system.
POSIX was basically a committee ratifying things that a bunch of systems people had come up with. So it gets to the point, it's reasonably concise, and there's little noise to wade through to do most things.
Java was slowly designed by committee, taking inspiration from other languages.
I just thought of something. Maybe it's relevant.
IBM said "let make something totally different with this 8086 system, let's make everything open and not lock it down." Apple said "let's do something different with the Macintosh, let's enforce absolute control over the hardware and software so we can perfectly unify them."
Maybe Sun got fed up with SunOS and said "let's make a language and runtime that's totally different - something so different that it resists influence by platform architecture."
"Modernism was based on a kind of arrogance, a set of monocultural blinders that elevated originality above all else, and led designers to believe that if they thought of something cool, it must be considered universally cool. That is, if something's worth doing, it's worth driving into the ground to the exclusion of all other approaches. Look at the use of parentheses in Lisp or the use of white space as syntax in Python. Or the mandatory use of objects in many languages, including Java. All of these are ways of taking freedom away from the end user 'for their own good'. They're just versions of Orwell's Newspeak, in which it's impossible to think bad thoughts. We escaped from the fashion police in the 1970s, but many programmers are still slaves of the cyber police" ( http://m.linuxjournal.com/article/3394 ).
The article was an excellent read too.
I've noticed that a lot of people around the 18-25 demographic (and some outside that range) have mental health issues that (among other catastrophes) cause detrimental effects to emotional development. I was thankfully able to get off this train myself using alternative therapies about ten years ago, but one of the things I observed about myself was a tendency to hone in on one specific idea present in something I was thinking about and then redefine what I was focusing on on the basis of and in terms of that idea, in many situations irreversibly discarding any other possible interpretations. I essentially didn't have the capacity to wield concepts that required careful balance between a series of discrete ideas.
I wonder a lot about how much of the noise margin present in current research and work is caused by related developmental issues.
$ perl -E 'unlink("/etc/passwd"); say (0+$!)'
13
$ grep 13 /usr/include/asm-generic/errno-base.h
#define EACCES 13 /* Permission denied */
$ perl -E 'unlink("/etc/passwd"); say $!'
Permission denied
Thanks for the example too!
The list of features is impressive, but taken together all at once can be daunting. I think that's why there's so much distaste for it in certain camps. It's actually possible in a function to test whether the caller wants a single value or a list and adjust your return accordingly. It has anonymous functions. It has closures. It has map() and sort(), either of which apply a custom block of code to a list. You can easily write user-supplied functions that do that, too. It has dictionaries / associative arrays (called "hashes" in the community since that's how they are implemented), regular arrays, scalar values, and a number of different object systems from which to choose.
But for smaller scripts that automate tedious tasks or massage data to connect two otherwise software systems or generate a report-ish overview of a database/table, it is very hard to beat. Ruby comes close, but then again, Perl has been relentlessly optimized and fine-tuned over the last ~15 years, so for the stereotypical use-cases it is actually very fast, even compared to what one could cook up in C without weeks of hand-optimization and tweaking.
Someone once said that Perl is to batch-processing of text what Emacs is to interactive editing. I think the comparison is somewhat accurate.
perl5.6.2 still blows away all newer releases performance and memory usage wise. 15 years ago the author was still active.
stableperl (http://blog.schmorp.de/2015-06-06-a-stable-perl.html) is a fork of perl 5.22 with a couple of tiny reversions that re-enable access to some internal state required by certain CPAN modules.
The author talks in other blog posts (http://blog.schmorp.de/2016-12-29-griefing-the-perl-api.html, http://blog.schmorp.de/2015-11-12-tidbits-why-coro-crashes-o..., http://blog.schmorp.de/2015-12-15-tidbits-cgipm-a-data-point...) about the decline of Perl's cohesion.
It's sad to see.
--
EDIT: And now I'm being downvoted.
I have no problem with Perl, I watched the Perl 6 presentation when it was released with great interest.
Perl remains on my list of languages to learn (I know, I know...). It's up there. And that's why I said I was sad to see datapoints like the one I linked. I want Perl to keep going strong, and I hope it lasts another 20 years. I guess I added this comment because I wanted to find out if there was anything I could do.
I wouldn't mind learning more about this, perhaps via email (as an alternative to public discussion that might(?) start a flamewar).
This week I realised that a script I wrote about ten years ago has become an indispensable part of my company's infrastructure: it converts Office documents to PDF using OLE. It's about 30 lines long of very clear code.
To be honest, I think Perl still powers a whole lot of systems, and certainly is a powerful tool for someone who is a Unix sysadmin, but this kind of job is dying. And as a language, I think Perl has nothing on Python or even Ruby, or even PHP nowadays.
I then see it happen they no longer have any knowledge about systems and their processes, just outsourcing. And often, things then go downhill quite fast in service which leads to less happy customers which leads to lower company/employee moral etc.
People not knowing what computing power certain processes need or what its worth in money (over/under specced nodes), or backup processes not properly monitored or setup.
In all seriousness I'm glad with these changes. I'm paid more to be NIX sysadmin, with minimal working knowledge of AWS/Azure/GCP.
All hail buzzword!
method foo(bar):
self.do_foo(bar+self.baz)
> Please resist commenting about being downvoted. It never does any good, and it makes boring reading.
You could try to monkeypatch it by creating a decorator that will mess around with the closures of methods to make it work, but I don't understand _why_ you would want to do that.
- Big company bought lots of different hotel sites
- Big company decided to consolidate them into one system
- Booking (the Perl shop) won out
So I don't think it's necessarily just that "it started in Perl", if so then it could easily have been consolidated based on one of the other platforms that were not Perl based
I don't think this job is dying, but rather evolving. Of the Unix admins I learned under, only the ones who were also okay programmers and adapted have a great job right now. The writing is on the wall for those that can't/refuse to program. I had an interview with Facebook and they were bragging about laying off 100's of sysadmins with a machine learning model.
Also, this is anecdotal, but of my friends who are software engs only, I make more as a "Systems Engineer" or "DevOps Engineer" or whatever buzzword by knowing systems and a moderate level of programming, but it is the same skills from the 90's applied to the "cloud".
Basically, sometimes it's not a choice.
Looking forward to a Perl6 stable release. It is stable but Rakudo still needs a bit of polush. Also it doesn't have the amount of modules Perl5 has. What it does have however, is precise arithmetic because numbers in Perl6 are internally represented as rationals.
Although it's merely a list. But you have zef, an installer that pulls and installs modules.
Hence why I feel that a proper CPAN equivalent does not currently exist. The Perl 6 website even admits such.
Still, it does work reasonably well for now.
- Great for sys admin stuff. Working with files and external programs is a breeze. *NIX administration is how I got into Perl. Perl is a devops friend.
- Handy for processing anything text based. Tedious tasks like screen scraping is straight forward.
- Versatile. Don't like X in Perl? Someone else probably thought the same thing and made a module for it. Even low level stuff like Perl subroutines and OO have alternatives. As they say in Perl TIMTOWTDI (there is more than one way to do it).
- So many modules! Write less code and get stuff done fast.
- Low level voodoo is easy. Perl exposes many of the internals of the interpreter so things like adding grammars and making DSL's doesn't seem like voodoo.
- Multi-paradigm. Doesn't force a programming style on you.
- Complex data types.
Not that everything is unicorns and rainbows in the world of Perl.
- Some features/syntax can feel outdated or seem "clunky" for lack of a better term.
- Versatility is a double-edged sword. You can write code so bad/evil it can summon an elder god and Perl will happily execute it.
- So much punctuation!
If your new to the world of Perl, try out Perl 6. It has all the cool features of Perl 5 and ditches most of the weird stuff but has all the modern features you would expect from other new(er) languages.
I regularly see Perl jobs posted in London, but the wages are surprisingly poor, compared to what I could get for my Django knowledge.
When you take that into account, the salary would need to be at a real premium to make it worthwhile, and the premium just isn't there.
I suspect there is too much else going on for a comparison of salaries by language to be meaningful. Those Perl programmers are probably highly paid mainly because they have 20ish years of experience, and lots of other valuable Linux/Unix experience. There are probably lots of fresh graduate and entry level JavaScript / Java / C++ developers bringing down those averages.
I always get a good laugh when I see job ads for a "Junior Perl developer" paying 25k GBP or something. They stopped making those 20 years ago.
I think there are a number of reasons for this. One is that a lot more Perl code got written by non programmers (sysadmins) than Python code. People know Perl for regexes and "golf" (writing extremely short code), which looks like "compressed" (as in Closure/uglify compiled) JavaScript: Ugly.
The main thing that I disliked about Perl is something I also dislike about C, which is writing arrows. Other than that using other languages like Python didn't get me a lot.
You can and will write ugly, unmaintainable code and long unreadable lines in both Python and Perl. The main thing that makes Python look prettier seems to be forced indention, but believe it or not Perl can be indented too. The other thing probably are sigils, which are also a rather powerful feature.
There are of course different tradeoffs. Perl is more on the Ruby/JavaScript side, where people prefer expressiveness of code, where Python people prefer simplicity. And while I always for simplicity I don't think whether the community in large sets a bit more focus here or there there doesn't seem to be a great indicator for whether to choose one or the other language.
When comparing Perl with Python or Ruby, which I think are maybe other than JavaScript make the most sense in terms of use cases I think Perl influenced both of them more than a lot of programmers realize.
Despite the others being very mature I think Perl would wins on the edge of having solid modules and infrastructure. It certainly doesn't win in terms of image and popularity. What is nice about Perl is that the shortcomings of the languages have been largely compensated via modules. That includes modules that add changes to the syntax or add really big features like Moose, adding a lot around the topic of Object Oriented Programming, more than you have available in other languages.
Another thing I want to point out is, that Mojolicious is by far the best web framework I've seen so far. It's my personal opinion, but it beats everything available in the Python and Ruby world by far. And at least with Python I've used Django and Flask for multiple years, as well as taken a look at others.
The eco system in general is really good. There is a lot in regards to testing. If you really are into test driven development that alone might be a reason to give Perl a shot and be it simply to steal some ideas around this topic. That includes many modules around the topic of testing as well as CPAN Testers and other things.
For the bad side. Other than reputation, the learning curve is higher. This has a multitude of reasons. One is that Perl was designed after natural languages, which explains many of its oddities. That's why it isn't as easy to pick up as other languages. Knowing other languages simply might not help you as much.
Another is that a lot of very old and bad Perl tutorials are around. So one might want to look at something that in one way or the other mentions Modern Perl.
One might think to know and understand Perl really quickly, but it simply takes longer than knowing how to write Perl. This is why it makes a lot of sense to read Perl code from some "big people" in the community.
In terms of industry usage. I think the big names here are DuckDuckGo, Craigslist, eBay (I think), Amazon (I think).
However that probably is very outdated.
A good reason to not learn Perl is if you want a simple language. Perl simply is not that. I changed to prefer simple languages, which might be the reason I am now sticking mostly to Go and Python. However, it might open your eyes about different ways of simplicity here and there.
It's also good to know the other side and know how "simple" certain more complex tasks can be, if you just approach them with another tool.
Okay, this wasn't so much about the industry. It's certainly around, both for older and newer projects. I've seen it both in the Enterprise and Startup scene and not just online.
It's more quiet, but then most projects that have been around for a while don't have any big news. Debian, Postgres, various OSs, etc.
Oh one more reason: If you like it boring to get stuff done then use Perl. I think the Perl5/Perl6 thing is over and everyone agrees they are two different languages, so it's not like in Python where you still have so many projects supporting just a subset of Python in order to keep compatibility.
I think if you have Perl developers, which certainly exist, even in large quantities, choosing that one rather than Python certainly won't give you a big downside or so.
I think they are pretty much the same in that regard, even though I am pretty sure that neither community would agree on that statement.
I chose Python and Go for everything I do, mostly cause I haven't been programming Perl in ages and so my development setup, my muscle memory, etc. and money is all there, still I don't think other than that Python really has an edge over Perl. Again. I know people will disagree.
I haven't touched Perl in 10+ years. At all in fact. So if anything I am biased towards Python.
You're in luck. Perl6 dropped the arrows. It's using dots just like everyone else. It also dropped the floating point math, so you can now do precise calculations natively which is a big deal for financial and scientific software.
I can second Mojolicious being one of the best web frameworks. We are using it for our web infrastructure. Basically we did a full rewrite from CGI.pm to Mojolicious. It is however Sinatra inspired, so let's give credit where credit is due.
perl5 is still top 10, runs tons of code, has one of the hugest library codebases (CPAN), and is much easier to use than e.g. python or php. ruby is better, but slower. You cannot use simply a repl in whitespace formatted language (python), and trivial scripts get soon overly large. with perl sysadmin tasks or extending bash scripts is trivial. why gdb chose python over perl is not a technical decision (perl would have fit much better), but more a management decision. perl5 is going nowhere, and python is also stagnating, just slower. with ruby there still is a bit of hope. php done everything right, but still got its legacy coders and the horribly designed old stdlib.