Live data from Hacker News

Half My Life with Perl

perladvent.org

41–50 of 139 posts

Re: Half My Life with Perl

#41

I’m about to turn 40 and have been thinking if I should learn Perl or AWK or go with a “modern” solution for text wrangling on the command line. The general advice here seems to be “learn Perl while young”

What's the modern solution to text processing on the command line?

I don't think anyone tried seriously addressing that use case after Perl. Like, obviously you can do text processing in any language, but you're not going to be doing it in the context of shell pipelines and one-liners. The preferred interaction modes are totally different.

Re: Half My Life with Perl

#42
post #35

I’m about to turn 40 and have been thinking if I should learn Perl or AWK or go with a “modern” solution for text wrangling on the command line. The general advice here seems to be “learn Perl while young”

Perl was 1 line vs. 100 lines in everything else, in text processing. Now it is 1 line vs. 2-3 lines that are clearer and have stricter semantics. It also has support for running oneliners straight from cli. You probably don’t want to learn it today, as it won’t make that big of a difference.

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.

Re: Half My Life with Perl

#43

I’m about to turn 40 and have been thinking if I should learn Perl or AWK or go with a “modern” solution for text wrangling on the command line. The general advice here seems to be “learn Perl while young”

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.

I've used awk for a lot of weird shit over the last ~30 years and while I agree it's much more straightforward and convenient than Perl for most simple tasks, "expert in a week or two" is no.

Re: Half My Life with Perl

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

[deleted]

Re: Half My Life with Perl

#45
post #40

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…

My experience with Perl is that often the batteries are rotting. Not a strong opinion though, i haven’t been writing perl in a while.

Can you give a specific example?

Re: Half My Life with Perl

#46

I’m about to turn 40 and have been thinking if I should learn Perl or AWK or go with a “modern” solution for text wrangling on the command line. The general advice here seems to be “learn Perl while young”

Go with AWK. When your AWK code gets too complicated, that's the signal to switch to something more documentable like Python, Ruby, etc.

Re: Half My Life with Perl

#47
post #35

Earlier quoted context omitted.

Perl was 1 line vs. 100 lines in everything else, in text processing. Now it is 1 line vs. 2-3 lines that are clearer and have stricter semantics. It also has support for running oneliners straight from cli. You probably don’t want to learn it today, as it won’t make that big of a difference.

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.

Ruby? It has perlisms and awkisms around, here's a stupid example:

    echo -e "foo 1\nbar 2\nbaz 3" | ruby -n -e 'BEGIN { puts "===" }; $_ =~ /^b\S+ (.*)/ and puts "#{$_.chomp.upcase} => #{$1}"; END { puts "===" }'
There's -p too, -0777 works for slurp mode, throw in -rjson to get battery-included pretty_generate, interpolation can be nicer, but $_ is not implicitly used so it can get a bit more verbose than Perl.

Re: Half My Life with Perl

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

It's not a race. Perl got there fast by basically not giving a damn about anything.

Perl (talking about Perl 5, don't know anything about Raku, don't want to know anything about Raku) simply treats strings as sequences of numbers without requiring numbers to be in the 8-bit range. This makes it easy to say that those numbers could in principle be Unicode codepoints. The problem is that the actual assumptions about what those numbers represent are implicit in programmers' minds, and not explicit in the language, much less enforced in any way. The assumptions shift as strings are passed between different libraries, and sometimes different programmers working on the same codebases have different ideas. Perl will happily do things like encode an already-encoded string, or decode an already-decoded string, or concatenate an encoded string with an unencoded string, or reverse a utf-8 string by reversing the encoded byte sequence, etc. etc. So it's easier in Perl than in any other language I've ever used to end up with byte salad.

It'll take you, let's say, the first few years of your Perl career, involving painstaking testing of everything you do with nontrivial characters, to truly grok all of that. But the problem is: You're not alone in the world. If you work on a nontrivially-sized project in the real world that heavily utilizes Perl, then byte-salad will be what you will get as input. And byte-salad will be what you will produce as output. It is frustrating as hell.

Unicode was a pretty painful matter in the transition from Python 2 to Python 3, but Python's approach means that the Python ecosystem is now pretty usable with Unicode. This is not the case with Perl at all.

Re: Half My Life with Perl

#49

Earlier quoted context omitted.

I wonder how much of catering to the lowest common denominator / being a team player is an internalizing of corporatisms reduction of the worker to a fungible interchangeable cog. As a solo dev it is a massive advantage to use sophisticated languages and tools without worrying if the dumbest person on my team can use them. It’s a strategic advantage and I run rings around far larger companies.

I agree with you that it is sad there isn't more diversity in languages and tools, and that generally organizations are using the same terrible slop. We could have such nice things You lose me with the smugness. Make no mistake, you aren't smarter or better than someone else purely by virtue of your willingness to hack on BEAM languages or smlnj or Racket or whatever languages you like. There are probably people smar…

[deleted]

Re: Half My Life with Perl

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

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't I just use "open my $f" and everything works the way it obviously should? Well, kinda, unless you want to be able to store an existing filehandle like STDIN in there, then you have to do something different again... Do I need IO::Handle instead? (Why does that need to exist...?)

Post reply on HN