The issue was that none of the trio of shell scripts/awk/sed could stand alone, so the "language" by necessity consisted of all three tools. You'd write the main loop in shell and use awk and sed when required.

Remember, this was 1987—25 years ago, before bash and other modern shells, and with much more primitive versions of awk and sed. Nor was the web available to look things up.

Writing shell/awk/sed scripts back then was awful, no matter how much the Bell Labs folks touted its superiority.

When perl showed up on comp.sources.unix it was an incredible breath of fresh air. I downloaded and built perl based on its claim to replace shell script/awk/sed programming and Larry Wall's reputation as the author of rn [1], my preferred newsreader for usenet. Perl lived up to its billing and was an enormous improvement for writing scripts.

[1] http://en.wikipedia.org/wiki/Rn_%28newsreader%29

I'm not terribly familiar with awk, but it seems very useful. My understanding is that it lacks a lot of the features that people expect from a modern, general-purpose programming language (not that it can't be or hasn't been done--but you're probably not going to be writing a web server in awk for example), but also that awk has been improved significantly since the mid 80s when Larry Wall decided to create perl as basically "a better awk." But awk is definitely very good in its niche, which is processing text data.

I expect he means that awk may seem more like a DSL than a full-fledged language, even though/if it's possible to use it like a programming language. (Another example may be that it wasn't really intended to be a general-purpose language, IIRC that chapter in Masterminds of Programming.)

I don't know that anyone necessarily believes you couldn't program with awk in an absolute sense, but it doesn't read like a glorified shell script in the way that perl is explicitly designed to.