I'd say it was pretty influential for Ruby, CGI-BIN, pcre, and other things that will live on in more refined forms. PHP has some obvious Perl influence as well.
Edit: Maybe also Perl's Configure (crazy wide cross-platform portability) and CPAN. They were pretty ahead of their time.
While I agree that Perl influenced Ruby which I guess in turn influenced CoffeeScript and Elixir to some degree, the lineage of PHP seems to be dead. I don't really know any languages that are inspired by PHP itself, other than maybe Hack which one could argue is very closely related to PHP.
I still write and actually still (sorta-kinda) like PHP, but there's no major concept/feature I can think of that's intrinsic to PHP rather than inherited from other languages. The Perl (and general "C-like language" influence is notable, and as PHP has matured it's started to feel ever more like Java. ("To write a simple PHP server app, first just initialize your PSR-11 compatible dependency injection container and add your PSR-7 compatible HTTP request/response handlers to it...")
React(Js framework) is close to PHP as a concept. Facebook's team had to take ideas from their exisitng code. With JSX, we could potentially call it a new language.
CPAN is probably the biggest influence, it is the ancestor of most package managers used today. But Perl has also spread its dialect of regular expression and the idea of regular expression literals, plus it was hugely influential on Ruby which then have lived on in Elixir and Crystal.
Also you may be correct about it kicking off the scripting languages' popularity, and as someone else mentioned it is also responsible for cgibin.
Perl incorporated regular expressions into a general purpose programming language in a way that seemed fairly unique at the time. Today they seem to be everywhere, often with the help of PCRE-Perl compatible regexps.
The problem with perl and this kind of list is that in reality it's just an elegant way of writing awk/sh scripts with proper flow control, i.e. like python today it was seen as an way to get around the compatibility and performance issues associated with shell/awk in the bad old days of commercial Unix.
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.
In my mind what Perl brought to awk/sh was not flow control but rather data structures that did not make you want to kill yourself. Its standard library also delivered a lot of core sysadmin functionality back in the day and the reporting/output features fit very well with what was needed for early web CGI scripting.
Yeah, the idea that programming languages should be more like human languages seemed promising at the time. Perl showed us that we definitely does not want that.
Not sure I understand that one. I know Larry Wall is a linguist. But there's not much about Perl, to me, that seems like a human language.
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.
That is one of the things that are so brilliant about Perl. Tell a developer to create a programming language inspired by natural languages and you'll get verbose crap like COBOL which superficially looks "natural" but is very far from how languages work.
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!
FWIW, one of the reasons Perl 6 (now Raku) was started, was to fix the errors made in Perl, to be able to get an even more natural language. Even for difficult things:
react {
whenever signal(SIGINT) {
say "Aborted";
done;
}
whenever Promise.in(3) {
say "Timed Out"
done;
}
}
say "Goodbye";
This little program will wait for you to press Control-C or 3 seconds, whichever comes first. And say "Goodbye" on the way out.
Yeah, Wall knew what he was doing. He didn't try to make it look like a human language, he tried to make it work more like a human language.
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.
> That is one of the things that are so brilliant about Perl.
> - 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
or
x = 1 if something
which I find super cumbersome to parse. In all cases, I have to keep the whole phrase in mind before I can understand it, because I don't know which way the phrase will go. If there was only pre-conditionals, or only post-conditionals, then I would know how to parse each part of the phrase before I have read the entire phrase, which makes it easier to parse complex phrases.
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?
Reading code is more important than writing it, but I'm not convinced that two ways to phrase the same conditional assignment is a bad thing. Or, rather, it might not be a bad thing that there are two ways to phrase the same conditional assignment.
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 remove all of the non-letter characters, you are left with very understandable english sentences.
if you are hungry make a sandwich
make a sandwich if you are hungry
So unless english is a second language to you, it should be fairly easy to understand.
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)
}
Though I might consider using `when` instead.
sub factorial ( UInt $_ ){
return 1 when 0;
return 1 when 1;
return $_ * factorial($_ - 1)
}
Of course a junction would be useful
sub factorial ( UInt $_ ){
return 1 when 0|1;
return $_ * factorial($_ - 1)
}
You are probably having fits with that to.
The thing is, that also reads fairly well in english.
return one when [it is] zero or one
Often times in informal english the “it is” in such a sentence is left off for brevity. So I left it off, because we are obviously talking about “it" (`$_`). I mean, what else could we be talking about? I could easily see this being said as a response to another person.
> Alice: What result should we give the user?
>
> Bob: Return one when zero or one.
> Otherwise multiply it by …
You are probably thinking that communicating with a computer should be more formal. You should also be wearing nicely ironed clothes with a jacket and tie.
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;
The result on the left is very simple. Not only is it simple, it is the same for both lines.
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.
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.
When I started to learn other languages after learning bash then Perl first, I was really dismayed at how clumsy it was to build up a data structure of any complexity. So verbose in the Java/C++/C# land.
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.
Could partially be the TIMTOWTDI thing. People mixing:
$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.
Plus many years of Bash script intended one-liners to replace or augment awk/sed leading a lot of Perl Golfers to a sublanguage that makes APL look far saner in comparison. That the code golf then shows up in "production scripts" and libraries (if for no other reason than muscle memory) builds a fortress wall to readability by outsiders.
I think it would be fair to give Perl that credit. When it was first released, there really wasn't anything else like it. There was sh/csh, awk, sed, but nothing that really showed the path forward as Perl did.
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. :-)
But if Perl can be credited with kick starting the dynamic language boom (Python, Ruby) then it have been massively influential.