Perl 5.26.0 released
nntp.perl.org
nntp.perl.org
Btw., as mentioned in announcement. The actual changes are here, if you missed that:
https://metacpan.org/pod/release/XSAWYERX/perl-5.26.0/pod/pe...
Except for any other language than english.
I have mental images of driving a wildly overpowered monster truck with no brake lines over a minefield. And then I start to consider the implications of passing the /i flag in...
Will your regex match correctly in the case that the text shifts direction halfway through? Will the case insensitive search work in languages where case is ambiguous (where uc(lc(x)) != x)? Will you be able to match letters that are effectively identical but on different code points? Do you want to? Will it get confused by furigana?
Unicode's goal of encoding every language in the world as is means it encompasses every bizarre thing people have ever done to a written language. It is almost impossible to actually do anything with a block of unicode codepoints except treat it like a big binary blob and hope that you never have to personally deal with the strings contained therein. Most everybody gets it wrong in one way or another.
Compare it to the "non-community" professional effort https://github.com/perl11/cperl/releases/tag/cperl-5.26.0 http://perl11.org/cperl/perl5260cdelta.html
regular expressions are much better with pcre2, which almost work (50% faster) with https://metacpan.org/pod/re::engine::PCRE2
I didn't only disagree with some patches, I disagree with most of the feature decisions, management and bugfix handling. And esp. with their negative track record. perl5 deserves a properly managed project and the perl6 features, so I did it. At an important time, with :const, types and signatures upcoming. And perl5 should not be used in public services due to its lack of security (I am warning against it since 5.16), not talking about the feature mishandling.
See the perl11 blog.
Some numbers: In the last 2 years, p5p produced 12005 commits (2 releases), whilst I produced 6291 commits. That's >30%. The 2nd most prolific author did 3104 (unicode), the third 1689. And I squash commits into features and bugfixes and don't spread it out over 3-5 postfixes, because cperl works in branches, not posting directly to master. Of those 6291 commits you have nothing in perl5, but they continue to play stupid and take nothing. Features wise and security fixes it's more like 1000%, not 30%.
In the long run switching out to a fast VM for tight loops like p2, rperl or spvm (formerly called sperl) is still being considered. Perl6 inline::perl5 is unfortunately not doing too good, and I see no way forward with their architecture.
perl11 is doing very well. Many perl6 features are already in cperl, many more not yet completed. The design is done and sound.
That seems like an awfully bold claim.
cperl is great, don't get me wrong, but if I'm going to move away from Perl 5 to a different Perl I'd rather just move to Perl 6 (and, in fact, I already have for some of my latest pet projects; so far, I've been very impressed).
cperl is a not a different perl, it's a perl5 replacement, which is faster, more secure, less bugs and more features. types and using a modern perl is optional. 90% of the vm and toolchain is unmaintained by p5p, and taken over by cperl.
Perl was never intended to be fast for computers. It was intended to be fast for programmers. Perl 6 does a pretty darn good job of that, and additionally already has working and easy-to-use C/C++-compatible FFI that I can use today to offload things that really do require maximum computational performance (that latter point wasn't true for cperl last I checked; "extern sub ..." is still a "todo" item AFAICT, and I don't really see an equivalent to Perl 6's "is repr(CPointer)").
"and unusable for professional usage."
By what measure? More importantly, by what measure in which cperl fares any better?
"more features"
Not at all the impression I'm getting from perl11.org/cperl in relation to Perl 6. What you're saying is certainly true in relation to Perl 5, though.
Of course cperl is lacking compared to perl6 features, user facing. Because I had to fight first p5p sloth, like broken designs for everything. cow, const, threads, attributes, regex, scalar, arrays, hashes, functions, types, lecical $_, objects, symbols, unicode, build system, warnings, exceptions, the VM, ... http://perl11.org/blog/p5p-incompetence.html is a short overview of the technical problems to be fixed.
Professional use: read cperlpod cperl. No security process and competence, lack of progress, lack of maintainance of critical modules (cpan is fine, p5p and toolchain authors are the problem), no types, no compiler, recommending worst practices to move towards Java, no technical management, just community leaders without any idea what they are deciding, loosing all competent devs in the last decades and with just the remaining dead wood vocally protecting their turf, with the usual racial and more unpleasant slurs of the leadership towards its users and co-devs. As company you wouldn't want to be associated with them, but their counter propaganda silencing and censoring the critics works well.
While you censored me from adding comments to the old official discussion channels, I will not censor you on the new discussion channel /r/cperl or here. I just don't accept illegal comments as they used to happen on the old channels (asshole and such).
Whenever I think of something that has anything to do with batch data munging, there is usually half a dozen Perl modules that already do it. I have no opinion about Perl as a language but I like how rich the ecosystems is for that sort of project.
CPAN was way ahead of the competition - it was elegant where other languages would require you to manually download dependencies archives and wrangle them like a barbarian.
This is a really nice alternative to CI services and it makes sure that your stuff works in other environments than your standard Ubuntu LTS systems.
It's pretty much crowd funded CI and I am pretty sure that a lot of people who don't have the most common system would love to run it.
What's cool about this is that you see problems on both the platform and the library side, that one wouldn't expect.
Something similar, also from ages ago, but an anecdote I like to tell is that I used to have access to a hppa64 (64 bit PA-RISC) system and while I didn't really have use for it I as a fun project installed OpenBSD on it and ran some test suites there. Despite OpenBSD/hppa64 15 years or so ago being an alpha release Rakudo (aka Perl 6) actually compiled and was able to run its test suite. In the end this found a bug in math.floor or something like this.
The point is that something like that tends to have unexpected benefits for both sides. It's like when someone decides to compile a project using a less common C compiler. That pretty often leads to people finding bugs in the given software, because of errors or warnings emitted by that compiler. Similar things happen with different architectures, etc. So in the end cross platform software ends up way more reliable. Something that I think some projects focusing on only one OS or even just one or very few distros really miss out.
Of course reducing your project to work on just one platform might safe you some time somewhere, but often it's a bit like saying not writing tests safes some time. And usually it's really little or no effort, which results in a lot more feedback and quality code contributions (people that port a lot of software tend to be pretty good programmers).
I don't know why Perl 1 to Perl 4 had messed up Regular Expression. Perl 5 actually redeemed themselves and returned to the normal good old regular expressions.
> Regexes in Perl are not he same as in Python, Ruby, or PHP, even if some of them call them "Perl 5 compatible Regular Expressions". https://perlmaven.com/introduction-to-regexes-in-perl
I would say the older Perl messed with RegEx and I wish everyone else would get on board. I HATED!!!!! doing my awk regex and then jumping into Perl it wouldn't work.
Most of the horror stories that you'll hear about perl are from people who have tried to fix/maintain code that was written badly, which is no different from any other language. You can write horrific or easily-readable code in any language.
Perhaps perl has its reputation because it is often used as a quick kludge to do something that would be just too painful to do in shell script, and novice writers just cut & paste stuff from their searches online to get the job done?
I recall a great talk a couple years ago at OSCON that Damian Conway gave about how you could essentially turn Perl into a custom language that exactly fit your needs. I walked out of there thinking "wow! That is incredibly awesome, and yet I would never consider it for a business environment." Perl is an appealing language for people who like languages. I count myself as one of those. But I cannot deny that Python makes so much more sense for teams of more than one person.
At that point the difference is just syntax.
It's a tool that can be abused. Saying that the number of tools available should be limited so that they can't be abused seems counter-productive.
See static typing, golang, and functional languages.
function myFunc () {
var myFunc2 = function () {};
return myFunc3().then(myFunc2);
}
> At that point the difference is just syntax.
Isn't that the case with most things? If I said that I missed curly braces, that's "just syntax" too.
You're right that almost all dynamic languages have this feature, but to give you two notable languages that don't: C doesn't allow defining inner functions. Pascal allows to define inner functions, but doesn't allow you to return them. C++ does allow you to define inner functions (actually functor classes) and allows you to return them, but you need to be explicit about the capturing process.
It is less frustrating for me than the fact that the scoping rules for a var in JavaScript mean that you're likely to scope to the nearest function call rather than loop. Despite having anonymous functions, doing what I would want to do with them in JavaScript is often much harder than doing it in Python.
>This isn't some Python-specific thing.
I think btilly meant that by the ability to do in Python what he described (define a nested function and then return it), you get (almost) all the same features as anonymous functions (and specifically, more than Python's lambdas give you, because they can only contain an expression, not statements) - in response to what you said:
>Python just has lambda functions which can only evaluate an expression.
In fact, IIRC, Guido (van Rossum, Python creator) has been known to say, to people who complain about the limitations of lambda in Python, to just use nested functions. And BTW they are quite powerful so you can do a lot with them.
He (btilly) was not implying that other languages cannot have nested function declarations (if I understood his comment right).
I'm not saying that they aren't powerful. I'm saying that personally, I find declaring one-time-use functions in-line to be syntactically more pleasant / organized than sticking the function definition in the middle of functional code.
I'm not a newbie to Python, but after working with it for years, it's one of those things that I still wish existed. It's not necessarily a pain point or deal breaker or anything. I'm not even sure how it could work given Python's syntax.
Ok, I get what you mean now, and think you have a point there.
All of those other languages "just work" too. I'm not really sure what you're getting at with this comment.
I worked with Perl 5.x in for 4 years a while ago. It's not as bad as people really think it is. That said, there are a lot of things that can cause you to go wrong. For example: source filters. Super powerful, but if implemented wrong can make debugging a nightmare.
Why does it have something called 'say' instead of something more intuitive like 'println'. Then there are worse examples: carp, cluck, croak. These are commonly used. They are from the same module of course. There is also Moo, Moose. I'm not sure but was there something called 'Mo' too? Commonly used of course but as you can see from the names - you can't tell what they are for.
So, I think from some of the choices made in how the language is, it ended up being more drawn towards unreadability than readability by attracting a kind of mindset that wanted it to be 'fun' in a way that only a clique could relate to and now if the language doesn't have broad appeal, I think it shouldn't be that hard for them to accept that fact.
In fact Moose, Catalyst, Starman, etc were all projects specifically named more fun _becasue_ their authors saw other communities not naming things "DBIx::Class" or "ExtUtils::MakeMaker" and wanted to bring some of that fun to Perl.
Why is the Unix command `ls` not `list-directory-contents`? Sure, it's a lot more for everyone to type all the time, but you could get rid of a single line in the man page, meaning the name is much, much more intuitive!
'say' is a lot more intuitive than 'println' for me. In the former case, I'm telling my program to say something. In the latter case, I'm telling it to... print? What if I don't have a printer? And what's a 'ln'? Line? Loan? Loon?
In other words, 'println' is not "intuitive". The word you're looking for is "conventional" or "familiar", and it's only either or both of those things if the programmer is coming from a different language.
Perl was the first programming language that really "clicked" for me, though, so I'm probably a bit biased there.
(as a side note, Perl has a 'print' as well, which actually predates 'say' by a considerable amount ('say' only became a thing in, what, Perl 5.10?). 'say' is pretty much just 'sub say { print "$_[0]\n"; }'.)
"Then there are worse examples: carp, cluck, croak."
'carp' and 'cluck' are weird, yeah. 'croak', however, makes sense in the context of 'die'.
"There is also Moo, Moose."
Both of which feature the letters "oo", which usually stands for "object-oriented". Not as obvious as I'd personally like, but once you spot that it becomes clear that both have at least something to do with Perl5's object system.
But yeah. Perl 5's flavor of object-orientation is remarkable for exposing the inner workings of objects to the programmer. Fields are just hash table items. Methods are just subs that take the object as the first parameter. Classes are just namespaces/modules full of methods and constructors. Constructors are just ordinary subs that return blessed data structures.
It's all remarkably simple and elegant once you're used to it.
"Say" is a common English verb that fairly directly communicates the action performed (with a bit of metaphor, sure.)
"Println" is, well it starts out with something which might be as good as "say" and then has some extra opaque consonants glued on the end.
The latter is only "more intuitive" from the perspective of someone whose used languages which happen to use it in the past.
I'm not a Perl expert, but have read books on it and done a bit with it. I think Perl tends to attract the kind of people who find these kinds of names (and many other things) fun, and are not put off by it - which is fine.
>worse examples
According to who(m)? Opinions differ.
(I'm sure there must be other languages with dedicated regex syntax, but I'm not aware of any.)
/foo\sbar/i;
new RegExp('foo\\sbar', 'i'); $str =~ m{/some/path/\w+}
/\/some\/path\/\w+/
Regexp("/some/path/\\w+")So, you've never seen Ruby?
If you mean at "parsing text", for which regexes are a tool, I don't think many other languages have caught up with Perl, which had (with Perl 6) gone beyond regexes to grammars.
But, even ignoring that, I think plenty of languages have regex engines less powerful than Perl's, and poorer ergonomics for using regexes in the language independent of regex engine quality so even on regexes as such Perl has an advantage.
P.S. I am student and I have no real perspective on what is going on in industry right now.
Basically, sometimes it's not a choice.
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".
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.
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.
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.
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.
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.
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.
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.
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.
- 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.
Its a very easy language to learn. My first language was C back in 1994. I was in high school and encouraged to learn C before I learned Perl.
I read my books. I kept on going after it. Then finally six years later I started learning Perl.
Perl is a great language.
I haven't touched Perl6 yet - I bet its even better. It might take me 20 years just to do a hello world in it and optimize it.
Larry gave us a great place to start. Guido is awesome too.
"I don't like big bloated snakes though" -- I heard this back in 1996 or so...
We have been focusing on languages for 20k years or so. We have built computers for about 100 years - and invented languages to talk to them.
It wouldn't be my first choice but there is plenty of reasonable paying work around.