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

191–200 of 261 posts

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

#191

Post by thesuperbigfrog »

tharne wrote: post #173
cutler wrote: post #167

Earlier quoted context omitted.

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.

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

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

You can write hard-to-read code in any programming language.

Python lets you with mandatory whitespace so that the awfulness spans multiple lines instead.

Really talented Python programmers can do downright demonic stuff with list comprehensions.

Python appears to be simple, but is actually quite complex. I recommend reading "Effective Python" (https://effectivepython.com/) to see beneath the surface.

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

#193

Post by beebeepka »

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.

Yes, exactly. I have seen entire backend systems written in bash. Everything was shell script, sed and awk. The owner didn't want python or perl because he only knew bash and the related tools.

Everything was needlessly hard because these tools were not built for that. Easy to talk about philosophy and the "classic Unix approach" if you don't have to build modern applications this way.

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

#194

Post by justinator »

dhosek wrote: post #76
adastra22 wrote: post #44

Earlier quoted context omitted.

Yeah CPAN is easy to take for granted now that every language has its own package manager (npm, cargo, pip), and even for C/C++ you can find what you want on GitHub. At the time though CPAN was revolutionary and no one else had it. To be able to just search for a module, find one that did what you wanted, then download it to your project was pure magic.

There is some question whether CTAN (for TeX) or CPAN was the first big library. It was pretty close. I was involved tangentially with the guys in the UK who were setting up the first pass at CTAN as the administrator of the ymir.claremont.edu archive and I remember one of the things that they came up with back then was that you could do an FTP get of any directory and get back a zip archive of its contents which was…

>assume a single version of dependencies will be installed on any system which causes untold nightmares when it turns out that there’s a non-backwards compatible update to something three dependencies deep that you weren’t even aware you were using.

I may not completely understand what you're describing, but with perlbrew managing different Perl versions, and various CPAN clients installing modules in versioned libraries - as well as the test/smoke servers that test CPAN on tons of versions of Perl for Perl CPAN authors automatically, I don't know if I've come across what you're describing.

What's still a pita is when there's an outside dependency from the Perl ecosystem that breaks a module, but I'm not sure that's Perl's fault.

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

#195

Post by grumpyprole »

tharne wrote: post #175
imron wrote: post #17

Earlier quoted context omitted.

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

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

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

#196

Post by justinator »

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…

>We chose the immediate benefits for Perl 5.

Well, I thank you.

Is there a summary of what Tom Christensen did? I hold him up pretty high when it comes to Perl lore. I don't know from what you wrote if he's the hero or villain in this case (and if you don't remember that's fine: ancient history)

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

#197

Post by casey2 »

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

Should have just embedded a shell with Unix inspired (perhaps even plan 9 - 1992) command suite, implicitly treating piped HTML as plaintext corresponding to the rendered page. So the user which is 99% of people is better served rather than some random developer who happens to know perl.

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

#198

Post by stanleydrew »

sigg3 wrote: post #165
Scubabear68 wrote: post #49

Earlier quoted context omitted.

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…

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

It's not a lack of being "taught" shell scripts. It's the fact that shell programming constructs aren't well documented, your "standard library" is basically dependent on whatever binaries happen to be available on the filesystem, error handling is almost non-existent, etc.

It's very easy to write a bad shell script that "solves" a problem as long as a bunch of assumptions aren't violated. In my experience, senior software engineers are extremely averse to hidden assumptions and very concerned with reliability of the systems they build.

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

#199

Post by justinator »

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…

>They did not add support for encoding/decoding html entities or URLs were added.

It's certainly not in core, but look how PHP flubbed that up (html_entity_decode, htmlspecialchars_decode, htmlentities).

>No standard modules for this.

Obviously there are,

https://metacpan.org/pod/HTML::Entities

The changelog goes back only to 1998, where it states,

    2.14     1998-04-01
    HTML:: modules unbundled from libwww-perl-5.22
That wasn't a hurtle to developers, but certainly to end users who did want to just throw a php script up and have it work.
Post reply on HN