Hacker News Reader

Comment by kdklol | Hacker News Reader

I discovered Perl basically by accident. For scripting/systems administration its simply unmatched. It's been clearly designed for speed and utility which is what I always wanted and I'm a bit disappointed nobody ever mentioned it to me. I'm 20-something btw, so it's not just ravings of an old man. I think the catastrophe happened when people mistook this it for a backend development language... and it somehow worked. Not well, but it did, which is it's own quality. I slowly started learning it half a year ago and it's been really useful for scripts. It's indeed more robust than POSIX shell which tends to have baked in assumptions about the system which may not transfer well onto different platforms. No regrets - the grey beards were right!

View on HN

Yes, it's a great language for this application.

Make sure you read Damian Conway's book "Perl Best Practices" as a guideline for crafting consistent and readable code. People's biggest gripes about this language generally revolve around poorly written code that is hard to read. Also, when writing regexes it helps to paste one or more example lines or matches above the regex so there is no question about what you are trying to do. 9/10 times I've found debugging SA perl scripts comes down to an unhandled pattern in a regex and this is what helps the most when re-writing it to ensure it doesn't break anything else.

Can you recommend any free resources that amount to an "effective minimal core" or crash course for Perl? I'M a Python dev, but I use sed/cat a great deal, and maybe Perl is a better solution. (Take me to the Dark Side.)

edit: you said "free", but this isn't technically free

For me, going through the llama book (Learning Perl) and actually doing the exercises was great. I would think I got it after reading the chapter, but when I went to do the exercise, I realized I had to look up the info again. Putting it into practice was great for internalizing the information. I can't believe there's an 8th edition now (from 2021!). I must have used the 2nd edition (1997) at the most, so I'm assuming it's still good.

Since you know sed/awk, you're going to see where a lot of the ideas came from.

I'd suggest the last edition of Modern Perl.

It is dated but it's free online:

http://modernperlbooks.com/books/modern_perl_2016/index.html

Difficult to say.

I picked up a bunch of info from perl.org: https://perldoc.perl.org/perl#Tutorials

Perlmonks was a good source for certain specifics.

Doing is better than reading IMO. Open files, parse log data or such with regexes, sort them into a hash, and return that by reference. Perl has different ways of doing things that aren't common in some languages such as how it deals with binary data (see pack/unpack).

Coming from python, I would say forego the delving into OOP aspect of perl as it is more of an afterthought than a core feature. Focus on understanding data management with scalars, lists, hashes, and the core functions (Perl has native functions for things like sorting which are quite useful).

I managed to go from C to perl over a weekend but it takes hours of practice to improve.

Thank you everyone in this thread for suggestions.

I personally learn by practice. Writing stuff. I've read good things about the "Modern Perl" but I'll check out Conway if people here are vouching for it. Also, Perl's manpages actually teach you the language - another advantage of an older language from a time when people knew what manpages were and how to write them. They're not OpenBSD quality, but they're pretty good from my experience.

I recommend this blog post to all devs I work with that need to pick up Perl: https://qntm.org/perl_en

> Make sure you read Damian Conway's book "Perl Best Practices"

Extend this to any media you can by Conway. He's in my top 3 of tech presenters and I'm really not that into Perl.

The problem with Perl isn't that you cannot write good, comprehensible code it's that doing so is difficult.

Lol, what? Why? Are you that bad at programming that you can't structure code well without guardrails?

Lots of bad code was written in Perl by people who didn't know how to program. This is a feature, though. Tons of valuable software was created with the assistance of a language that attempts to get things done more than it tries to hold people to the implementor's dogma.

If you'd like to spend your time thumping your chest, go right ahead. I'd rather code.

Not at all, I'm an average programmer at best. But writing well structured code is about being conscientious of your team mates, it's about not being a show off, it's about not being arrogant even if you are the smartest person in the room, it's about reading some books on clean code, knowing what KISS is.

If someone can't write readable, maintainable, understandable code unless the language has certain guard rails in place, then they aren't doing the above things and I would consider them a toxic team mate, no matter how much of a rock star programmer they are.

  If someone can't write readable, maintainable, understandable code

I never claimed that it's impossible to write legible code in Perl. Perhaps work on your reading comprehension before doing all your chest thumping?

   it's about reading some books on clean code

It's about choosing the right tool for the job. Perl offers a number of enticements to write illegible code that other languages do not.

It's not so difficult to do, it's difficult to get people to do it.

Some of perl's features use syntax which is either very concise or uses implied operations or operands. Things like regexes, sorting, subroutine arguments, special variables can all be used in a manner which makes things more cryptic. In many instances you can be explicit (for instance with arguments):

my ($filename, $data_ref) = @_;

Rather than , randomly in code somewhere:

my $filename = shift;

If you cannot express something more explicitly in syntax to be clear you really should be using comments to elaborate.

Arguably this problem is the same across all languages. The issue with perl is that the brevity and flexibility of the language can exacerbate the grief one experiences when working with unfamiliar code.

I think this sort of argument misses the point of my comment. I really don't want to write serious software with Perl, I want something more powerfull than AWK, but not as cumbersome as a more "structured" language. I literally use AWK daily for random stuff I'm most likely gonna throw away or put it in a script which I'm gonna throw away happily the moment it breaks. Sometimes, AWK is not enough, and for these usecases, in my short expirience, Perl is unmached.

http://modernperlbooks.com/books/modern_perl_2016/index.html is also a good read.

i am a grey beard. i confirm "the catastrophe happened when people mistook this it for a backend development language"

I suppose I’m a grey beard (in industry is 96ish) and I mean, it’s fine as a backend language in so far as dynamically (or even loosely) typed languages go. It’s just as easy (or hard) to write modular well tested code as in any number of other languages in wide use for backend services, in my XP.

Reply on news.ycombinator.com