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

211–220 of 257 posts

Re: Not Your Grandfather’s Perl

#211

Post by Karrot_Kream »

duskwuff wrote: post #108
theonething wrote: post #98

Earlier quoted context omitted.

are Perl function signatures the PHP/Python equivalent of type hints?

This may shock you, but: historically, Perl functions did not have declared arguments. Like, at all. The function just got arguments implicitly passed to it as an array (@_), and parsing that into individual variables was up to the function -- so most functions would start like this: sub myFunction { my ($self, $arg1, $arg2) = @_; ... } Or, in older code, you might even see this: sub myFunction { my $self = shift; #…

Lol there were places, perhaps times, where Perl subroutines would "shift" as they go along, to create a prose effect. Sometimes you'd get a comment about it, but mostly not. Maddening for any longer function.

Re: Not Your Grandfather’s Perl

#212

Post by teddyh »

wazoox wrote: post #209
gyulai wrote: 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…

> I'd rather see "hôpital" than "Error 500"

The debate between weak typing and strong typing is as old as the hills. But in much of the modern era, strong typing, of which Python is an example, seems to have decidedly prevailed.

Re: Not Your Grandfather’s Perl

#213

Post by arunix »

wazoox wrote: post #207
auraham wrote: post #109

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

This is what I do to get that functionality:

    rlwrap perl -dee
https://linux.die.net/man/1/rlwrap

Re: Not Your Grandfather’s Perl

#214

Post by cestith »

csdvrx wrote: post #29
cestith wrote: post #12

Earlier quoted context omitted.

If you need new code you write today to run on 20 year old systems, don't use the newer features. Perl 5.36 is backwards compatible to code written for Perl 5.6 after all. If you need 20 year old code to run on new machines, the same thing occurs - you hand it to a recent Perl 5 and it works. Compare and contrast the last 20 years of PHP or Python.

> If you need 20 year old code to run on new machines, the same thing occurs - you hand it to a recent Perl 5 and it works. You're only noticing half of the picture. If you want to write code that'll still run in 20 years, do the same.

Are you saying that in 20 years they'll have removed all the features added in the last 20 years?

Re: Not Your Grandfather’s Perl

#215

Post by bluedino »

wistlo wrote: post #14
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!

I'm working in Windows (employer's choice) and need to process some huge data files on the desktop. Perl (Strawberry Perl for Windows) is much faster than native Powershell (or CMD) scripts. A few Perl one-liners and I have 2 GB processed in a couple of minutes. Big fan of Perl here.

I don't think you could be slower than Powershell if you tried.

Re: Not Your Grandfather’s Perl

#216

Post by LudwigNagasena »

wruza wrote: post #204
MobiusHorizons wrote: post #97

Earlier quoted context omitted.

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 se…

I agree with the first part (I generally hate the devops situation with JS, TS, nodejs, modules, etc). But I don't understand the part about type acrobatics. TypeScript's typing is robust to the point of being Turing complete, so you can express things that are generally not expressable in your typical typed language. And if TypeScript cannot pin down your types, it is probably a code smell. But you can revert to "any" at any time anyway, if you feel compelled to do some unidiomatic js trickery.

Re: Not Your Grandfather’s Perl

#217

Post by collyw »

CraigJPerry wrote: post #65

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…

I miss perlmonks as well, now that I do mostly python. It was like stack overflow, except discussions were encouraged. It gave you far more understanding than copying a SO answer usually does.

Re: Not Your Grandfather’s Perl

#218

Post by anthk »

jandrese wrote: post #141
anthk wrote: post #16

Earlier quoted context omitted.

Perl's bindings for Win32 and OLE are amazing.

While you can use them, I do not recommend it. The problem is when you want to convert a script into an EXE so not everybody has to install Strawberry Perl. Apparently some viruses are written in Perl because Windows Defender flags any exe you build as a virus and deletes it. Also, changing the application icon doesn't work, so you're always distributing a Camel app. It's a shame too because as you say the Win32 API…

Not a Perl issue, but a Windows Defender one.

Re: Not Your Grandfather’s Perl

#219

Post by rrwo »

lmm wrote: post #119
rrwo wrote: post #113

Earlier quoted context omitted.

Badly-written Perl code from the 1990s is not the fault of the language. It's the fault of the non-programmers who read "Learn Perl in 2 hours and become a millionaire" books, had a massive s*t on a keyboard and started a business with it

And yet those non-programmers who instead "read "Learn Python in 2 hours and become a millionaire" books, had a massive s*t on a keyboard and started a business with it" tend to have ended up with something significantly less horrible to maintain.

It really has to do with the "programmer" and not the language.

Those learn to program and make fast money books were a product of the 1990s, and they appealed to people who cared more about making money than about producing any kind of product.

For example, I once had to fix some code that was supposed to delete files that were sitting in a directory for more than a week.

Rather than do something sane and simple, like look for files where the mtime was less than a cutoff and delete them, it looked for files where the absolute difference between the age and 7 days ago was 0. So it had the side effect of deleting things that were 7 days old, or were less than a day old. It also missed things that happened to be older than 7 days old.

(And nevermind that it was written because people couldn't bother to figure out why files were stuck in the directory.)

The company's codebase was filled with nonsense like that.

The person who wrote that would not have written anything better in Python or anything else.

But from the outside it worked well enough and they made a lot of money.

Re: Not Your Grandfather’s Perl

#220

Post by liveoneggs »

TimTheTinker wrote: post #40
latchkey wrote: post #34

Earlier quoted context omitted.

Perl needs backwards compatibility given the `write once, read never` nature of the syntax. Imagine trying to upgrade this to some new syntax... https://github.com/schwern/AAAAAAA

That looks more like write-only naming... but the syntax itself isn't bad at all. Here's the main module: https://github.com/schwern/AAAAAAA/blob/aaaaaa/aaa/AAAAAAAAA...

gross. Look at all of those non-'A's
Post reply on HN