Hacker News Reader

Comment by bloak | Hacker News Reader

What's the alternative to Perl for the sort of file conversion and text processing that can be done with a Perl script of about a hundred characters that I can type in and edit on the command line? Or if I want a 100-line script that will work in 2029 the same as it works today and won't require any stuff to be installed first?

I don't like Perl, but since it's there, it works, it runs quite fast and I'm familiar with it, I'll probably continue using it for my own stuff for as long as I continue to use a computer, which is likely to be at least a couple of decades beyond 2023.

View on HN

For one-liners, awk. For anything more complicated, I'm faster writing a 30-line Python script than a 5-line Perl script - and everyone involved, myself included, is happier six months later when we need to edit it.

For one-liners, I considered switching from Perl to AWK, but gave up because AWK behaves differently on BSD and Linux.

Btw: The book "Perl One-Liners" from No Starch is not bad for people who want to learn a bit of Perl to become "dangerous".

An expert Perl user will always be able to show some nifty program that could never be replicated in another language, or would be ten times larger and full of bugs if it were. If you play to its strengths, it is amazing. There is no better language for ingesting text in ad hoc formats and generating formatted reports. Hence the name.

It’s quite a bold claim, do you have an example?

Nothing specific to which I can point but I’ve never seen a language with quite the utility of Perl’s format feature.

https://perldoc.perl.org/perlform.html

I love string encoded logic. Not joking.

The Practical Extraction and Reporting Language thing is not Perl's name, it's just a backronym that Larry Wall came up with. My personal favorite backronym is Pathologically Eclectic Rubbish Lister (I say this as someone who really loves Perl).

From `perldoc perl`:

"""Perl officially stands for Practical Extraction and Report Language, except when it doesn't."""

It seems like you are arguing that because it is in the official docs, that is where the name 'Perl' came from, but that is not accurate.

autarch is right, "Practical Extraction and Report Language" is a backronym --the language was named 'Perl' first, and that acronym (and others) were devised later ( see https://en.wikipedia.org/wiki/Perl#Name ).

Larry was originally going to include the 'a' and name the language 'Pearl'. However, at the time there was already a programming language named 'Pearl', so he changed the name to Perl ( again, see https://en.wikipedia.org/wiki/Perl#Name ).

This can be verified from multiple sources, including the "Learning Perl" book ( see https://en.wikipedia.org/wiki/Perl#cite_note-57 ).

It can be a backronym and the official name at the same time. Your assertions are all true but your logic is faulty.

Sorry, just got back to this.

I guess that depends on whether you consider an obviously tongue-in-cheek backronym to be "the official name". We obviously disagree on this point.

There is the one liner bash syntax for Ruby:

The -n option processes lines, the $_ magic variable yields from STDIN:

    echo "Foo\nBar\nBaz" | ruby -ne 'puts $_.downcase!'

outputs "foo\nbar\nbaz"

The -p option processes lines and prints the output:

    echo "My String" | ruby -pe '$_.downcase'

outputs "my string"

Just using -e allows you to pull all of STDIN with gets:

    echo "My String" | ruby -e "puts gets.downcase"

is functionally equivalent to the last.

More references: https://www.notch8.com/bash-commands-ruby/

The use case you describe is a use case of diminishing value in an era of better IDEs and tools. Definitely a thing people can still want to do, but your average new hacker is likely going to lean towards a tool with fewer sharp edges so that they can be confident the file conversion came through correctly.

The question is whether future generations will be as familiar with it as we are.

Maybe awk for text manipulation?

Literally the reason AWK was created

AWK has been and will forever been under appreciated. It is a fantastic tool. I always preferred it to Perl myself.

I use it multiple times a week for printing/copying tabular data from space-delimited files. It's not the most arcane usage but it would probably take several lines to do what awk does in one. I don't even know much awk! Learning any bit of awk is worth every moment of the investment.

    cat somefile.txt | awk '{ print $1 "\t" $2 }'

On mac I pipe to `pbcopy`. Saves me several minutes each time.

I don't use it quite that frequently but awk/sed is a strong addition to the toolbox.

Bash is actually pretty decent at this by itself if you don't have a lot of extra columns:

    cat somefile.txt | while IFS=" " read one two; do echo -e "$one\t$two"; done

IME the pattern matching is where awk really shines.

I do have a ton of extra columns I'm filtering out but that's really good. I'll try it on. Thanks!

Also see basic Unix utilities like cut / paste (and colrm if your *nix has it, not sure if MacOS does) as these do the same column selection and printing and support simple options for delimiter and field number selection instead of writing a parser.

cut -d’ ‘ -f 1,2 < some file.txt

Having extensively used AWK and PERL, I don’t agree. AWK works for simple things, but has significant limitations especially for more complex parsing you might do in a dozen lines of PERL. Subroutines don’t return complex structures, Strict mode declaration checking, hashes, foreach style iterators are much less functional or missing in AWK. Multi layer structures are also trivial in PERL (hash table or array composed of child hash or array). Finally, AWK versus GAWK versus NAWK compatibility is an issue.

I always thought that the original idea of Perl was slapping sh, sed and awk together into one language.

The problem of course, is that you have to be familiar with it. If you're facing this problem and don't already know Perl, you'll just use whatever your regular scripting language of choice already is.

Perl may be efficient at some tasks, but having to learn it to take advantage of that efficiency is basically never going to pay off.

Or put another way: https://xkcd.com/1205/ and https://xkcd.com/1319/

>The problem of course, is that you have to be familiar with it.

This is generally what formal education is supposed to solve.

If we're going to go with xkcd, the "death date" reminds me a bit of https://www.xkcd.com/605/

Obviously just use J.

Better yet, K - it's even more cryptical than Perl :)

Reply on news.ycombinator.com