Live data from Hacker News

Perl first commit: a “replacement” for Awk and sed

github.com

161–170 of 261 posts

Re: Perl first commit: a “replacement” for Awk and sed

#161
post #122

Earlier quoted context omitted.

> And you needed it in your head, because finding the information you needed in the massive single document man file reference was a pain That's what the O'Reilly books were for, especially the Nutshell series.

I remember capturing every password at my university via "methods". Because we had a printer quota. In the summer when everyone was gone I printed out all the man pages (all the mans, the system libraries, etc) so I'd have a nice reference book. I made sure to make it so no one was charged any money. The one thing people can't possibly fathom if they started coding after the mid-late 90s was how much we relied on the…

I still remember when we measured the documentation IBM shipped with the mainframes not in pages but in yards it occupied on the shelves. It was a lot.

Re: Perl first commit: a “replacement” for Awk and sed

#162

Earlier quoted context omitted.

Honest question-- why weren't the tools glued together or perhaps replaced entirely with the lisp inside Emacs? What was it missing?

Memory and CPU efficiency, since most systems were memory constrained. My first server had 128MB of RAM...

> My first server had 128MB of RAM

Whippersnappers! :D

The first big iron I had the luck to work with was an IBM 3090 , essentially a gift from IBM, it handled the university entrance exams of the entire country of some ten million people and it had 64 MB of RAM. (It was also the first computer in Hungary permanently connected to the Internet via a leased line to Austria so it had an Austrian IP address. Hungary didn't have its IP region for two more years.)

I think the first machine with 128MB was a VAX 6510 a year or two later at another university. A little bit later, in 1994, CERN had gifted a VAX 9000 with an astounding 256MB of RAM.

To compare, the first server I installed Linux on had a grand total of 4MB RAM -- and that was one of the largest computers a small department at the university had.

It would be a long, long time before "128MB" and "mine" entered the same sentence.

Re: Perl first commit: a “replacement” for Awk and sed

#164
post #86

Earlier quoted context omitted.

I think we are actually mostly in agreement there then. Perl was invented because the gap from shell to more capable languages was (and is) really big. Languages like Python and Ruby didn’t exist yet, and Perl had a really, really strong sweet spot in text processing.

> Perl had a really, really strong sweet spot in text processing. Still does.

Since Ruby took the best bits of Perl what advantage does Perl retain?

Re: Perl first commit: a “replacement” for Awk and sed

#165
post #42

Earlier quoted context omitted.

> Automation was glued together in one of these with a series of grep, awk, sed, ls, test, commands glued together. Anything more complicated was written in C and called from one of these things. This doesn't sound that horrific to me. It's the classic Unix approach of building small tools that do one thing well, and composing them in novel ways to solve problems. For any problem that can't be solved this way you wri…

I don’t think you’ve seen the kind of scripts the person you are responding to is talking about. I have, and mentioned one lower down in the comments. Unix philosophy was great but does not scale well in terms of maintainability or efficiency. Invoking processes over and over again loops is godawful slow. And the horror of complicated shell scripts is legendary.

As a self-taught coder, I've experienced many times how highly skilled software engineers groan and sweat when they encounter shell scripts. I don't understand why, but it seems like people with a CS background are never really taught shell scripts and have come to irrationally fear them. It's sort of taboo.

This results in weird behavior, such as writing a groovy (Java?) script for Jenkins to execute bazel in order to build a go binary that runs the very same commands in an exec.Command() construct. Or people who download and import pandas to grab the third field in a csv file.

During the course of learning, I've naturally written code in bash that should have been written in another language. I replaced if statements with case because they turned out to be more performant. It's a great learning experience and why I got into python and go.

IMO we should use the right tool for the job. Sometimes that tool is a combination of unix utilities that you can put in a shell script for easier maintenance. It's just procedural execution of (usually very efficient) binaries, akin to a jenkins script or gitlab pipeline. Just mind the exceptions and use exit codes.

Re: Perl first commit: a “replacement” for Awk and sed

#166
post #42

Earlier quoted context omitted.

> Automation was glued together in one of these with a series of grep, awk, sed, ls, test, commands glued together. Anything more complicated was written in C and called from one of these things. This doesn't sound that horrific to me. It's the classic Unix approach of building small tools that do one thing well, and composing them in novel ways to solve problems. For any problem that can't be solved this way you wri…

I don’t think you’ve seen the kind of scripts the person you are responding to is talking about. I have, and mentioned one lower down in the comments. Unix philosophy was great but does not scale well in terms of maintainability or efficiency. Invoking processes over and over again loops is godawful slow. And the horror of complicated shell scripts is legendary.

Yeah, the actual experience of leaky abstractions and non-portable code is forgotten. Perl solved a very real problem in the 90s. Grief, I shudder to think back to the sheer complexity of my bashrc file back then.

Re: Perl first commit: a “replacement” for Awk and sed

#167
post #153
post #75

Earlier quoted context omitted.

I'm not saying that Perl didn't have its time and place. It certainly fulfilled a need at the time for a language more capable than shell scripts, but less cumbersome than C/C++. But the thing is that today the shell landscape is much more mature for solving simple problems, and we have C/C++ alternatives that are saner and more capable than Perl (e.g. Go). So it arguably has lost its place, as shell tools are still…

Python killed the game.

Unfortunately. Ruby should have been Perl's natural successor. Python is the VHS of scripting languages. For a start it doesn't have a decent answer to Perl or Ruby's one-liners. Then there's the crippled lambda implementation. Python is a sad case of worse is better.

Re: Perl first commit: a “replacement” for Awk and sed

#168

I used to kind of unfairly disparage perl, but now I regret never learning it. I've written a lot of scripts for munging text/files that outgrow bash, and when I rewrite in Python they get twice as long. Seems like perl would be a happy medium and let me keep using a lot of the nice bash shortcuts like `baskticks` for shell execution, etc

> I used to kind of unfairly disparage perl

It was fashionable in programming discourse for people to parade their skillful opinions about things they never really understood. And it still is. ^_^

Even today in 2023, some people continue to disparage bash, awk, sed, grep, and Perl as though these tools form a common nightmare for all humanity. But these are very successful tools that solve problems quickly, efficiently in memory, and across many hardware platforms.

People are free to dislike the notation and to prefer Python or Haskell or Powershell. But some detractors simply behave in a bigoted way towards languages that they have little desire to learn. And as far as their objections to the notation are concerned, the same expressive problems find similar notational solutions in Powershell and the various DSLs that Python includes (e.g. numpy, pandas).

Bash, awk, sed, grep, and Perl are robust, durable, portable tools. Their developers were/are smart people. I've found that knowing these tools well has been important in my career. And I also code in Python.

Re: Perl first commit: a “replacement” for Awk and sed

#169

Earlier quoted context omitted.

Awk today is very much the same language it was in 1977 when it was introduced. Comparing your links with today's POSIX awk manpage doesn't yield a single thing Perl brought to awk. At best, while JavaScript syntax is even based on awk, you could say JavaScript regexpes are based on PCRE, and it wasn't clear whether use of capture groups/back references makes Perl regexpes accidentally Turing.

POSIX, right. POSIX sucks. POSIX anything is stuck 30 years ago. Nobody in 2023 really uses POSIX awk on some commercial UNIX like IBM AIX, they use GNU awk, that's the modern one I'm talking about https://www.gnu.org/software/gawk/manual/html_node/index.htm...

Well, I look at the POSIX standards whenever I want to write shell scripts and Makefiles that work on both Linux and macOS. Which, in my current role, is often enough that I am driven crazy by how far POSIX is behind GNU tooling...

Re: Perl first commit: a “replacement” for Awk and sed

#170

When perl came out we were living in horrific times. You had the choice of either Bourne, C or Korn shell. Automation was glued together in one of these with a series of grep, awk, sed, ls, test, commands glued together. Anything more complicated was written in C and called from one of these things. Perl in one stroke collapsed the programming of C, text manipulation, the capabilities of all of the Unix utilities, an…

> Yes, awk and sed were replaced by Perl, but more importantly, the unmaintainable nightmare that glued all of it together was wiped out. Er, Perl replaced an unmaintainable nightmare? Perl, the language infamous for being indistinguishable from line noise?

Yep, that’s how bad it was before.
Post reply on HN