Live data from Hacker News

Not Your Grandfather’s Perl

stackoverflow.blog

201–210 of 257 posts

Re: Not Your Grandfather’s Perl

#201
post #176
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.

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

Re: Not Your Grandfather’s Perl

#202
post #172

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…

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

Paint me unconvinced. Python2 is still a thing, 14 years later.

Re: Not Your Grandfather’s Perl

#203
post #96

I don’t really miss perl. I do miss the period when perlmonks was relevant to me. I haven’t really seen a similar community since. Maybe rose tinted spectacles on my part but i learned some really enlightening algorithms on there specifically in text processing and i recall it being a really warm community. Randall Schwarz used to run a podcast that was a total goldmine. Fond memories of listening to that on the trai…

Most of the people who were on perlmonks are still around somewhere. Often with the same or a similar handle. (I added my first initial to mine.)

Actually some still are on perlmonks :)

Re: Not Your Grandfather’s Perl

#204

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…

This is my experience as well. I have a side project in its prototyping state and tried to use typescript in it. The result was exactly what I was afraid of - the first half of a weekend spent on fine-tuning tsconfig and tsserver integration, the second half on type acrobatics and investigating wrong narrowing issues. No code was written that day. I have a decent experience with both typed and untyped languages to see pros and cons of typing and am consciously choosing untyped for the “development” phase.

Re: Not Your Grandfather’s Perl

#205

I skimmed the article looking for a mention of a REPL or a new debugger. Perl is a great language but it lacks these tools. Sometimes I just want to try a couple of lines of Perl code in a REPL, but I cannot. Instead, I need to create a file. Also, when debugging with `perl -d`, I cannot use the Up arrow key to get the previous command. Not a big deal but the coding experience will be significantly improved with thos…

There are several, highly configurable (of course) and usable REPLs.

https://metacpan.org/pod/Devel::REPL https://metacpan.org/pod/Reply

Not to mention the Jupyter kernel: https://metacpan.org/dist/Devel-IPerl

Re: Not Your Grandfather’s Perl

#206
post #200
post #170

Earlier quoted context omitted.

Getting strings to have the right encodings should be easy. On the last Perl codebase I touched it's proven impossible for all practical intents and purposes.

It's markedly easier than with Python, though. Here's a short script that will recode a file with mixed iso-8859-1 and utf8 data into proper utf8: #!/usr/bin/perl use strict; use warnings; use Encode qw( decode FB_QUIET ); binmode STDIN, ':bytes'; binmode STDOUT, ':encoding(UTF-8)'; my $out; while ( ) { $out = ''; while ( length ) { $out .= decode( "utf-8", $_, FB_QUIET ); $out .= decode( "iso-8859-1", substr( $_, 0,…

Thanks for posting the happily ignorant code snippet that I have been waiting for.

The problem is that Perl internally encodes strings as sequences of numbers. Not even sequences of bytes, but sequences of numbers that could either be codepoints or bytes resulting from the encoding of such a sequence of codepoints. ...as a developer you are perfectly free to make this assumption any way you please at any given point in your codebase. It's not even clear that any one of those two is particularly "preferred" at large or a best practice or anything like that.

To make things worse, there is no way to know which is which, i.e. a string itself is happily ignorant about the assumptions that people will/should make about it. And Perl will happily concatenate strings making different kinds of assumptions, or double- or triple-encode them as you please, or decode something that hasn't been encoded in the first place.

This leads to jumbles of numbers that aren't anything in particular. They simply work well enough for sloppy programmers to not realize when they are making mistakes, but badly enough to almost guarantee that encoding errors will crop up on users' screens regularly.

Now, given that this is how the language works, be my guest jumping into a 100k loc Perl codebase that dozens of programmers have touched over a decade, passing around and munging together strings not just within their own codebase, but also using strings stored to and retrieved from elsewhere, in some case places where no one knows anymore where they initially came from or where they will ultimately go to.

Re: Not Your Grandfather’s Perl

#207

I skimmed the article looking for a mention of a REPL or a new debugger. Perl is a great language but it lacks these tools. Sometimes I just want to try a couple of lines of Perl code in a REPL, but I cannot. Instead, I need to create a file. Also, when debugging with `perl -d`, I cannot use the Up arrow key to get the previous command. Not a big deal but the coding experience will be significantly improved with thos…

