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

151–160 of 261 posts

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

#151

Post by silvestrov »

btilly wrote: post #77
idlewords wrote: post #46

Earlier quoted context omitted.

During a later period (early 2000's) Perl was the only scripting language with good Unicode support, including inside regular expressions, which was revolutionary at the time. There was so much cool stuff you could only do in Perl, and then like you say it all ran into the brick wall of Perl 6.

The brick wall of Perl 6 was itself a solution to an internal nightmare inside of core Perl development. Particularly around conflicts involving Tom Christensen, which caused no progress to be made on Perl 5.6.1 despite major bugs in 5.6.0. For example: my $x = 5 + 6; $x .= "0"; print $x + 5; # 16, not 115. The result in the year 2000 was a famous cup throwing incident by Jon Orwant. And Perl 6 was a plan to separate…

It also seems like the core perl developers did not want to acknowledge the importance of web/html.

They did not add support for encoding/decoding html entities or URLs were added. No standard modules for this.

No easy method of making html pages from a URL request besides running as CGI.

This made perl lose to php which made it very easy to make a simple "Hello, world" page.

php would never had any traction if perl developers had made web support high priority.

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

#153

Post by lolive »

imiric wrote: post #75
em-bee wrote: post #65

Earlier quoted context omitted.

you probably shouldn't abuse shell scripts to build a complex system, and beyond a certain level of complexity, a programming language is the better tool but the only free programming languages available at the time were C/C++, various shells, and awk. everything else was expensive or not generally usable for other reasons. all the really useful languages to build complex systems didn't really appear or become freely…

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.

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

#154

Post by WesolyKubeczek »

eigenlicht wrote: post #84
ForkMeOnTinder wrote: post #4

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've forgotten almost everything about Perl, but one thing I dimly remember is that for just about anything exceeding your one-liner/dirty one-off script (outgrow bash??) you'd use some library anyway, even for purposes like this. Just to make it sane. In other words it came down to more or less what you do in Python post Y2K: run(['blah'], ...) Not necessarily shorter (how?), probably not better (how?), certainly no…

It’s interesting that while macOS is weeding out scripting language runtimes as the internal tools get rewritten (in Swift, I presume), one that is likely to prevail is Perl, so deeply is it entrenched there.

Curiously enough, Ventura ships with not one but two perls, 5.18 and 5.30. I haven’t yet investigated which tools there are using Perl. (It could also be that some prominent third party applications still call out to Perl, expect it to be there, and vendors asked nicely. How else would you explain the 5.18?)

It seems to be an apt illustration of the Lindy effect more than anything.

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

#155

Post by shaftoe »

shrubble wrote: post #99
jancsika wrote: post #92

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

There's an old joke that emacs stands for Eight Megs And Constantly Swapping.

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

#156

Post by ykonstant »

silvestrov wrote: post #151
btilly wrote: post #77

Earlier quoted context omitted.

The brick wall of Perl 6 was itself a solution to an internal nightmare inside of core Perl development. Particularly around conflicts involving Tom Christensen, which caused no progress to be made on Perl 5.6.1 despite major bugs in 5.6.0. For example: my $x = 5 + 6; $x .= "0"; print $x + 5; # 16, not 115. The result in the year 2000 was a famous cup throwing incident by Jon Orwant. And Perl 6 was a plan to separate…

It also seems like the core perl developers did not want to acknowledge the importance of web/html. They did not add support for encoding/decoding html entities or URLs were added. No standard modules for this. No easy method of making html pages from a URL request besides running as CGI. This made perl lose to php which made it very easy to make a simple "Hello, world" page. php would never had any traction if perl…

Does Perl now support web development and if so, to what extent? Can you now do with Perl 5 what you can do with PHP?

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

#157

Post by jeremyjh »

speedgoose wrote: post #100
_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.

JavaScript being some kind of Lisp dialect with a C syntax is good IMHO. You also get some Perl inspired features in JavaScript, like the regular expression engine, and the not so user friendly array methods like slice and splice. The DOM API is also a bit more robust than string manipulation.

I know its history but Javascript is not in any meaningful sense a "Lisp dialect". Code is not data, code is not even an object, you have to define a function, closure or object to manipulate the code itself.

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

#158

Post by imiric »

hnlmorg wrote: post #149
imiric wrote: post #129

Earlier quoted context omitted.

> This works really well if your problem can be solved in one or two liners. My personal comfort threshold is around the 100-line mark. It's even possible to write maintainable shell scripts up to 500 lines, but it mostly depends on the problem you're trying to solve, and the discipline of the programmer to follow best practices (use sane defaults, ShellCheck, etc.). > It go bad very quickly when, say, you have two C…

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 important to mention the modern context it struggles to exist in.

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

#159

Post by vague_irssi »

ykonstant wrote: post #156
silvestrov wrote: post #151

Earlier quoted context omitted.

It also seems like the core perl developers did not want to acknowledge the importance of web/html. They did not add support for encoding/decoding html entities or URLs were added. No standard modules for this. No easy method of making html pages from a URL request besides running as CGI. This made perl lose to php which made it very easy to make a simple "Hello, world" page. php would never had any traction if perl…

Does Perl now support web development and if so, to what extent? Can you now do with Perl 5 what you can do with PHP?

Not like php, no. But perl has loads of excellent web frameworks(mojolicious, dancer, et al) and there is webperl.js which tries to bridge the gap to an extent, though I don't know if anyone uses it and what the quality of it is

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

#160

Post by anthk »

yjftsjthsd-h wrote: post #104
unpythonic wrote: post #11

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?

Gen-Zer spotted. No, Perl is not line noise.

Get the Perl source code for PangZero and you'll understand proper Perl code.

Post reply on HN