Comment by noisy_boy | Hacker News Reader

Comment by noisy_boy | Hacker News Reader

I remember reading the Perl O'Reilly book (Introduction to Perl[0]) end-to-end and basically feeling that it all makes sense - ($)calar, (@)rray and % for dictionary (because we have a pair of "o"s representing key/value) and so on. Coming from only writing bash (which is all people around me wrote), it was like a becoming a superhero overnight. I rewrote all my bash scripts in Perl and got high level language features with blazing speed. I relished taking people's bash scripts that took an hour and rewriting them in Perl for them to take barely few minutes (which was objectively terrible performance but I was a novice programmer then and nobody else knew better). I was a hotshot. It was an awesome feeling.

Later I got another role solely because they couldn't find Perl programmers and I wasn't half bad at it. But this was an actual application written by a bunch of people who wanted to write clever code and it was like handing over the keys to a missile depot to a bunch of arsonists. Many thousands LoC. By the end of it, I was told that we need to move to using Java and I could barely contain my relief.

For one-off scripts, still nothing flows like Perl. It is the most interesting language I have coded in, bar none.

[0] correction: Learning Perl, the llama book (thanks @ninkendo)

You stole my story! :)

I was a mediocre developer and student in my CS program and actually considered getting out at a few points. I really loved systems and building solutions though, and I ended up becoming a DBA.

For some reason my mental model resonated with Perl. I was able to use it almost like a writing process, getting my “outline” laid out in Perl and refactoring supplementing with more efficient C code or third party stuff later.

It was cool, i started fixing data integration issues and automating processes around the databases. Eventually a colleague and I basically built an application that made our DR testing failover and failback processes a two-click event. I left that company long ago and I know a bunch of our stuff ran almost 20 years before the system was migrated to AWS.

IT is more industrial and efficient these days. That’s not a bad thing, but I had alot of fun being the kid showing the old people what Linux was and gluing all of these systems to orchestrate them. Unfortunately Perl is an artifact of that era.

I felt the same when I used Python to rewrite some broken/incompatible C code. It didn't save on performance, but it did reignite that hacker mindset with a clear to write language. I show students my Flask sets up and I can see the light bulbs firing off in their brains.

The older languages may be artifacts of our era of code, but I'm excited to see what the next wave of documented prompting vibe coding will bring.

I might finally understand what the heck my students' code is doing HA!

There's so much I can write here, not only do I agree with you - there remains little better for processing streams of text than perl.

Even PHPs prominence (and ease of use) can be traced back to the parts it borrows from Perl; since the web is just manipulating text after all.

I went on a similar journey to you. Started with C, moved to bash, then to perl to replace bash scripts, and you're right that it feels like a super power.

But the most interesting language I've ever coded in was probably Ruby, because it changed the way I look at languages. In Ruby, everything is an object and everything is mutable - this makes the dynamic metascripting possibilities simply absurd.

I don't advocate for these languages anymore, as Perl is easy to become "write once, read never", in a way that's much worse than bash- but I can't help but feel like we have definitely lost a killer language for text processing. Seemingly nobody writes perl anymore.

I do :)

> there remains little better for processing streams of text than perl.

That's true, but obscures what IMHO is a deeper truth: thinking in perl naturally leads to thinking in "streams of text", which is a kind of general composability that's been largely forgotten in the Unix world.

These days every project has it's own giant list of dependencies, it's own conventions about code structure, it's own list of para-toolchain utilities like linters and formatters. Often it even has it's own set of vscode extensions you pretty much have to use.

Nothing is just a tool anymore.

So much this. While software is generally more reliable now, it certainly isn’t composable, and the ability to script solutions on the fly has been lost.

So often, people want their systems to be scriptable… they were once, and then people destroyed the things that made all that possible.

The Camel Book.

There was something so wonderfully down-to-earth and humane about those O'Reilly books. But actually most IT books had something casually playful and creative about them. A quality you rarely find these days.

It was the second book that I actually loved. I read it several times, in no particular order, like one just dives into chomping on a fond snack.

The camel book was “programming Perl” and was more geared towards existing programmers IIRC… there was also the llama book, “learning Perl”, which was maybe what GP was referring to?

Learning Perl (the llama book) was my first programming book, and it taught me programming in general, not just Perl, and I still think it was an amazing book. Very approachable, helpful to beginners, I read it cover to cover. There’s also “learning Perl objects references and modules”, which is a bit of a sequel to Learning Perl. Those two books helped me land my first gig as a Perl programmer, and started my whole career.

Thank you, it was indeed Learning Perl, the llama book.

…and sadly because they're already outdated by the time they reach the printing press these days.

Maybe

But I couldn't understand anything of it.

Hence I became an economist within cyber security instead.

Sounds very familiar. For me I was writing batch scripts and the book was Learning Perl on Win32 Systems. Otherwise it’s the same story.

Ah, back in university I wrote a paper comparing Perl, Python and Tcl/Tk.

Tcl was by far the easiest to use, while Perl sat on the other end of the spectrum for both skill needed to write it as well as to just be able to read it.

As the mantra goes, "Power, but at what cost?!?"

Modern python is far more complicated than anything one saw in a perl 5 script back into the day. Type hints, decorators everywhere, big frameworks like numpy that force your problem into particular paradigms. The modern focus on async and iterables has had the effect of turning even simple code "inside out". It's complicated!

And what's interesting is that it's complicated in a lot of similar ways, in terms of thought space, as perl was. Perl was great because you could be clever, where you really couldn't in more pedestrian languages.

I find (and I'm not sure this is a good thing) that my python output these days feels very clever sometimes...

Reply on news.ycombinator.com