I think that 'perl -d' needs to have Term::Readline to be installed to provide line editing. Otherwise you could use DDD, which provides an ugly but functional GUI to gdb, and perl -d. Or ptkdb which is better IMO ('perl -d ptkdb', requires the module and Tk).

Re: Not Your Grandfather’s Perl

#208
post #185

Earlier quoted context omitted.

> I'm surprised CPAN is not mentioned. I wonder if it is still active. CPAN is indeed alive and kicking; https://metacpan.org/

The thing is back in the day 35,000 modules on CPAN was a big deal but if you look at https://modulecounts.com that's since been dwarfed by Python/PyPI (398,000), Ruby/Rubygems (173,000), PHP/Packagist (351,000) and JS/npm (2,116,000).

I am not much into JS but I have seen countless jokes about JS/NPM having so many modules. I never understood why JS/NPM ecosystem has so many modules? I guess JS isn't that versatile language.

Re: Not Your Grandfather’s Perl

#209
post #206
post #200

Earlier quoted context omitted.

It's markedly easier than with Python, though. Here's a short script that will recode a file with mixed iso-8859-1 and utf8 data into proper utf8: #!/usr/bin/perl use strict; use warnings; use Encode qw( decode FB_QUIET ); binmode STDIN, ':bytes'; binmode STDOUT, ':encoding(UTF-8)'; my $out; while ( ) { $out = ''; while ( length ) { $out .= decode( "utf-8", $_, FB_QUIET ); $out .= decode( "iso-8859-1", substr( $_, 0,…

Thanks for posting the happily ignorant code snippet that I have been waiting for. The problem is that Perl internally encodes strings as sequences of numbers. Not even sequences of bytes, but sequences of numbers that could either be codepoints or bytes resulting from the encoding of such a sequence of codepoints. ...as a developer you are perfectly free to make this assumption any way you please at any given point…

> Thanks for posting the happily ignorant code snippet that I have been waiting for.

Thank you from being so civil. IMO displaying a badly encoded string beats crashing on a runtime error most of the time. I'd rather see "hôpital" than "Error 500", if you will. Maybe don't think your personal assumptions carry any validity out of your own choices, preferences, or uses.

I imagine the difficulty working with a huge codebase lacking refactoring and maybe even predating utf-8, but where would you be if it was written in Python 2.5 originally?

Re: Not Your Grandfather’s Perl

#210
post #209
post #206

Earlier quoted context omitted.

Thanks for posting the happily ignorant code snippet that I have been waiting for. The problem is that Perl internally encodes strings as sequences of numbers. Not even sequences of bytes, but sequences of numbers that could either be codepoints or bytes resulting from the encoding of such a sequence of codepoints. ...as a developer you are perfectly free to make this assumption any way you please at any given point…

> Thanks for posting the happily ignorant code snippet that I have been waiting for. Thank you from being so civil. IMO displaying a badly encoded string beats crashing on a runtime error most of the time. I'd rather see "hôpital" than "Error 500", if you will. Maybe don't think your personal assumptions carry any validity out of your own choices, preferences, or uses. I imagine the difficulty working with a huge co…

But that's precisely the point: Python 2.5 realized that something was fundamentally broken and the community went through a painful transition process. Transitioning to Python 3 meant getting your house in order where string encodings were concerned.

Any python programmer would tell you: Starting a new project in 2022 in Python 2.5 is professional malpractice.

But that's what the original post seems to be saying: That Perl 5 has somehow managed to fix any of what was fundamentally wrong with it. ...and that couldn't be further from the truth. And people in this thread are saying that maybe they should have another look into Perl 5 as a serious option for starting out a new codebase in 2022. ...and that's a very bad idea.

Sure: If you started out a new codebase in Perl 5 in 2022, there are coding standards you could adopt to avoid getting yourself into a pickle where string encodings are concerned. But without the interpreter helping you out on that front, it'll produce ugly code, and take mental discipline and disciplined code reviewing practices on a team. It's solving a problem that Python solves for you so much more easily and effectively. You could go with Perl 6 / Raku, but why would you? What does it have to recommend it over Python or Ruby, other than a Perl programmer's nostalgia for being a little Perl-like?

You could say the transition from Perl 5 to Perl 6 is just like the transition from Python 2 to Python 3. The difference is: Perl is simply late by at least a decade.

The point that the article is trying to refute, namely that Perl is for dinosaurs, in my mind just absolutely stands.

Post reply on HN