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

Half My Life with Perl

perladvent.org

Post reply on HN
Print view View original

101–110 of 139 posts

Re: Half My Life with Perl

#101

Post by stouset »

RandalSchwartz wrote: post #19
stouset wrote: post #15

Earlier quoted context omitted.

Frankly nothing. Ruby is a strict improvement over Perl in almost every way. I cut my teeth on Perl and I still remember it fondly. But there is no reason to learn Perl (5) over Ruby. Maybe Perl 6 is a different story though.

I believe Perl got Unicode to a usable state long before Ruby. Ironic, given Ruby's origins.

On the other hand Ruby has the Schwartzian transform baked in :)

    foo.sort    { |a,b| a.expensive  b.expensive } # basic
    foo.sort_by { |a,b| a.expensive  b.expensive } # Schwartz-enabled

Re: Half My Life with Perl

#102

Post by harry_ord »

doublerabbit wrote: post #55
temporallobe wrote: post #17

Perl is my first love, and I still whip it out from time to time to do system tasks (anything in the linux world). It is literally installed on any *nix OS, macOS included. Python is fine, but it’s not as universal as Perl. I also feel like Perl is more “batteries included” as many times I can be productive without “use”ing any libraries. It’s has been my secret weapon over the years. I’ve also noticed that most youn…

MSN Messenger contact bots got me in to perl back at 15, 35 now and still coding it for work as a legacy maintainer. Pays well.

Nice similar age, I got into it as my first job after university and every job since

Re: Half My Life with Perl

#103

Post by emptiestplace »

creer wrote: post #79
RodgerTheGreat wrote: post #36

Earlier quoted context omitted.

Learn AWK. It's tremendously simpler than Perl, and even more omnipresent. In a week or two of study and tinkering you'll be an expert.

