Live data from Hacker News

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

github.com

241–250 of 261 posts

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

#241
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.

Horror is apt.

You hit it on the head with the slowness of loops when the body comprises a series of program invocations. The horror really seeps in when you realize the original author wasn't stopped by the lack of data structures: they could get around that with some creative variable names.

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

#242

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?

Oh yeah! Perl sure did have a bunch of ugly programs, but I believe that was because it was so easy for non-experts to program in it. There have been many companies successfully built atop of a Perl code base, and I've seen fantastic systems built with it. I've also seen one-off programs handed from manager to manager which would scare you to death.

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

#243
post #228
post #162

Earlier quoted context omitted.

> 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…

Shades of the Monty Python sketch here, but the following is true... 4MB?!? My first encounter with IBM kit was a, er, darn I'm not sure cuz I'm getting old, but I think it was a 4300? Not big iron in some senses, but still with a box that was something like 6-8 feet long iirc and definitely several feet wide and high. (And a bank of about 6-8 tape decks, each as tall as me, and two disk units, each the size of a was…

> including a brand new building to house it

Ha yes the aforementioned IBM 3090 was so big for installation they removed the roof of the building it was living in, craned it in place and put the roof the back. Bringing it up the elevator or stairs was impossible.

Much later, in the second half of the 90s, I remember the four of us carrying an IBM HDD -- I think it was your normal 5.25" drive but it needed four people because it was mounted on a vibration dampening base ...

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

#244

Earlier quoted context omitted.

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...

Yep. Funny enough, Linux is actually not POSIX certified POSIX was initially a bunch of the Unix vendors getting together in the 80s seeing a rise of incompatibility saying "this shit is crazy let's find something we can agree on" and then the conflicts of trying to still have a differentiating But Also compatible product. They knew that if they cannibalized themselves, IBM Novell and DEC were there to snatch up the…

Got it. I'm the dev tools guy at my job right now, and we have a mix of Linux and Mac users, so I've gotta make sure that any shell I write works on both. For me, POSIX seems to be a good indicator of the intersection between the two OSs, even though the true intersection is neither a superset nor subset of POSIX (eg, Mac has bash, which isn't POSIX shell). Oh well. It's close enough to be useful, and I test it all manually anyway.

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

#245
post #158

Earlier quoted context omitted.

You’re discussing modern tooling in a conversation about early UNIX tooling. Back in the period being discussed, even ‘read’ was less functional. Ksh introduced a lot of the stuff we now take for granted, some of which wasn’t even available until the Ksh93 (long after Perl was released). Bash itself is a younger project than Perl. Albeit not by much.

Fair point. I'm not arguing that Perl wasn't an improvement back then, but that the approach of composing Unix tools is not inherently bad. And as the shell ecosystem evolved since then, and more capable programming languages appeared, Perl has been left by the wayside as a historical relic, rather than the replacement of Unix tools that Wall envisioned. So I don't disagree that it was needed back then, but it's impo…

Perl is still a commonly used tool chain. It is far from being a “historic relic”.

I agree that there’s nothing wrong with composing UNIX tools. I mean, that was one of its key selling points. if you watch any early promo videos for UNIX you’ll see them talk heavily about the composability of the command line and shell scripting. It wasn’t an accident — it was designed that way.

The point of the conversation wasn’t to say that one shouldn’t write shell scripts, it was just to say that there was a massive and unfilled gulf between what was easy to do in Ksh, awk and sed, and what could be done in C.

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

#246
post #209
post #173

Earlier quoted context omitted.

> For a start it doesn't have a decent answer to Perl or Ruby's one-liners. This is by design. Readability is core to the design and philosophy of python. One liners are cool and fun to write, but trying to decipher someone else's incredibly dense bash or perl one-liner is absolutely awful.

The readability complaint usually comes from people who never took the time to grok the language and its idioms. At least give the user the option. Advocating a language based on what it denies you doesn't make sense. Why use a scriptig language at all if belt and braces is what you're looking for?

This topic is akin to "holy wars" and since I used to think the same way (still do to some extent), I would like you to at least consider another aspect: the effort it takes to "grok the language and its idioms" is vastly different depending on the design of the language. Letting people do whatever they want, whatever way they want it isn't only about protecting them from themselves or not.

Just think of C: I'd argue its design is actually more akin to Python than Perl (and it definitely inspired languages like Go and Zig, NOT languages like C++). It's a small language and this is a very important characteristic of it: you can count on being able to actually master it or at least very well comprehend it. Other effects of a simple and literally straightforward language can be: easier implementation and evolvement, less mental load on the developer, easier portability among developers (both for general knowledge and actual code), etc. I'm not saying that C is the way it is for all these reasons but I wouldn't overlook this factor and I do think that languages like Python are deliberately building on these advantages.

Now, I don't dislike C++ at all but back when I studied it at university, I noticed that it was the first language for me that needed to be actually studied, unlike Pascal, C, Python and "oldschool" JS. Ever since, the only languages where I felt the same were Prolog (mostly because it requires a different mindset; other than that, it didn't seem bloated) and Raku. Not C#, not Java, not Erlang. I didn't really have to touch Perl but from all I know, Raku started off as a fresh take on the Perl approach. It seems somewhat more organized but huge nevertheless, to the extent that there literally isn't one person who really "groks the language" all around. In the case of Raku, I wouldn't even say it encourages you to write unreadable code (especially if you have a thing for APL look-alikes, lol) - it's just so rich that there is a good chance you will come across something in someone else's code you have never used before and don't quite remember how it will act in your specific use case.

There are different types of freedom than "do whatever you want". Like, the freedom to feel safe and confident about code. These days, humanity has aggregated an immense amount of knowledge and technology and "I will do it all by myself" is not that much of an option. And even people with such puritanistic tendencies will choose simple and straightforward tools, even if not for the "limitations".

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

#247
post #17

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, I still use awk and sed semi regularly. I haven’t used Perl in over a decade.

What is the reason for that? I think they should be long gone for the lack of proper data structures, if nothing else.

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

#248
post #175

Earlier quoted context omitted.

> I still use awk and sed semi regularly. I haven’t used Perl in over a decade. Same. Awk and Sed are delightful little tools that have aged exceptionally well.

They are also constrained languages which gives many advantages. POSIX regex will always execute in O(n), Perl "regex" are potentially exponential and can be a security risk in certain situations.

Well, that's at least an actual argument, even though POSIX regex would have never proven so useful in a variety of use cases.

Other than that, I'm completely shocked that somebody would praise sed or awk in well into the 21st century. Turing-complete languages barely capable of properly solving any problem that has any sort of algorithmic complexity, let alone one that requires proper data types, variables or interacting with any sort of system. Really, you can do that in Perl (even in Raku) without your couple-of-liner horribly breaking down once you need some custom logic to it. Oh, and it will even resemble programming languages, not some hieroglyphs left behind by aliens.

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

#249
post #2

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

Doesn't booking.com still run on it?

Yes. Actually a lot of companies still run on it. Booking.com, Fastly, ByteMark, OpenCage, I even know of a few startups that run on Perl.

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

#250
post #112

Earlier quoted context omitted.

Perl was huge in the early web and first dot-com boom, it was used a lot for CGI scripting.

I miss CGI internal tooling. It was always fast and just did the thing you want. Now we have bullshit recursive lambdas with nonsense UIs full of harmful whitespace. I started with Perl CGI and have been less productive every year since then.

Seriously. I feel like 99% of the work I do in Micro-Service/Event-Driven/etc systems could realistically be a few CGI scripts hooked connected to a DB via DBI. It's sort of ironic how people often call Perl "overly complicated" or "confusing" then justify 100+ service clusters using K8's and AWS to serve 1000 users/day. AdventOfCode handles a few million users per day during the weeks it's active, all powered by a few FastCGI scripts, it's still really good technology.
Post reply on HN