Technology

59381 readers

3189 users here now

This is a most excellent place for technology news and articles.

Our Rules

Follow the lemmy.world rules.
Only tech related content.
Be excellent to each another!
Mod approved content bots can post up to 10 articles per day.
Threads asking for personal tech support may be deleted.
Politics threads may be removed.
No memes allowed as posts, OK to post as comments.
Only approved bots from the list below, to ask if your bot can be added please contact us.
Check for duplicates before posting, duplicates may be removed

Approved Bots

founded 1 year ago

MODERATORS

Perl still relevant in 2023/24? (lemmy.ml)

submitted 1 year ago by It0m@lemmy.ml to c/technology@lemmy.world

71 comments fedilink hide all child comments

hi, i was interested if perl is still relevant in this day and age. Perl has been on the decline for a very long time now. Perl 6 (now named 'raku) not being backwards compatible with perl 5 code made the already small perl community even smaller by splitting it in half. A good example is lisp with it's thousands of different dialects.

Is it still worth using or is it bound to legacy software forever? Like cobol.

you are viewing a single comment's thread
view the rest of the comments

[–] Kazumara@feddit.de 4 points 1 year ago (3 children)

unexpected bits of flexibility

The worst one I stumbled across while reading a colleagues script was the three separate namespaces for symbols of type scalar, array, and hash.

[–] dan@lemm.ee 1 points 1 year ago* (last edited 1 year ago) (2 children)

You mean the fact that you can have a hash called %foo, an array called @foo and a scalar called $foo all at the same time? I agree that's a weird choice and there's potential for insanity there, but it's pretty easy to just not do that...

20+ years of Perl experience and while Perl has a load of idiosyncrasies that make it harder to work with than other languages, I don't think that particular one has ever caused a significant problem.

[–] Kazumara@feddit.de 1 points 1 year ago* (last edited 1 year ago) (1 children)

You mean the fact that you can have a hash called %foo, an array called @foo and a scalar called $foo all at the same time?

Yes, exactly. Those definitions aren't clashing, so they must have separate namespaces.

it’s pretty easy to just not do that…

I wouldn't do that either, but my colleage apparently did. So far I'm having a harder time reading perl than writing it.

[–] dan@lemm.ee 1 points 1 year ago

The way it works is that there's a symbol table entry for "foo" which has a slot for a hash, scalar, array, glob, etc.

That leads to some super weird behaviour like, for example, if I declare a scalar, hash and array as "x":

$x = "sy";
%x = (foo => "mb");
@x = ("ol", "s!");

You can access them all independently as you're aware:

say "x: ", $x, $x{foo}, @x; # Outputs:  x: symbols!

But what's really going to bake your noodle is I can assign the "x" symbol to something else like this:

*z = *x;

..and then the same thing works with z:

say "z: ", $z, $z{foo}, @z; # Outputs:  z: symbols!

Oneliner if you want to try it:

perl -E '$x = "sy"; %x = (foo => "mb"); @x = ("ol", "s!"); say "x: ", $x, $x{foo}, @x; *z = *x; say "z: ", $z, $z{foo}, @z;'

Congratulations! You now know more about one of Perl's really weird internals than I'd wager most Perl programmers (I have literally never used any of the above for anything actually productive!)