Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

131–140 of 261 posts

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

#131

Post by akira2501 »

_2z1p wrote: post #16

Unpopular opinion, but I think we'd be so much better off if Netscape had just embedded a Perl interpreter instead of creating JavaScript. Perl CGI was already the dominant server side technology at the time and it has incredible string manipulation capabilities that would be beneficial for browser scripting.

I recall the C interface to perl being exceptionally ugly. It was not designed with embedding in mind. That was one of the things that convinced me to move to ruby.. matz had exceptional taste when it came to the C api.

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

#132

Post by akira2501 »

idlewords wrote: post #30
aportnoy wrote: post #2

The funny thing is Perl is now arguably more obsolete than sed and awk.

My livelihood depends on a large set of Perl scripts, and I bet I'm not the only one in that position. It's perfect for gluing things together and then not breaking for decades, while other languages come and go. It's kind of the new COBOL that way.

Modern day ronin right here.

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

#133

Post by imiric »

aidenn0 wrote: post #79
imiric wrote: 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…

csh was a decent interactive tool, but not great for scripting. Bourne shell had the right idea but there were so many bugs in various corners of it (I still sometimes end up writing "test "x$foo" = "xbar" even though shells that need that are long gone). If you can depend on a recent bash and use shellcheck, then it's actually quite a pleasant programming environment, with fewer footguns than one might think. (I wan…

Mostly agree. The modern shell scripting environment is much more robust than 30 years ago, with ShellCheck and some sane defaults, as you say. I also find it pleasant, once you get over some of its quirks.

As for managing libraries, that's true, but you can certainly import and reuse some common util functions.

For example, this is at the top of most of my scripts:

    set -eEuxo pipefail

    _scriptdir="$(dirname "$(readlink -f "${BASH_SOURCE[0]}")")"
    source "${_scriptdir}/lib.sh"
This loads `lib.sh` from a common directory where my shell scripts live, which has some logging and error handling functions, so it cuts down on repetition just like a programming language would.

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

#134

Post by juliusdavies »

idlewords wrote: post #30
aportnoy wrote: post #2

The funny thing is Perl is now arguably more obsolete than sed and awk.

My livelihood depends on a large set of Perl scripts, and I bet I'm not the only one in that position. It's perfect for gluing things together and then not breaking for decades, while other languages come and go. It's kind of the new COBOL that way.

Recently I wanted to see if some code I wrote still worked on Java 1.x.

The only way I could get Java 1.x to run (among my fleet of existing machines) was by installing the windows JDK version to run inside Wine on my Ubuntu.

Native Windows 10 could not run Java 1.x. This surprised me, since in my previous experience Windows was pretty amazing for maintaining reverse compatibility.

(I guess I could grab a super-old Debian docker image like Debian 6 and see if the linux Java 1.x binary would run on that, but I wanted to stick with machines I already had running.)

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

#135

Post by mulmen »

Scubabear68 wrote: post #49
imiric wrote: 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.

Programming environments including shells and operating systems are just tools. And every tool can been misused. I opened a can of beans with a screwdriver once. Reality is messy. That doesn’t make the tool bad.

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

#136

Post by mulmen »

j16sdiz wrote: post #109
imiric wrote: 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…

> 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. This works really well if your problem can be solved in one or two liners. It go bad very quickly when, say, you have two CSV files and want to join them the sql-way. In sed, you have to use positional variables and think about shell escaping. In…

> It go bad very quickly when, say, you have two CSV files and want to join them the sql-way.

Then just put them in a database and write a simple SQL query. If you use Perl it’s really very simple to do.

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

#137

Post by Cyberdog »

mulmen wrote: post #117
Cyberdog wrote: post #47

Earlier quoted context omitted.

I don't think comparing Perl to SQL quite works. There are currently plenty of other widely-used scripting languages that can do the same sort of thing that Perl does (if we consider it in the context of a general purpose scripting language rather than a sed/awk alternative), but the usage of SQL alternatives for querying relational databases is a rounding error.

It works because they both get shit on unfairly today. There’s still no substitute for either of them.

As I said above, there are dozens if not hundreds of substitutes for Perl (as a general-purpose scripting language) now.

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

#138

Post by globular-toast »

aportnoy wrote: post #2

The funny thing is Perl is now arguably more obsolete than sed and awk.

There's a difference between using something because you want to and using something because you have to. awk and sed are sometimes the right tool, just not always.

When I used sed and awk a lot I also made heavy use of bash which makes things a lot nicer. And Python, of course.

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

#139

Post by tribby »

BaseballPhysics wrote: post #107
margalabargala wrote: post #106

Earlier quoted context omitted.

Yes. It's comparative. The absolute value of Perl's readability, maintainability, and general intuitiveness is massively better than all comparable tools that existed when Perl came out. Perl is a massive improvement over those tools. If you have doubts, try writing a complicated production software stack in awk. Then hand it off to a coworker. One need not be irreplaceably good, if one is already beating the current…

Moreover, as often as people joke about the readability of Perl code, that's entirely a function of the developer. I've easily written tens of thousands of lines of Perl, and not a single person has complained about difficulty reading or maintaining that code. Why? Because I apply all the usual best practices for code hygiene that apply to any language. Frankly, I think most people are just repeating a meme they hear…

absolutely a response to perl. “TOOWTDI” has been an expression in the python community for a long time :)

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

#140

Post by cpach »

jancsika wrote: post #92
stubish wrote: post #55

Earlier quoted context omitted.

At the time, before everything became Linux, all these tools and the shells used to glue them together were an incoherent mess. Was your glue sh, ksh, csh, tcsh, bash or something uncommon like zsh? Did your grep, awk and sed use the same regexp syntax as your text editor? Single letter command line options, all meaning something different to each tool. Dozens of domain specific languages (shells, awk, sed etc.) mean…

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

Elisp is very much a niche language. For whatever reasons, the use of Elisp outside of Emacs is basically non-existent. Elisp is quite clunky, and AFAIK there hasn’t really been any big efforts to make it usable outside of Emacs. People who wanted Lisp outside of Emacs already had Common Lisp. (And Chez Scheme, and Scheme 48, etc etc.)
Post reply on HN