What I like about AWK is that it is described by a few pages of the POSIX standard. If Perl was that ubiquitous and simple, I would prefer it over AWK.
But now we live in a world where no one knows perl, and languages like python and javascript are clumsy and weird in this space. And that makes awk look clever and elegant.
All I'm saying is that in perl-world (which was a real place!), awk wasn't clever and elegant, it was stale and primitive. And that to me is more surprising than awk's cleverness.
And yet in 2018, I never think about Perl anymore, but use sed, awk, and grep daily.
Eventually the cycle will repeat again. The moment you will have non trivial text work to do, awk will have to give way to Perl.
The rise of Python was really use case for dealing with standard interfaces like DBs/XMLs/JSONs becoming common. Python hasn't actually replaced Perl in any meaningful way.
In the web space, Python is not huge, but it definitely supplanted the niche Perl used to have. No one I know writes web stuff in Perl anymore.
I entered the field at the tail end of the Perl era, so I've only toyed with it a long time ago.
Meanwhile, if you randomly mashed on your keyboard, it would output a perl script.
I jumped to Python as soon as I found out about it in the late 90's, because it was exactly what I was looking for in self-documenting structuring. It was great for creating parsers with state-machines. I was also the user of my scripts, and I didn't want to have to relearn what I coded a year or so earlier. Python let me pick that up, and to a lesser extent, awk. State machine programming was really self-documenting in Python.
"#awk doc shows you how to implement a rel-DB and a compiler. #perl doc talks 20p+ about nested data structures."
Who hasn't made some weird dictionary with its values being lists and forgotten to check for and write code to create it when it doesn't exist, and had to fix that later after a runtime crash? In perl that's literally covered by the one-line assignment you used to set the field you parsed.
This is why it's sad that everyone's forgotten perl.
open (my $FILEHANDLE, '<', $file) or
die "Cannot open $file\n";
while(<FILEHANDLE>) {
chomp;
#Do you stuff here
}
close(FILEHANDLE);
In fact the whole point of Perl was Larry wall reaching the upper limits of what one could do with awk, sed and other utilities and having to use them all over the place in C. Then realizing there was a use case for a whole new language.
LINE:
while (<>) {
... # your program goes here
} continue {
print or die "-p destination: $!\n";
}...
Deal with multiple files, or other advanced use cases.
I do exactly this every day with AWK. Solving exactly these kinds of problems features prominently in the AWK programming language book.
Perl is that plus more things.
And I would hereby like to remind you that every computing problem is fundamentally an input-output problem, and because of this intrinsic property, it is possible to reduce all problems in computing to input-processing-output.
Which is exactly the kind of problem AWK is designed to address.
And AWK doesn’t work with lines, it works on records, for which the fathers of the language cleverly chose the default of ‘\n’, which is reconfigurable.
Have you ever pondered the number of projects that, in addition to sh, make and common base utilities, require perl during compilation where awk could have sufficed?
As a single example, have you looked at compiling openssl without perl, using awk instead?
Whenever I see a perl prerequisite I question whether it is truly a requirement or whether other base utilities1 such as awk could replace it.
Assuming it could be removed, how much effort is one willing to expend in order to extinguish a perl dependency?
1. Some OS projects like OpenBSD make perl a base utility.
Yes, writing a build engine in AWK would be perfectly doable, but the right tool for that job is Make.
But that's not the end of it. The whole point of Perl is avoid a salad of C and shell utils. Also in many cases the moment you have to deal with >2 files at a time shell utilities begin to show their limits.
The resulting code is often far more unreadable than anything you will ever write in Perl.
This is of practical importance for portable scripts, since Debian uses mawk [1], RH ships gawk, and Mac OS uses nawk.
[1] mawk has recently received new commits by its original author after a hiatus of 20 years or so; see https://github.com/mikebrennan000