News for hackers. Stuff that matters.
Re:The Awk Programming Language (1988) [pdf] by kqr on Thursday May 24, 2018 @12:25AM (#17141085)
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.
Re:The Awk Programming Language (1988) [pdf] by ajross on Thursday May 24, 2018 @12:55AM (#17141197)
To be clear: I like that about it too. But in the real world, we want tooling that does more stuff. In the mid-90's, "everyone" knew perl, because it was the best choice for problems in this space. And in a world where everyone knows perl, there is no place for 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.

Re:The Awk Programming Language (1988) [pdf] by fiddlerwoaroof on Thursday May 24, 2018 @01:01AM (#17141218)
I think people underestimate the importance of medium-powered tools. Perl is great, but awks limitations make it easier to write in a way that the next person can maintain.
Re:The Awk Programming Language (1988) [pdf] by fiddlerwoaroof on Thursday May 24, 2018 @01:03AM (#17141223)
That being said, the couple times I’ve paired with a perl wizard were revelatory.
Re:The Awk Programming Language (1988) [pdf] by zmodem on Thursday May 24, 2018 @02:54AM (#17141627)
Or just reading about perl wizardry: https://www.hanshq.net/perl-oneliners.html
Re:The Awk Programming Language (1988) [pdf] by xyrouter on Thursday May 24, 2018 @02:07AM (#17141466)
Can you elaborate this? What revelations did you experience?
Re:The Awk Programming Language (1988) [pdf] by ams6110 on Thursday May 24, 2018 @09:08AM (#17143575)
> in a world where everyone knows perl, there is no place for awk.

And yet in 2018, I never think about Perl anymore, but use sed, awk, and grep daily.

Re:The Awk Programming Language (1988) [pdf] by mbubb on Friday May 25, 2018 @04:01PM (#17157358)
This is a great point
Re:The Awk Programming Language (1988) [pdf] by kamaal on Thursday May 24, 2018 @04:03AM (#17142005)
>>And that makes awk look clever and elegant.

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.

Re:The Awk Programming Language (1988) [pdf] by oblio on Thursday May 24, 2018 @04:31AM (#17142152)
Most modern distributions write their tools in Python instead of Perl. Proof: the really long transition process Fedora (and therefore RHEL), Debian and Ubuntu went through to migrate from Python 2 to 3. They could have done it faster if not for their system tools written in Python 2.

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.

Re:The Awk Programming Language (1988) [pdf] by kqr on Thursday May 24, 2018 @03:16AM (#17141742)
I totally see your point. And in Perl-world, I would probably use Perl too – I mean, if both tools are equally ubiquitous, why not use the most powerful one?

I entered the field at the tail end of the Perl era, so I've only toyed with it a long time ago.

Re:The Awk Programming Language (1988) [pdf] by mozumder on Thursday May 24, 2018 @04:39AM (#17142192)
I hated perl in the mid-90's, and stuck with grep/awk/sed intead, because it was a little more documented-structured.

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.

Re:The Awk Programming Language (1988) [pdf] by singingfish on Friday May 25, 2018 @06:05PM (#17158405)
I’m sick of the “perl is line noise” narrative. https://pastebin.com/C9hPS8xR
Re:The Awk Programming Language (1988) [pdf] by dannas on Thursday May 24, 2018 @01:58AM (#17141441)
Here's a picture of the AWK book next to the Camel book https://twitter.com/heinrichhartman/status/77170643345276928...

"#awk doc shows you how to implement a rel-DB and a compiler. #perl doc talks 20p+ about nested data structures."

Re:The Awk Programming Language (1988) [pdf] by FractalLP on Thursday May 24, 2018 @06:55AM (#17142796)
That is one thing I like better in Python than in Perl. In Perl, I was having difficulty with nested data structures and then realized this was something I did in Python daily without even knowing it was a thing on a conscious level. Who hasn't made some weird dictionary with its values being lists or tuples or something like that?
Re:The Awk Programming Language (1988) [pdf] by ajross on Thursday May 24, 2018 @09:02AM (#17143523)
This is exactly backwards to my eyes. Perl's autovivification behavior (assigning through a empty reference to something autocreates the object of the right type) makes nested data much, much cleaner.

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.

Re:The Awk Programming Language (1988) [pdf] by kqr on Thursday May 24, 2018 @04:19PM (#17147982)
Defaultdicts to the rescue! But I think it should be an explicit choice. If you only intend to have lists at some keys, and then accidentally mistype a key, it shouldn't (in my opinion) silently create a list, effectively hiding the bug.
Re:The Awk Programming Language (1988) [pdf] by FractalLP on Thursday May 24, 2018 @04:00PM (#17147740)
Sorry, but I didn't catch your example. Can you explain a little more? What does Perl do better there?
Re:The Awk Programming Language (1988) [pdf] by kamaal on Thursday May 24, 2018 @03:56AM (#17141967)
Most of awk's 'advanced and hard to do' use cases in Perl go like

    open (my $FILEHANDLE, '<', $file) or 
        die "Cannot open $file\n";
    while(<FILEHANDLE>) {
        chomp;
        #Do you stuff here
    }
    close(FILEHANDLE);
Also perl can do various other things awk just can't. For example removing something from a file and then talking to a database or a web service, or do other stuff like parse a JSON or XML. Deal with multiple files, or other advanced use cases. Unicode work, advanced regexes etc etc.

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.

Re:The Awk Programming Language (1988) [pdf] by greenleafjacob on Thursday May 24, 2018 @04:23AM (#17142109)
In fact the boilerplate you describe is mostly redundant if you use perl -p since perl -p results in your program running with this wrapper:

    LINE:
    while (<>) {
	...		# your program goes here
    } continue {
	print or die "-p destination: $!\n";
    }
Re:The Awk Programming Language (1988) [pdf] by flukus on Thursday May 24, 2018 @08:45PM (#17149773)
Correct me if I'm wrong, but this will only be line based won't it? As far as I can tell there is no equivalent of FS/RS/OFS/ORS that make awk the record (not line) based language it is.
Re:The Awk Programming Language (1988) [pdf] by Annatar on Thursday May 24, 2018 @06:45AM (#17142740)
For example removing something from a file and then talking to a database or a web service,

...

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.

Re:The Awk Programming Language (1988) [pdf] by kamaal on Thursday May 24, 2018 @09:02AM (#17143519)
It goes further. Awk is when you entire use case fits into the category of iterating lines in a file.

Perl is that plus more things.

Re:The Awk Programming Language (1988) [pdf] by Annatar on Thursday May 24, 2018 @09:37AM (#17143812)
Perl simply isn’t worth it. In all the decades of programming, I’ve yet to run into a problem which could only be solved in Perl because it couldn’t be done in AWK.

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.

Re:The Awk Programming Language (1988) [pdf] by textmode on Thursday May 24, 2018 @11:44AM (#17145109)
"In all the decades of programming, I've yet to run into a problem which could only be solved in Perl because it couldn't be done in AWK."

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.

Re:The Awk Programming Language (1988) [pdf] by Annatar on Thursday May 24, 2018 @12:02PM (#17145291)
The illumos project undertook a massive effort to eradicate any and all dependencies on Perl (which had also been made part of the core operating system decades prior, by themselves no less). While they're still at it, they have managed to rip out most of it and replace it with binary executables in C or shell.

Yes, writing a build engine in AWK would be perfectly doable, but the right tool for that job is Make.

Re:The Awk Programming Language (1988) [pdf] by kamaal on Monday May 28, 2018 @02:29AM (#17170875)
That's easy to do.

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.

Re:The Awk Programming Language (1988) [pdf] by Annatar on Tuesday May 29, 2018 @05:54AM (#17177772)
I’m sorry you believe that, but it’s simply not true, especially since UNIX is designed to be driven by a combination of binary code and shell executables. Perl is a mess whose syntax borders on hieroglyphic once poured into software. That doesn’t mean that it’s not a capable language; but it’s not a language in which written programs are maintainable or easily debuggable.
Re:The Awk Programming Language (1988) [pdf] by tannhaeuser on Thursday May 24, 2018 @01:47AM (#17141398)
That, and awk programs are almost perfectly portable across awk implementations: nawk, gawk, mawk (can't vouch for busybox-awk as I haven't tested it, though I've heard it's good as well).

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