Awk is too specialized, specific. Perl is amazing at text processing AND also amazing at much more. The basics of perl for basic awk-like functionality is really not much to learn. Skip awk and learn something more useful. This works because perl is layered. To do even fairly elaborate awk-like text processing you only need to learn a little perl. Nothing like all of perl. To do the rest (of elaborate text processing…

awk is purpose-built, lightweight, and perfect for line-oriented tasks. Perl can do everything awk does and much more, but that power comes with complexity. If you just need text processing, awk is simpler and sufficient. If you need more than text processing, consider modern alternatives like Python that are easier to maintain and collaborate with.

Re: Half My Life with Perl

#104

Post by [deleted] »

pjmlp wrote: post #70

Despite being famous for being a cryptic language, in most cases in UNIX world, the safest way to code was to do userspace stuff in Perl, and only if it really mattered, rewrite in C. This was more approachable in Perl, than Tcl or later Python, as Perl does expose most of UNIX API on its standard library in a more C like fashion. My Perl 5 camel book got a fair use back in the day.

[deleted]

Re: Half My Life with Perl

#105

Post by AnimalMuppet »

wruza wrote: post #38

Tbh, for me it was a source of regex knowledge, in retrospect. Remove regexes from perl, what’s left? I can name: dynamic scoping, implicit filehandles, implicit $_, strange contexts, keyword-like list functions. That’s basically it, and while it sounds fun, it doesn’t do much in a sense of code reduction. $. $? $$ etc, well you can split lines with .split('\n'), get status as a part of result, call os.getpid(). , yo…

$_ is not just a kid's toy.

Let's say I'm talking to a human programmer. I say, "Read in a line of text. If it ends in a newline, remove the newline." Cool.

But when I talk to a computer, I can't talk that way. It says, "If what ends in a newline?" It doesn't understand "it".

Except in Perl. In Perl, $_ is "it". It's what we're talking about if I don't specify something specific. It's where the line of text gets read into if I don't specify a destination. It's where the newline gets removed from if I don't specify a variable. It lets me ignore specifics when I don't care about those specifics. It makes Perl much closer to how we talk to each other instead of how we talk to computers.

Re: Half My Life with Perl

#106

Post by mikeInAlaska »

I love perl. I work with it every day still, 25 years later. I recently rewrote a cellular provisioning API in it to be fully object oriented.

I do not write it to win an obfuscation contest. I like it to be read as easily as possible. It is a joy to watch the core objects of the system work together so cleanly.

Re: Half My Life with Perl

#107

Post by creer »

bm98 wrote: post #94

That was a great talk! Notice how his entire career got launched from an internship at Tektronix. I love the bit about how he found his own troff macros in use at O'Reilly because a coworker had taken his code there years before -- and he appreciated that! One might say that the same kind of "80's hacker ethic" is what got him into trouble at Intel. The Camel book was so well-written. It was my introduction to Perl,…

> Perl 5 has been in maintenance mode for so long

Perl 5 has been adding features consistently over the years, not just fixing bugs. Many people just ignore the new features, but you don't have to.

Re: Half My Life with Perl

#108

Post by chongli »

wruza wrote: post #51
wodenokoto wrote: post #42

Earlier quoted context omitted.

What's the 2-3 line alternative to perl you are referring to? I find piping into python to be a lot more than 2-3 lines before I'm even ready to do any manipulation of input, which again can get quite verbose. So I'm guessing it is not python.

I meant average line ratio, not literal one-liners, apologies for confusion.

When you're talking about doing things interactively (in a shell, either directly via a terminal or indirectly via an editor) then the constant factors matter far more than the asymptotics. This has always been perl's target for optimization. That's why it has a million obscure operators that no other language has.

Re: Half My Life with Perl

#109

Post by akoboldfrying »

mst wrote: post #78
akoboldfrying wrote: post #50

Earlier quoted context omitted.

I use Perl for one-liners all the time -- nothing can top it there. But when the task at hand grows just slightly bigger, to the point where I know I'll need to pass filehandles to/from my own functions, my skin starts to literally itch because of how bad the filehandle situation is. It's not plain "open F, ..." any more... Is it "*F"? Is it "\*F"? Are those the same thing? (What the hell is a "typeglob"?) Wait, can'…

Plain perl: open my $fh, ' Nicer: use File::Open qw(fopen); ... my $fh = fopen $filename; (and File::Open is simple pure perl code so if I need to distribute the script to random machines I throw App::FatPacker at it to produce a bundled version)

"my $fh" works fine if you only want to work with files you open() yourself, but what if you want to write a function that, based on some test, returns either that or the preexisting STDOUT filehandle?

Re: Half My Life with Perl

#110

Post by wruza »

AnimalMuppet wrote: post #105
wruza wrote: post #38

Tbh, for me it was a source of regex knowledge, in retrospect. Remove regexes from perl, what’s left? I can name: dynamic scoping, implicit filehandles, implicit $_, strange contexts, keyword-like list functions. That’s basically it, and while it sounds fun, it doesn’t do much in a sense of code reduction. $. $? $$ etc, well you can split lines with .split('\n'), get status as a part of result, call os.getpid(). , yo…

$_ is not just a kid's toy. Let's say I'm talking to a human programmer. I say, "Read in a line of text. If it ends in a newline, remove the newline." Cool. But when I talk to a computer, I can't talk that way. It says, "If what ends in a newline?" It doesn't understand "it". Except in Perl. In Perl, $_ is "it". It's what we're talking about if I don't specify something specific. It's where the line of text gets read…

It’s also where you (or your adhd colleague, or future self) introduce a subtle bug if one of your subs reads another stream and you forgot to local $_ in it. And you realize that you don’t always understand what “it” is either and that it is a bad idiom for formal systems. Isn’t worth it in the long run, especially in implicitness-ridden code that perl encourages. Write out your “line” and assign it back:

  if (line ~= /\n$/) {
    line = chop(line)
  }
Or use a library with helper functions akin to chomp(). This sentence-like code with $_ is a sign of wrong level of abstraction which solves small tasks with smaller components. If a language claims text processing capabilities, it should provide a function or a generator that does “read this file and split by [ omitting empty ones but keeping original line numbers in the emitted records][ also erase /\s*#.*$/-comments][ keep original lines too]” among other common tasks. All this $, $. $/ $_ could be just a couple of functions that accept a config argument with few optional callbacks for custom needs. You don’t have to create a whole language to read lines split by newline then by separator. Same for matching vars, could be just a sliding context arg to a properly designed matching api.

You may argue that other languages don’t have it either, well that’s true. Standard libraries usually suck compared to what perl does out of box.

Post reply on HN