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

231–240 of 261 posts

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

#231

Post by thesuperbigfrog »

wodenokoto wrote: post #143

Reading this summarizes my feelings on what kind of new language we need. Something that makes workloads usually delegated to find, grep, sed and awk coherent and easy to use, allows streaming data between functions/commands and can still be used to glue things together. Can I use Perl instead of bash/as my command line ? Should I start learning Perl?

>> Can I use Perl instead of bash/as my command line ?

No. Perl is not a command line shell just as Python and Ruby are not.

>> Should I start learning Perl?

If you are doing workloads with the command line tools you list above (find, grep, sed and awk), yes.

If you are familiar with bash, sed, and awk you will find Perl familiar-looking and very handy.

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

#232

Post by btilly »

justinator wrote: post #196
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…

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

Essentially Tom was both knowledgeable and abrasive to an extreme. Technically he was brilliant and a valued asset. But socially he was a center of conflict. And the result was that Perl 5 development ground to a halt and other people left.

I don't know everything that Larry did about the situation. But it was a situation that everyone on p5p was painfully aware of at the time.

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

#233

Post by btilly »

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…

BS. CGI.pm was part of the Perl core in 1997. And Perl was the language that dominated the dot com boom.

The thing that PHP did better than Perl was the ability to be set up on shared web hosting. Mind you, it did that mostly by not acknowledging all of the security holes that it had which allowed one user access to what should have been private for another user. But shared hosting providers had a population of people who wanted to use PHP, were forgiving of major security flaws (which PHP had many of), and would pay money.

Meanwhile Perl went the route of doing things right, and being much more secure. Which, even though it feels important to good developers, is bad for marketing. It was a classic Worse is Better situation. See https://www.dreamsongs.com/RiseOfWorseIsBetter.html if you're not familiar with that concept.

And, in the end, the commodity wins. So in the mid-2000s, PHP did catch up and beat Perl.

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

#234

Post by btilly »

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?

It is ludicrous to claim that Perl didn't support web development. From Amazon to eToys to Citysearch to Stamps.com, big dot coms were all based on Perl.

Big PHP shops like Facebook, and PHP projects like WordPress, came in a later development generation for the simple reason that PHP made it easy to get started on shared webhosting.

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

#235

Post by djbusby »

cutler wrote: post #211
djbusby wrote: post #204

Earlier quoted context omitted.

Well, I'm not sure about everywhere but, the work I'm finding is ASP3.0 (IIS6.0) and VB6 (more rare) also Perl and PHP. Many of these projects were started in the late 90s. They are internal systems (billing automation, internal work-tracking, custom "ERP"). Nothing exciting, just old shit that makes money in a non-tech business. I find the work on LI, and I show up when folk search for these olds skills. But I know…

Do you find any of these legacy system clients are open to having their system upgraded to a modern version of the same or related language, eg. .Net for ASP? After all, it wouldn't involve a significant change in the business logic and most esablished languages are more or less backwards compatible.

I hear that. I want that. But, mostly what I see is that at least once before a vendor shit the bed on a rewrite in $ModernX and then the business play became "nurse it".

And, having been through many rewrites myself, I frequently surprised they could hose the deal. It feels like scope-creep is the killer but I only have feelings for the data, no metrics.

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

#236

Post by stubish »

wodenokoto wrote: post #143

Reading this summarizes my feelings on what kind of new language we need. Something that makes workloads usually delegated to find, grep, sed and awk coherent and easy to use, allows streaming data between functions/commands and can still be used to glue things together. Can I use Perl instead of bash/as my command line ? Should I start learning Perl?

I found Perl a practical replacement on the command line (not as the command line) to command line sed and awk, to the point I never learned sed and awk. Thanks to the -p and -e options (perl -pe 's/foo/bar/'). It never felt like a practical replacement to find. It would probably work as a grep replacement, but my fingers already knew grep. Today? Don't know. Back in the day though, in your standard heterogeneous environment it was the most practical way of working since your awk and sed seemed to be platform dependent in many ways (awk, gawk, nawk, proprietary extensions etc.)

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

#237

Post by cutler »

kagevf wrote: post #230
cutler wrote: post #224

Earlier quoted context omitted.

The book constains Perl one-liner-style equivalents of these UNIX utilities which you can just drop into your bin directory.

Cool, I'm in the market for that.

For Perl-style grep there's also ack and it's successor ag which you might want to look at first.

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

#238

Post by _8j50 »

autarch wrote: post #200
_8j50 wrote: post #192

There was no Git in 1987, so was this migrated from something else to git? If so, what vcs did they use?

I don't know the entire history, but for a very long time the Perl 5 source was in Perforce. It was migrated to git in 2008.

Thanks

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

#239

Post by burntsushi »

mcswell wrote: post #88
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.

Perl still does have the best Unicode support, especially for regex's. In comparison, grep has imitation Unicode support (the -P "Perl" flag helps, but it's still nowhere near as powerful as Perl regex's). Python's standard regex library, re, is better than grep's regex's, but still not as good as Perl. Python also has a non-standard regex library, regex, in PyPi, which I think is as good as Perl. And yes, I deal wit…

Can you share some examples of Perl regex Unicode support that you make use of in real programs? Examples of stuff that can't be done (or easily be done) in PCRE would be awesome. :)

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

#240

Post by unpythonic »

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

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

The effortless composition of complex commands out of simple standalone programs is one of the best features of Unix. And yes, I admire and love it as well.

That said, imagine a metrics system for a huge networking company that used these methods to cover all automated testing or defect analysis. Those inner loops were made of greps and seds and so forth, and each one is the invocation of a new program. It wasn't uncommon for these runs to take almost a day.

Besides performance, the other nightmare was was someone described below: each script was a one-off that didn't leverage the work from others. If the author only new C shell, then you know you're going to be doing gymnastics to catch the stderr of some of those programs (you can't capture it in the same manner that Bourne variants do).

Anyway, yes, we all adore the Unix philosophy, but there are limits.

Post reply on HN