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

241–250 of 257 posts

Re: Not Your Grandfather’s Perl

#241

Post by int_19h »

jandrese wrote: post #177
int_19h wrote: post #158

Earlier quoted context omitted.

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.

bash (and other shells) are special in that regard, because they use textual substitution so heavily - to pass arguments etc.

But Python, Ruby etc all compile to bytecode, and have always done so as far as I can remember.

Re: Not Your Grandfather’s Perl

#242

Post by otabdeveloper4 »

gyulai wrote: post #239
otabdeveloper4 wrote: post #227

Earlier quoted context omitted.

> Transitioning to Python 3 meant getting your house in order where string encodings were concerned. They renamed "string" to "bytes" and "unicode" to "string". (And still managed to make file and path encoding broken, and added a few bugs in the process.) No, nothing about Python 3 is "in order". That was just your Stockholm Syndrome speaking.

> Renamed "string" to "bytes" and "unicode" to "string". Either this is hyperbole, or you're quite mistaken on the particulars there.

The particulars don't matter here.

P.S. Programming Python since Python 1.3

Re: Not Your Grandfather’s Perl

#243

Post by gyulai »

uhtred wrote: post #229
gyulai wrote: post #190

So, this is on the stack overflow blog. And Joel Spolsky famously thinks that to rewrite a codebase from scratch is the "single worst strategic mistake that any software company can make" [1]. I wonder if this is how you end up being a Perl user in 2022. [1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Eh? He's not wrong. for any serious (in production and actually being used by paying customers) software it _would_ be crazy to rewrite a codebase. I can't think of a compelling reason to. For the record, I became a perl user (for fun!) in 2022 because I was attracted to the text processing capabilities, the awesome documentation, the baked in regex handling, the way it's so integrated into unix culture, the fact tha…

> Eh? He's not wrong.

It's wrong when stated as a blanket statement like that. It depends on the particulars of the case.

I've worked in a company that's taken this dictum as gospel and took it to its absurd extreme where refactoring of any kind was forbidden.

I would explain some dark corner of the codebase and everybody would basically agree that it was in bad shape. I would then explain what I wanted to do about it and people would say "Is that a refactor you're suggesting?" in a tone of voice that would be more appropriate when saying "Is it killing babies that you're suggesting?"

As coincidence would have it, that was a Perl shop. So I speak from experience. And that experience has left me somewhat scarred.

Imagine working on a codebase where any mistake you ever make you're just stuck with. And it's not just your mistakes, but other people's as well. And the mistakes just pile up and pile up and start interacting with each other in nasty ways and there's just no way out. I love being a programmer, but there is little in the world that I hate more than having to be a programmer under such circumstances.

What's more is that the financial benefit of not refactoring is a benefit that usually accrues to those who are in power in a company and who don't have to touch the codebase, whereas the psychological cost of not refactoring accrues to those who have no power who are forced by the others to wallow in the muck. -- That's the thing that Spolsky consistently just doesn't get. He consistently represents the one-sided view of someone "in power".

As a programmer under such circumstances, it really makes no sense to throw away your psychological wellbeing so that your company's owners can make more money, just like it doesn't make sense for a miner to give himself lung cancer so that the owners of the mine can make more money.

Conversely: If you're the owner of a software company (or mine, or whatever) you should partially think of refactoring as an employee benefit that will pay for itself through increased productivity. It's a point that's very convincingly made by Tom DeMarco in his book "Peopleware" [1]. Asking your employees to dial down the quality of their output so you can realize cost savings almost never makes sense when you take into account the human side of the economic equation. You'll demotivate them and the losses in productivity will outweigh the cost savings.

[1] https://www.audible.com/pd/Peopleware-Audiobook/B09WDR3P3V?a...

Re: Not Your Grandfather’s Perl

#244

Post by gyulai »

otabdeveloper4 wrote: post #242
gyulai wrote: post #239

Earlier quoted context omitted.

> Renamed "string" to "bytes" and "unicode" to "string". Either this is hyperbole, or you're quite mistaken on the particulars there.

The particulars don't matter here. P.S. Programming Python since Python 1.3

...I agree, it's pretty obvious that this thread has gotten to the point where particulars don't matter any more.

As I recall, "bytes" didn't exist in Python 2.5 but were brought in in later versions of Python 2.6 and Python 2.7 when Python 3 already existed to provide a more continuous upgrade path for those still on version 2. You could get in the habit of using "unicode" and "bytes" and then the switch to Python 3 would be this "just renaming" thing. ...but that was the end point of the process, not the starting point.

I'm not an unreflected Python fanboy. I don't like many of the new developments since version 3.5. But I've spent 2003-2018 with Python as my main language, and 2018-2022 being forced to use Perl 5. And that has left me with the impression that Python fixed pretty much all of what was wrong with Perl 5 in a way that the Perl-community itself never managed and doing Perl 5 instead of Python 3 in 2022 is basically all downside, no upside.

I also admire how well the switch from Python 2 to Python 3 was executed, compared to how poorly Perl is doing in the switch to Perl 6.

I predict that the Python community is going to fall apart over the next 10 years over feature creep and losing its identity, trying to be all things to all people, with people subsetting it in different ways to get to a sane subset of the language, similar to how people are doing with C++.

Re: Not Your Grandfather’s Perl

#245

Post by uhtred »

gyulai wrote: post #243
uhtred wrote: post #229

Earlier quoted context omitted.

Eh? He's not wrong. for any serious (in production and actually being used by paying customers) software it _would_ be crazy to rewrite a codebase. I can't think of a compelling reason to. For the record, I became a perl user (for fun!) in 2022 because I was attracted to the text processing capabilities, the awesome documentation, the baked in regex handling, the way it's so integrated into unix culture, the fact tha…

> Eh? He's not wrong. It's wrong when stated as a blanket statement like that. It depends on the particulars of the case. I've worked in a company that's taken this dictum as gospel and took it to its absurd extreme where refactoring of any kind was forbidden. I would explain some dark corner of the codebase and everybody would basically agree that it was in bad shape. I would then explain what I wanted to do about i…

I'm not against refactoring at all! Refactoring is good! (Is Joel Spolsky against it? That _would_ be crazy). Refactoring in my opinion is very different to rewriting an entire codebase/application (which I assumed you meant - perhaps incorrectly?)

Re: Not Your Grandfather’s Perl

#246

Post by forgotmypw17 »

gyulai wrote: post #240
forgotmypw17 wrote: post #237

Earlier quoted context omitted.

To me, having to get my "house in order" without asking for it is basically non-consensual changes by the developer, and I think that is abusive. With humans, my response to abuse is distancing myself from the source of the abuse, and with technologies it is no different. Python is very popular, and I'm actually learning it right now, but I would not write anything important in it for another 20 years, since they jus…

> To me, having to get my "house in order" without asking for it is basically non-consensual changes by the developer, and I think that is abusive. If you used Python 2 in a way where encoding errors wouldn't be an issue, and if you used the Python 2 to 3 conversion tool that they made when they released Python 3, then in most cases you didn't have to do any work beyond that. ...if however you used the tool and sudde…

> It's more like a five-star restaurant asking you to please put on a shirt if you show up there in a bathing suit.

But in this case, the restaurant had previously told me that a bathing suit is OK, and I've been showing up in a bathing suit for years.

They don't owe it to me to accommodate me, but they have just proved themselves unreliable, and I won't be going to that restaurant again, since they ruined my plans for the night.

Re: Not Your Grandfather’s Perl

#247

Post by forgotmypw17 »

gyulai wrote: post #172
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 tak…

It doesn't really matter to me whether it is on purpose or not.

All I know is that I can depend on my Perl scripts running a year from now, and I cannot do that with Python.

It feels alive and well to me in that sense, while the stability and dependability of Python does seem to rot pretty quickly.

Re: Not Your Grandfather’s Perl

#248

Post by anthk »

kal247 wrote: post #234
anthk wrote: post #20

Earlier quoted context omitted.

Perl is the Unix utilities' replacement for Windows. It can do awk/sed in one place. What I miss it's a "strings(1)" replacement for Perl.

There's a "strings" implementation in the PerlPowerTools : https://metacpan.org/pod/PerlPowerTools

TIL. Good addon for w32 perl users.

Re: Not Your Grandfather’s Perl

#249

Post by nextos »

singingfish wrote: post #201
cutler wrote: post #176

Earlier quoted context omitted.

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.

Rust gets large amounts of inspiration from perl so don't forget that one.

Wikipedia quotes Ruby as an influence, but not Perl, citing this source: https://doc.rust-lang.org/reference/influences.html

Still, Perl might have influenced Rust via Ruby. Otherwise, do you have a reference for Perl's direct influence on Rust?

Re: Not Your Grandfather’s Perl

#250

Post by dragonwriter »

cutler wrote: post #176
nextos wrote: post #166

Earlier quoted context omitted.

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.

Python has a number of similar, static, compiled languages that are embeddable in Python code (notably Cython and taichi).
Post reply on HN