I don't care how un-sexy perl is by current standards. It's damn efficient, even for new projects. Also, it's not hard for a developper worth its salt to get productive in perl.
At the moment I'm playing with some threaded perl to parse very large text files - part of the code was developed by a C++/Java/js fan, who just realized it was the best tool for the job, and created that after a few days of playing with perl.
But is that really unique to Perl these days? It may have been true in the mid-1990s, but things have changed since then.
Python and Ruby both have a much cleaner syntax, yet still offer very comparable functionality, excellent portability, ample standard and third-party libraries, excellent documentation, supportive communities, great regex support, and basically everything else that Perl offers.
Since everything positive about Perl is also offered by alternative languages today, and those alternatives are themselves much better than Perl in some respects, Perl seems like a less and less enticing option each day.
>>It may have been true in the mid-1990s, but things have changed since then.
Hardly anything has changed. No language has taken scripting that seriously. You are likely confused between dynamic languages and scripting langauges. There is a big difference. If you haven't noticed, well then that's the whole point behind Perl. You really need to use it to see what it is.
>>Python and Ruby both have a much cleaner syntax
Its not about having a cleaner syntax. Making it easy to learn, only means the complexity is left to the programmer to handle now. Either way some one needs to handle the complexity, Its either the programmer or the language. If you make the language simpler, the complexity burden shifts to the programmer.
>>yet still offer very comparable functionality, excellent portability, ample standard and third-party libraries, excellent documentation, supportive communities, great regex support, and basically everything else that Perl offers.
Python takes great care to purposefully avoid offering every thing that Perl offers.
>>Since everything positive about Perl is also offered by alternative languages today, and those alternatives are themselves much better than Perl in some respects
You will have to substantiate that point with some evidence.
>>Perl seems like a less and less enticing option each day.
Perl is a great tool for scripting, but calling it "unmatched" is hard to justify. Knowing Python or Ruby well, you can be efficient scripting with them, and that's what scripting is all about, getting the job done fast.
Higher Order Perl is one of the best books I've read, but I feel that's much more about software development than scripting, teaching the fundamental techniques in functional programming.
Short answer: python is perl for bureaucrats and computer scientists. Ruby is perl for people who realised php is awful.
Perl fits the same niche as English does for natural language - used everywhere, easy to learn for simple cases,very tough to master. The way I like to say it is that while most programming languages help you think more like the computer, perl helps the computer think more like you do.
Those books look pretty general. Could you perhaps give just one or two examples which make Perl great specifically for scripting, to someone who does not know any Perl at all?
I was really just asking for a couple of short examples of scripts that demonstrate your point, based on Perl as it is now, not anything regarding its history.
"Scripting" is a pretty vague term. If you mean quickly writing one-off programs, then there are many languages that are just as good as Perl, if not significantly better.
It's pretty clear that Perl does not hold the prominence it once held in the 1990s. So, yes, it is clearly becoming a less-enticing option for a lot of people, whether you're willing to admit this or not.
It could be familiarity, but for small- to medium-scale "scripts", I still find Perl to be the best alternative to bash+sed+awk+grep thrown in, when I want to go to something more conventionally programming-ish. Basically its original use-case, before Modern Perl.
You can use Python for that, but the jump from Unix shell to Python feels bigger; everything is more verbose and less awk-y in Python. Which can be good for maintainability of bigger scripts, but feels heavyweight for some stuff.
Yeah, it's not just about shelling out, but about being able to write Perl that works sort of like an awk script, just with more of a real language attached to it. Functions that implicitly work on the current line, lightweight regex syntax, the <FILE> magic, bash-style file tests (-e/-r/-d/-f), etc.
Perl has reader macros and a meta-object protocol upon the object system is built with. Ruby and Python don't have either AFAIK. That is an example of what the OP is saying with Perl is an extensible language.
> Perl has reader macros and a meta-object protocol upon the object system is built with.
More specifically, Perl has advanced features with which meta-object protocols can be built with. See Class::MOP on which Moose is built.
> That is an example of what the OP is saying with Perl is an extensible language.
I think the difficulty with Ruby and Python is that both are fully object-oriented, which means it is difficult to create something that is truly orthogonal to the object model.
I generally use a graphical debugger in Eclipse. I have used Python and Perl, and can't see too much difference between them. Whats better about the Perl one?
Cleaner syntax than the declarative class mentioned in the article?
> Since everything positive about Perl is also offered by alternative languages today, and those alternatives are themselves much better than Perl in some respects, Perl seems like a less and less enticing option each day.
To my mind though the benefit is in mutability of the language. Yes, there are other languages in this category (rebol, red, lisp), Perl is somewhere between these and Python and Ruby. If I were to order them from most mutable to least, I would go lisp, rebol, red, perl, (python and ruby). This is a powerful thing and of course with great power comes the possibility of misuse.
Every time I try and write python or ruby I get an hour or so in and find that I'm writing 5x as much code as I would in Moo/Moose just to express the object design I want.
I've been known to say "perl5 is a lot like ruby except with usable OO" and it's very much a "ha ha only serious" sort of comment.
I used to sell software to very large corporations, and for enterprise-wide deployment. You won't sell them anything written in Perl, nor will you find them automating systems with it (there are domain specific languages for performing OAM&P on large numbers of systems.
If you want "no questions asked" in this environment, you need to pick Java ... and as of JavaEE6/7, it's a much more efficient language. Granted that it's not as dense as Perl, but it's also type-safe and with good conventions, readable.
If you're developing SaaS, use what you're most productive with (assuming you're not productive simply because you're creating crap). I've see people who can write in beautiful Perl, and I have no problem reading it. I've also seen people who write whole programs on one line just because they can ... and a couple months later, they can't read it either. Note that I've also seen bad Java, Python, etc programming.
True on the sales point. And it's getting harder and harder to find coders who want to spend all their time writing perl, as great as it is. That makes it tough for enterprises to maintain perl codebases.
Also, more CPAN libraries seem to be in a state of atrophy these days and I think the long-looming specter of perl 6 has had a depressing effect on that community.
The post talks about Moose, which is a behemoth with huge and varied dependencies and must be be tougher to maintain these days. Every time I've tried to write a project in Moose, I've regretted it in the long run.
However, I've written plenty of big, enterprise-class projects in perl instead of buying them from major vendors. Over the years, we were almost always able to beat the value proposition of Big Software precisely because we had a solid team of perl coders.
Don't underestimate the effect that the Perl 6 disaster has had on the reputation of Perl as a whole, even if Perl 6 is a rather different language in many ways, and generally promoted by a separate community.
Even if the Perl 5 community has generally admitted that Perl 6 was a failure and has moved on, a lot of people first think about how disastrous Perl 6 was well before they think about anything positive involving Perl 5.
> The spectre of perl6 stopped bothering us about 2006
From a practical usage standpoint, sure. But wouldn't you agree that an effective major version freeze has had a chilling effect on the progression of the language?
I'd argue it's had a deleterious effect to varying degrees, even since 2006. It's not enough for a community to be not bothered. They need to be energized, and it's tough to make the argument that the perl6 snafu has been helpful to the perl movement.
> CPAN uploads have been up every year since.
CPAN traffic was down over 10% last year, according to Alexa. In fact, many perl popularity metrics were down at least 10% in 2013. [0]
My experience, admittedly anecdotal, is that CPAN packages in general are not maintained with the same vigor as in years past. But why would they be, if people are moving their focus to other languages?
Regarding Moo, thanks - I'll definitely have a look.
2006 is when the energy around perl5 / new wave of cpan development became palpable to me.
Have a look at Task::Kensho - you'll find a fair chunk of the stuff mentioned in there originates from 2006-2009 or so (and has been actively developed since).
> My experience, admittedly anecdotal, is that CPAN packages in general are not maintained with the same vigor as in years past. But why would they be, if people are moving their focus to other languages?
That or the CPAN packages you've been using have been superceded but you've not found the replacement.
We're fairly terrible as a community at communicating when that happens.
If the OS is Windows, as it often is in these environments, C# seems to strike the best balance between safety, ease of recruitment, and flexibility. I have not used it in several years, but I still look back and miss awesome elements of the language like linq, the selection of super polished UI frameworks, Visual Studio, the ability to use dynamics when you needed to, the lack of drama in the community, and the ease of finding answers to obscure questions on SO. Of course, I left the platform for a lot of the same reasons, but in the context of being increasingly involved with OSS. That said, the positives still hold true for the enterprise space you are describing.
> Granted that it's not as dense as Perl, but it's also type-safe and with good conventions, readable.
The argument for Java is that there is a wide developer base, and lots of libraries. Perl, with appropriate frameworks, can be remarkably typesafe too (see Moose, etc). It's still loosely typed under the surface, but you have good error handling of invalid type syntaxes as long as you don't break encapsulation.
The big things I am looking at though are:
1. Maintenance and testing.
2. Readability
You can write unreadable crap in any language. What Perl excels at is allowing you to improve readability and maintenance/testing by building mini-dsl's in your framework which reduce testing footprints.
It's really hard to write unreadable crap in Java. Even if you do, there's automated refactoring to fix it. That's the thing about Java. It makes it really hard for clever bad programmers to do a lot of damage to a project. With Perl the sky's the limit.
People say the same about Python, but it is completely possible. Deeply nested hashes with no comments explaining the structure. Variable names such as 'Indexes' and 'indexes' in the same function. I have had to rewrite code like that.
As long as function and variable names are arbitrary, you can write code that appears to do one thing and does something else. Far more damage can be done that way than by straight obfuscation.
> Also, it's not hard for a developper worth its salt to get productive in perl.
Unfortunately, it's productivity gained at a very high cost, which becomes apparent once you try to debug and maintain that piece of software.
Sure, Moose and other modern helpers will fix that to some extent, sometimes with other tradeoffs (performance). But the "malleability" of Perl feels silly at some point where you get a bloated, slow and lacking simulation of a type-safe language when you could use a much faster modern language with real static type checks and great maintainability (like Go) instead.
> Unfortunately, it's productivity gained at a very high cost, which becomes apparent once you try to debug and maintain that piece of software.
You can write untestable, unmaintainable software in any language. I will agree with you that the default scoping of variables has some real costs in terms of maintenance and debugging that are not initially apparent to too many programmers though.
> Sure, Moose and other modern helpers will fix that to some extent, sometimes with other tradeoffs (performance).
Moose has performance impacts. If you want something less heavy, use Moo, or Role::Tiny. These offer fewer features and better performance. Also as I recently learned, lexically scoped variables are faster, so use strict can in fact sometimes flag possible performance improvements there.
> But the "malleability" of Perl feels silly at some point where you get a bloated, slow and lacking simulation of a type-safe language when you could use a much faster modern language with real static type checks and great maintainability (like Go) instead.
To be honest, the other languages I really like in this regard are red and rebol, which are, if anything, more malleable. The malleability is important because, done properly, it allows:
You need coding standards for all languages. Most (afaik) Perl shops use Conway's "Perl Best Practices" with some local changes. Go read "Modern Perl" etc. Are you not aware of those developments? PBP isn't exactly new.
I don't think there are references of these problems while following good practices? Considering all the trolls which show up when Perl is mentioned, I ought to have seen such a link a long time ago...
But sure, we could assume without support (I don't know) that using Perl forces you to read a few more pages of coding standards. That is, as percentage of work time over a long project, not a problem.
>> [Go preaching]
Today, I don't see much practical difference among the usual scripting languages (they tend to port the successful stuff from each others). Also their niches are partly different compared to the niches for Go. So there is no need to preach.
One big advantage with Perl is that I am not often embarrassed by fan boys and/or language war fanatics, as you find in some other environments...
What's the point of programming in a language that has 100 ways to do something, and then banning all but 99 of them? Why would you use a language if you don't agree that the designers did a good job? That's like going to a burger joint and ordering a salad. Only someone hell-bent on maintaining an emotional connection to a worn-out old programming language, would even consider that.
I've never seen a project that could enforce its coding standards in every case. Things always slipped through. Turns out, machines are much better at enforcing arbitrary coding standards than humans. Maybe we should let the machines do the machines' job, and the humans do the humans' job.
Perl has all the problems of an old language. No commonly-agreed on coding style (you'll get flamed to a crisp in some parts for even talking about Modern Perl), no single object framework (Moose, Class::Accessor, Object::Tiny, Role::Tiny, and plain old "inside out object." References are confusing and unnecessary (neither Python nor Ruby needed to make an artifical distinction between references and non-references). All the various different ways that things can fail at runtime are a huge burden, especially when you combine them with the different modes that perl itself can be run in, like "use strict" versus not.
Just about the only thing Perl did right was regular expressions. That, and avoiding the version hell that Python got itself into.
Perl was fun in the early 90s, but it's time to let go. Only a masochist would use it today. Only a sadist would recommend it to newcomers.
What's the point of programming in a language that has 100 ways to do something, and then banning all but 99 of them?
Because the real world comes with edge cases. Just because 99 times out of 100 you're better off with the agreed upon standard, doesn't mean that other way doesn't have it's distinct time and place that it can shine, and clearer, cleaner and or faster. I would much rather be constrained by convention than by capability.
no single object framework
No, but the reason for that's been a good one historically (experiment and see what comes out on top). That ended up being Moose and it's ilk (Moo, Mouse). I can't think of a single case I've heard about where people used something else and it wasn't driven by some external factor.
References are confusing and unnecessary
I've always liked references. It seems to make clear exactly what's going on. Maybe it's just me.
Only a masochist would use it today. Only a sadist would recommend it to newcomers.
You should have started your comment with this. Then I could have stopped reading there. Are you here to participate in an informed and enlightened discussion or to show everyone how brilliant you are for not liking something?
> References are confusing and unnecessary (neither Python nor Ruby needed to make an artifical distinction between references and non-references).
Perl references combined with its nested list semantics make it extremely convenient to flatten arrays and hashes when you need to. Doing the equivalent in Python and Ruby is verbose and ugly by comparison. I know in Ruby you can get it down to one line, but it lacks the cleanliness of Perl (if you can believe that).
> What's the point of programming in a language that has 100 ways to do something, and then banning all but 99 of them?
Two points in this. You might not want to ban all 99 in all cases. For example, you may want to do things one way in one aspect of a project and a different way in a different aspect.
This sounds dangerous (and power is dangerous), but done right it allows teams to focus on doing things right with the right interfaces between them.
For example, it's one thing to contribute to Moo, Moose, and PGObject in one way, but have a different coding convention internally for the programs which use these libraries. This is where those other 99 ways really come to be powerful.
> Why would you use a language if you don't agree that the designers did a good job?
I like the design of Perl 5. However, it took a lot to get to the point where I saw the beauty in it, and saw how to use the power properly.
In a larger project however, that's not so much of a problem. Once you get the core code started, people can grow within it. Different levels of the project may handle things differently, and that's fine. People can branch out over time.
> I've never seen a project that could enforce its coding standards in every case.
And sometimes the responsible decision is to let the coding standards violation occur and plan to fix it later. There are times I have done that and regretted it, only to later realize it was a net positive anyway.
> Maybe we should let the machines do the machines' job, and the humans do the humans' job.
Absolutely. Now to tell which is which.
> Perl has all the problems of an old language.
Evidently every 5 years or so we need to all jump on the bandwagon to a new language?
> No commonly-agreed on coding style (you'll get flamed to a crisp in some parts for even talking about Modern Perl), no single object framework (Moose, Class::Accessor, Object::Tiny, Role::Tiny, and plain old "inside out object."
There are lots of object structures but you probably shouldn't list Role::Tiny there. The basic point there is you have Moose, of which Mouse was an attempt to make it smaller for performance sensitive applications (now largely superceded by Moo). Role::Tiny is an attempt at a minimalist piece of Moose aimed at specific applications. Moo/Moose/Role::Tiny are best thought of as aspects of a single object system rather than separate ones. In fact Moo and Role::Tiny were authored by the same individual.
The Perl world has largely gone to Moose and friends. Pretty much everyone that uses anything else does so for legacy reasons or external constraints IME.
> References are confusing and unnecessary (neither Python nor Ruby needed to make an artifical distinction between references and non-references).
And yet I have been bitten by the lack of such a distinction in Python.
> All the various different ways that things can fail at runtime are a huge burden, especially when you combine them with the different modes that perl itself can be run in, like "use strict" versus not.
Meh, my test cases in any language use up more code than my production code anyway. There is no substitute for clear code contracts.
parsing text files is literally the only thing Perl is the best tool for. Of course, every single person who needs to update it would have a 20 hour RTFM session before they could do so. (fairly conservative; this is 3 hours per day for 7 days from a standing start to maintaining Perl.) Perl has a ton of context, and that context is really hard to learn (just try writing a Perl parser/interpreter), and it applies best to text files and configuration scripts from 1987-1997.
I am not saying it's not an appropriate tool for anything else. But as a tool to be learnt, it wouldn't be the 'best' tool for a new person to learn from scratch.
> parsing text files is literally the only thing Perl is the best tool for
To be honest, Ruby has built-in regexps also and Rebol has built in recursive descent parsing (and has no regexp support at all). So I disagree with you on two counts, the first is that Perl is the best tool always for parsing text files. To some extent it depends on what you are doing.
What I do think that Perl is really good at is building frameworks and the reason here is that what you can do (and what I highlighted in the article) is create mini-dsl's for common tasks which can then be seamlessly worked into the general purpose programming environment. Lisp can do this too, as can Rebol, but these each have other tradeoffs (I found the Lisp learning curve to be rather steep, Rebol 2 is not open source, Rebol 3, though open source, is still in alpha, and has no Linux GUI support yet).
> But as a tool to be learnt, it wouldn't be the 'best' tool for a new person to learn from scratch.
I don't know that there is a best tool for a new person to learn from scratch. One should generally apply tools I think with an intent of doing something with them. IMO, Perl excels at very big projects and very small projects. It's in the middle that things get less than ideal.
Yes that's correct. Atronix efforts have been towards producing 64-bit versions + the Linux GUI from the Saphiron code base (which was 32-bit and Windows GUI).
I believe you can consider this as the official build for Rebol3 View/GUI because Saphiron took over the RebGUI/R3-GUI project from Rebol Technologies.
But yes some of the Rebol 3 Core stuff that Saphiron/Altronix have done do need merging back into main open source core [1], which itself as moved on from the Saphir codebase (Saphiron Rebol build) [2].
The best I've come up with so far searching for information on MOPs (of the explicit, controllable sort) in those languages is sort-of/almost for Ruby and no for Python. Is there some other name they go by in those languages that I should be aware of?
* Some of the best languages for producing an internal DSL (dialects) don't have a "native MOP". For eg. Lisp, Rebol or Forth.
* Python & Ruby don't have native MOP's anyway :)
NB. I wonder what you mean by "native MOP" is baked-in OO? Python & Ruby OO systems do come with MOP like abilities. However for full blown (metacircular) MOP (http://en.wikipedia.org/wiki/Metaobject#Metaobject_protocol) you need to look at things like CLOS & Perl's Moose/Class::MOP.
By "native MOP" I really mean things like Python's metaclasses and descriptors (and whatever Ruby's equivalents are called), as opposed to an add-on library to simulate them like Moose.
A bit of apple & oranges going on here because you don't need Moose (or more precisely Class::MOP) to simulate Python metaclasses and descriptors. Because you could, if you so wished, build a Python metaclasse/descriptor based OO system in Perl's native OO.
To clarify things:
* Python comes with a pre-defined OO system with metaclasses/descriptors for dynamically building new Python classes/objects.
* Perl comes with OO lego blocks from which you build you own OO system.
* Class::MOP is a metacircular MOP mainly written in Perl using these lego blocks (it's turtles all the way down).
* A MOP (like Class::MOP) provide an API for building & managing extendable OO systems.
* Moose is an advanced OO system built on Class::MOP.
* Moose provides features like Roles, Method Modifiers, lazy attributes and many more.
There have been two attempts, that I know of, to bring (a subset of) Moose to Python:
> Don't languages with native MOPs, such as Python and Ruby, create better internal DSLs than Perl?
Why would you say that?
It seems to me that a DSL's function is at least reasonably decoupled from the method it uses behind the scenes, and that there is no real difference between a native MOP (like that in CLOS -- I don't really see an equivalent in Python or Ruby) and a non-native one like Class::MOP in Perl in this regard.
It helps you strip out code that isn't related to the DSL. For example, the mechanisms of class definitions in things like MongoEngine or Django's ORM. You end up with something that looks a lot more declarative.
the additional context involved with knowing Perl isn't enough IMHO to learn Perl just to parse text. I would do that with a 'more popular' language and its regex library, especially for new users.
Careful though. There's a lot of parsing that folks want to use regexps for that don't do that well.
Why Perl really shines for text file parsing is that you have a fairly large set of tools as appropriate, which fall into largely three categories:
1. regexps (great for some things, lousy for others. DO NOT use these for parsing HTML)
2. Recursive descent parsers. You could write an HTML parser in one of these if you need to.
3. Dedicated format parsers (CSV, XML, JSON, etc).
It's the combination of the three that makes Perl a very good tool for parsing text files. One thing going for Perl is a strong community of people who can help point people to the right tool for the right job.
For example, I am in the process of writing a library to do PostgreSQL tuple parsing and serialization. It is sort of like Text::CSV with some differences. In this case, regexps are the right tool. But if I was writing something else, I would probably go with recursive descent.
Anyway, Perl referencing an deferencing syntax is a mess. I regret any time I start a new program on it, as it always lead to a long debugging session where I remove all the parse errors. I use no other language with a syntax as complex (and can't really remember of any).
Hmmm. so it always takes you a long time to debug a language that you clearly don't actually know?
What a terrible language!
I don't know Python very well. I've worked on some python code but every time I do I have go read the manual for the most basic stuff (what does an "if" statement look like in Python, again?). But I wouldn't ever dare to blame Python for the fact that I don't actually know it!
> Anyway, Perl referencing an deferencing syntax is a mess.
It's not too bad. It is amusing however to see someone with twelve years of experience doing something like: somefunc(\%$someobject); Um, wtf?
I personally found the reference/dereference syntax close enough to C's I had no trouble with it but far enough away I didn't get references and pointers confused.
At the moment I'm playing with some threaded perl to parse very large text files - part of the code was developed by a C++/Java/js fan, who just realized it was the best tool for the job, and created that after a few days of playing with perl.