And unfortunately, the brilliant minds that worked on Perl 6 spent so much time rewriting the compiler tool chain and basically treating just that part as a research project, that it was incredibly difficult to actually contribute and push the project forward. Couple that with a spec that never seemed finished and a community that tore itself apart because of assholes, and it was a perfect storm to remove Perl from prominence.
But if Perl can be credited with kick starting the dynamic language boom (Python, Ruby) then it have been massively influential.
Edit: Maybe also Perl's Configure (crazy wide cross-platform portability) and CPAN. They were pretty ahead of their time.
Smarty could possibly take credit for inspiring some of the template engines out there also.
Also you may be correct about it kicking off the scripting languages' popularity, and as someone else mentioned it is also responsible for cgibin.
It might sound strange to modern eyes but there was an time when Perl was considered elegant and robust, but then again very few young people have ever experienced the horrors of trying to write portable shell code for commercial Unix, perl was on the other hand almost completely identical regardless of what variant of Unix you happened to be running, and vastly faster then sh/awk at a time when even expensive systems could be slow by modern standards.
For modern day script writers Ruby and Python have all but replaced perl even though that's not stopping the enterprise from keeping their perl codebases alive and kicking for the foreseeable future, but even there it's being challenged from bellow by the fact that bash and gawk have become fairly universal on Linux systems and hardware fast enough that regex performance rarely matter.
A lot of subsequent languages have focused on readability, partly as a reaction to some of the....unique things came up with in Perl.
If I dig into the gripes about the syntax, it's usually use of the implied $_ variable, wide use of sigils ($, @, %), derefs of complex data structures (hash of lists of hashes, etc) or regex syntax that people are talking about.
Perl, on the other hand, looks just like a programming language would if it was the only way we could talk to computers, day in, day out:
- Implicit "it" variable,
- Very brief syntax for common operations,
- More than one way to say things,
- Context determines the meaning of things, and so on.
It's not at all what one instinctively thinks of as "a programming language drawing from natural languages", but on closer inspection (and daily use) that's exactly what such a thing would look like!
react {
whenever signal(SIGINT) {
say "Aborted";
done;
}
whenever Promise.in(3) {
say "Timed Out"
done;
}
}
say "Goodbye";
Another significant experiment in Perl was embracing the idea that everybody write in their own personal dialect or subset of the language. Again, the conclusion seem to be that this is a really bad idea since someone else will have to maintain the code eventually. But nevertheless it is valuable that the experiment have been tried. Python took some important lessons from that.
> - More than one way to say things
I respect that others may disagree, but I actually find this to be a major disadvantage in a programming language. From a readability perspective[1], having more than one way to express the same task is in my opinion a bad thing. As a trivial example, Perl supports both pre- and post-conditionals:
if something then x = 1
x = 1 if something
I think this is one major reason languages like Perl or C++ are often considered hard to read. Having so many ways to express the same thing means a major mental load until you've figured out what is trying to be expressed.
[1] By now we've all come to agree that easy reading of code is far more important than easy writing of code, right?
See what I did there? Same meaning, different order of clauses. Emphasis ended up on different parts of the sentence! This is a very powerful out-of-band signaling path to control how the reader interprets the literal words, and being used to Perl where we also have it, it is weird to not have it in other languages.
Sometimes the actual predicate is the important/interesting bit, in which case putting it first makes sense: `if (user_is_underaged) return;`. Sometimes the predicate is not as interesting as the expression it's conditioning: `say "message" if debug_mode;`.
if $you-are-hungry { make-a-sandwich() }
make-a-sandwich() if $you-are-hungry;
if you are hungry make a sandwich
make a sandwich if you are hungry
If you pay attention to how people use those different forms in english, you will also notice that the infix form of “if” tends to be used for simple short sentences. Which is exactly how I use it in Perl and Raku.
sub factorial ( UInt $n ){
return 1 if $n == 0;
return 1 if $n == 1;
return $n * factorial($n - 1)
}
sub factorial ( UInt $_ ){
return 1 when 0;
return 1 when 1;
return $_ * factorial($_ - 1)
}
sub factorial ( UInt $_ ){
return 1 when 0|1;
return $_ * factorial($_ - 1)
}
The thing is, that also reads fairly well in english.
return one when [it is] zero or one
> Alice: What result should we give the user?
>
> Bob: Return one when zero or one.
> Otherwise multiply it by …
The problem with that is that you aren't communicating with a computer. You are communicating with everyone that is going to read your code. Reading a technical manual can be very tiring for even the most stoic of readers.
I prefer to read a well written novel. Good Perl and Raku code often reads more like a novel than a technical manual. Even when it is kept very precise about its semantics.
Which means that when I am done doing something in Perl or Raku, I want to continue doing more of that. I don't want to stop.
Sometimes I will find myself re-reading the same line repeatedly at 3am.
---
Further, note how I used the infix form of “if”.
return 1 if $n == 0;
return 1 if $n == 1;
It is very common to use it in this manner. Where they sit at the very beginning of a function as a kind of guard clause. The real important bit is the right part of the lines. Which actually stands out more than the left half, because it is closer to the center of the screen.
After those two lines, we know two things about `$_`. It is neither a `0` or a `1`, because we already dealt with both cases. So we don't have to worry about them in the rest of the function.
For the most part, when I see a line like that I know that I can safely skip over it. That is because it is almost only ever used for that type of thing. As a way to deal with simple cases early in the lifetime of a function. It also means that I can very quickly glean the information I need for that very same reason.
---
People tend to have a lot of bad things to say about Perl and Raku.
Almost everyone who has used them enough to get comfortable with either of the two languages would say just about the opposite to most of those things.
Basically, it's bad in theory, but it's good in practice.
Reminds me of a video “Clay Shirky on Love, Internet Style” https://www.youtube.com/watch?v=Xe1TZaElTAs (9m14s long)
Particularly this line:
> And it was at that moment that I understood what was going on. Because they didn't care.
> They didn't care that they had seen it work in practice, because they already knew it couldn't work in theory.
---
I very much agree that it is far more important to be easy to read. Which is why I find Perl and Raku to be awesome.
I can write things in the most readable way for a person as possible, rather than the only way the compiler can understand.
Am I the only one who finds perl data structures simple and consistent? Once I understood the difference between () and [] (or {} for hashes), it was easy (too easy, some might say!) to construct complex data structures.
Having those constructs so effortlessly available with a minimal amount of syntax spoiled me. To this day, I would likely still prefer to do any kind of complicated ETL involving deeply nested structures with Perl.
$foo->{bar};
$$foo{bar};
And quoting or not the key, etc. Slices and individual elements, etc. Probably looks like line noise to outsiders when you have a long one using parens to grab a specific array element, combined with $$ and so forth.
Raku (formerly known as "Perl 6"), PHP, Ruby and PowerShell were directly influenced by Perl.
That said, once Python 1.5.2 (or so) hit, Perl was done for. It was simply better, and there was no reasonable way for Perl to recover the lead, or even really coexist. Perl had a lot of momentum and took many years to decline, but that was the tipping point, in my mind.
It remains to be seen whether Python3 will displace Python2. :-)
Sure the percentage has gone down, but the count has gone up.
Anyway...
Somewhat deserved, surely?
Perl is like the Continuum transfunctioner, "Its power is exceeded only by its mystery." ;-)
Much of our "duct tape" is unmaintainable code with undocumented aracne regexes everywhere, single-letter variables, and 1990s-era flow control. Nothing you'd find in Modern Perl is in our duct tape. Ultimately, the fastest turnaround on "we need feature X added to Perl script Y" is going to be "rewrite Y in Python, add feature X" because actually extending the Perl code has proven to be a nightmare.
(and as a side note, most of these Perl scripts ran out of cron on various boxen scattered across our network, and as I've been rewriting them I've also been removing them from cron and putting them in our centralized setup that uses Jenkins to run scripts, pulled out of git, inside Docker images on a schedule)