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

Not Your Grandfather’s Perl

stackoverflow.blog

Post reply on HN
Print view View original

171–180 of 257 posts

Re: Not Your Grandfather’s Perl

#171

Post by kqr »

MobiusHorizons wrote: post #97
cryptonector wrote: post #58

Earlier quoted context omitted.

Needs static typing. I'll let myself out now.

When was the last time this caused a bug for you? My experience of moving from JavaScript to typescript is that it takes significantly longer to write many generic things because the types can’t really express the intended use as well. I will certainly admit that types help a lot at the boundaries between systems , or for catching errors introduced when changing code, but it’s not always a clear win for types, given…

We actually have science on specifically plain ECMAScript versus TypeScript, where the software written in the latter has 15 % fewer bugs. https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-q...

But of course, the study does not account for if increased development time cancel out revenue gained from lower bug count. (And this will be a difficult problem in general, due to first-to-market effects etc.)

Re: Not Your Grandfather’s Perl

#172

Post by gyulai »

forgotmypw17 wrote: post #4

With function signatures and state variables added in 5.010, I consider Perl feature-complete and have not really missed anything from it for as long as I've been writing Perl. What I do appreciate that's missing from many other languages and systems is the extreme committment to backwards compatibility. The knowledge that the next minor release won't break existing scripts is underrated, IMO. Solo project with ~23K…

> What I do appreciate that's missing from many other languages and systems is the extreme committment to backwards compatibility.

Is that even something they're doing on purpose? Didn't they completely botch their attempt at a new major version?

When Python moved from Python 2 to Python 3, introducing breaking changes, there was enough velocity and acceleration in the Python ecosystem for people to be willing to take the pain.

With Perl it's inertia. So even if the language designers and package maintainers wanted to make breaking changes, they couldn't, because people would just stop updating. All that's left to do is to drag out the process of this ecosystem rotting away.

Re: Not Your Grandfather’s Perl

#174

Post by cutler »

forgotmypw17 wrote: post #4

With function signatures and state variables added in 5.010, I consider Perl feature-complete and have not really missed anything from it for as long as I've been writing Perl. What I do appreciate that's missing from many other languages and systems is the extreme committment to backwards compatibility. The knowledge that the next minor release won't break existing scripts is underrated, IMO. Solo project with ~23K…

I used to think you had to be a hashref to be blessed but The Damian put me straight on that.

Re: Not Your Grandfather’s Perl

#175

Post by auraham »

csdvrx wrote: post #3

Even on modern hardware with vectorization, the speed of perl is hard to match for stream processing. I write and deploy brand new perl code in 2022 to replace some clunky python and javascript - for real! AMA!

Any chance to make it open source on GitHub?

Re: Not Your Grandfather’s Perl

#176

Post by cutler »

nextos wrote: post #166
fijiaarone wrote: post #142

Earlier quoted context omitted.

What we need from a programming language is to make medium complexity things, at worst, medium difficulty. I don’t care about hard problems, and easy problems.

Erlang/OTP does medium difficulty things, i.e. very large applications with good fault tolerance and QoS, really well. But it's a very different niche. Perl and Ruby scale to mid sized applications quite well, but above that fault tolerance and QoS become hard.

I think with languages like Perl, Ruby and Python you just need a static, compiled language to migrate to at a certain scale, preferably with similar features. Kotlin and Scala seem to be currently the best options for Ruby, Python and OO Perl. For procedural Perl maybe Golang.

Re: Not Your Grandfather’s Perl

#177

Post by jandrese »

int_19h wrote: post #158
jandrese wrote: post #144

Earlier quoted context omitted.

Perl does a kind of half JIT when you start a script. It doesn't compile fully down to native machine code, but it does parse and lex the script to build an internal representation. The code is then interpreted, but since it doesn't have to parse each line again it runs very fast and also you can interpret code on the fly in a variable so you get the best of both worlds.

This has been the usual way to implement interpreted languages for decades; Perl isn't special in that regard. JIT generally refers to generation and execution of native code specifically.

I'm pretty sure bash still interprets line by line because you can mess up a script by editing it while it is executing.

Re: Not Your Grandfather’s Perl

#178

Post by cutler »

Perl enabled me to take a business-owner's disorganised national spreadsheet of teachers, locations and contact details and turn it into a web application, freeing him from fielding phone calls all day and boosting conversions over a period of 15 years. Perl's superb regex handling was essential in extracting and gradually refining the data until it was fit to be entered into a database. From that point on Perl, along with PostgreSQL, literally ran the business while generating opportunities for hosting promotions with bigger companies. Those who (m|kn)ock Perl usually haven't spent a significant amount of time using it to add real value to a business.

Re: Not Your Grandfather’s Perl

#179

Post by barrenko »

senorsmile wrote: post #63
yakubin wrote: post #35

Earlier quoted context omitted.

I’ve had very limited contact with Perl, but for scripting purposes it does seem like the best option, so I intend to sit down to it and learn it better. It looks like a great next step after sed and awk (perl -pe). I love the ability to write terse scripts, reasonable speed for a scripting language and, as you said, backwards-compatibility (such a stark contrast compared to Python).

The "Learning Perl" book from O'Reilly is the best book to do this (and imho is one of the best written programming books).

Yup, I'd almost recommend it to a non-programmer.

Re: Not Your Grandfather’s Perl

#180

Post by barrenko »

ra88it wrote: post #112

When I was about 20, I went to the local Barnes and Noble to find a book about programming. Picked up the O'Reilly Javascript book from around 2000. Had no idea what javascript was, just wanted to learn how to program and trying to pick the most popular language. $40 later, I got home and started reading! Very confusing, the first half of the book covered the language runtime (I think?) and the second half covered th…

Ah Ruby, the only OOP without the stink.
Post reply on HN