Hacker News Reader

Comment by DangerousPie | Hacker News Reader

As an outsider who hasn't written perl code in more than a decade this all makes a lot of sense to me.

I think of Perl 5 as something "outdated" because I know that there is a language called Perl 6. When I think of Perl 6 I am not particularly interested in it because I assume it's more or less the same as the "old" Perl, which I don't use and didn't really like back in the day.

Renaming Perl 6 to something else would help with both of these problems.

That said, I wonder how much damage has already been done at this point and whether renaming it now will still be very useful. There are a lot of references to Perl 6 out there already, so convincing people that Perl 5 is the latest version of Perl again will be tough.

View on HN

If Perl 6 is renamed, Perl 5 could skip to Perl 7 in the next version to avoid confusion.

Like PHP

From what I gathered, I believe that Perl 5 would transition to the minor version number much like how Java did (1.7 -> 7).

That feels like the best way to save the brand. Cut a Perl 7 release concurrently with the Raku v1 release, and just get on a regular schedule of incrementing the version every 6 or 12 months.

Edit: Okay, starting from the minor version instead of 7 sounds like an even better approach.

Not exactly the same situation, but this reminds me of Angular. Angular 2 was a marketing debacle; the official stance of "Angular != AngularJS" is stubborn and nonsensical — any idiot can see that they're confusingly similar, and if they're supposed to be different then why is the first Angular release version 2.0.0 instead of 1.0.0? (I personally think they should've called it Circular.)

In any case, I think the way they moved forward (with "Angular 2" no longer being a thing, except in reference to that specific release) was ultimately the best way to salvage the situation; given its recovery and growth since then I'd say Perl could take some lessons from it.

Yes for Perl 5->7, but it would be good to have a solid-ish feature change or addition to justify the jump and promote it.

When I see that we still don't have a simple "is item 'in' set" operator, 12 (?) years after the introduction of smartmatch and 5 or 6 years after its half-retraction...

(Well, we still have no sets either :-), let's talk about lists/arrays...)

When I see we still don't have a clean function parameters declaration system (better than the mess with prototypes and signatures)...

When I see that constants, enums, simple structured data (C-like-ish structs) still have to be simulated with functions and/or objects and the weight which comes together...

...On one hand, it gives a set of features that could be used to justify a jump. On the other hand, if these basic features has never been deemed useful by the language leaders until now (that is, during a couple of decades), I have little hope they will change their minds.

There is little strain on the "language leaders" (that would be barking up the wrong tree, anyway) as the features you named with one exception are already done and have been available for years.

• "is item 'in' set" operator: https://metacpan.org/pod/Syntax::Feature::In

• sets: https://metacpan.org/pod/Set::Object

• clean function parameters declaration system: https://metacpan.org/pod/Kavorka::Manual::Signatures

• constants that are not functions/objects: https://metacpan.org/pod/Const::Fast

• enums that are not functions/objects: ?

• structs that are not functions/objects: pack/unpack, for explanation see https://metacpan.org/pod/Convert::Binary::C

I feel like this is what Perl11 could end up being if it actually becomes a version of Perl instead of a kind of collection of Perl5 descendants: http://perl11.org/

Just keep perl 5 running forever please. I don't want to have to re-write the perl I wrote in 2001 that is still running in production. I wish now I had never started writing stuff in Python 2.

There's no saving Perl 5; it's a legacy language in legacy maintenance mode for good reason.

Renaming Raku/Camelia could help that language quit being saddled with the perception that it's also legacy in the same way, though.

What good reason is that?

I still use Perl 5 for some tasks, but my rule-of-thumb is that if I anticipate wanting to use references, I will go elsewhere.

I suggest and use the opposite rule of thumb, "always use references". It tends to simplify things. Python writes the same rule into the language itself.

When I used it for larger tasks, I did the same. Nowadays, the consequence of my rule is that Perl 5 sits in my toolbox between Awk and Python.

> but my rule-of-thumb is that if I anticipate wanting to use references, I will go elsewhere

Why? References are not scary and they work just like in any other language -- they are simply a memory address that points to another value stored somewhere else.

The implementation is not the issue; it is the awkward and fussy syntax. It is not a show-stopper -- I coped with it for a while -- but there are better alternatives.

The happy-path syntax is pretty straightforward. I wonder if you're under the impression like some that you need to use the arrow syntax or prefixing dollar for every reference, and not just the first? That's not the case. e.g.

    my @a = (
      { first=>1, second=>"b", another_ref=>["y"] },
      { first=>1, second=>"b", another_ref=>["z"] },
    );

    say $a[0]{first}; # Outputs 1
    say $a[1]{another_ref}[0]; # Outputs z
    
    my $a2 = \@a; # top level is a reference too now
    say $a2->[1]{another_ref}[0]; # Outputs 1, arrow only needed at top level
    
    # The following are alternate syntax that I find unnecessary and better left alone (and most do)
    say $a2->[1]->{another_ref}->[0]; # Outputs 1, explicit, entirely unneeded because it's unambiguous without extra arrows
    say $$a2[1]{another_ref}[0]; # Outputs 1, extra prefixing $ dereferences first level ref

Personally, I'm happy with a single arrow that lets me know if I have a reference or not. References are important, because they denote that this data may be accessed elsewhere as well, so I'm happy to have a small reminder. Inner level references needing a bit of care if they are copied is somewhat normal though, most non-toy languages have some concept of deep or shallow copying.

I rest my case (it is a personal preference, anyway.)

Fair enough. I did go a little overboard in the name of completeness. IT just boils down to actually understanding what a reference is in Perl (which is something that needs to be done for anything non-amateur), and then realizing there's one -> or not depending on if it's a reference (and doing the wrong thing will fail, not do weird stuff).

Personally, I like that it forces you to be aware that this data structure is likely in use somewhere else as well, and your changes may not be local (which is true of deeper levels regardless).

Off the top of my head:

1. CPAN was great 20 years ago, but it's a joke compared to modern dependency management systems.

2. Functions don't have explicit parameters, and still shift off of @_. (This can be kind of a catch-all for all the "things that are useful for scripts, but suck for programming in the large" design decisions in Perl 5, because I honestly don't remember all of them at this point.)

As an active perl5 programmer, what do you mean by (1)?

To this day, I've seen package management systems for many languages, and none I've seen has been as good as CPAN in terms of

(1) Consistent place for distribution + documentation (cpan.org/metacpan.org)

(2) Automated testing on a wide variety of platform and configuration (cpantesters.org)

(3) CPAN has as standard for declaring dependencies in packages, but a newer "cpanfile" may be more akin go "modern" dependency management. Perl has also had a way of 'use Package $version' right in the source code for ages.

(4) the command "cpanm Package::Name" (or even the older "cpan Package::Name") almost always results in figuring out whatever distribution needs to be installed, even if the distribution is named differently from the package name.

I don’t know where you’ve been looking, but none of that is particularly interesting or new at this point.

I worked with Perl daily and find CPAN even more of a wasteland than NPM. The average package there hasn’t been updated in a decade and has ancient dependencies to match; takes months / years for clients to be written for new tech.

Don't get me wrong, I'm not disputing that the existing collection of modules on CPAN is languishing, but specific point is that the infrastructure behind CPAN + module distribution is unparalleled by anything I've seen elsewhere.

What's wrong with a package not being updated for 10 years?

Languages like perl--like common lisp, and c--are Stable. They change, some, but you can count on old code working. If a 10-year-old package Works, what reason is there to update it? I wrote a c library which has seen no updates in about 2 years--because it doesn't need them. It already does everything I need it to do.

I'm not talking about the 'reached perfection' case. In ten years the language, standards and it's patterns, underlying libraries, hardware, performance, all change. There is also no value in having a working, stable implementation of say, md5 when the entire world has moved on.

Often I'll just not find the library I want since nobody using that tech is actually writing Perl. For example, complete lack of a working GraphQL package until late 2017.

CPAN search in particular is unbelievably bad. The first result for 'Postgres' is a package last updated in 1998 (not joking), try to find a usable driver here: https://metacpan.org/search?q=postgres. Even the widely used DBI package has last seen an update almost a year ago.

It is pretty unfortunate that so many people used "PostgreSQL" and "Postgres" in their module name and DBD::Pg didn't, so it gets ranked lower for those queries. But ranking is a hard problem when there is no curation. The MetaCPAN team does want to improve this if possible.

As for DBI, it's definitely in the "stable" category and isn't trying to keep up with anything; the DBD::Pg driver though was last updated this month.

I'm sorry your initial search for a term didn't immediately give you what you're looking for, but the database layer of Perl is very mature, and if you looked at the docs for DBI, you would see that it uses drivers in the DBD namespace, and if you search DBD, postgres is in the first few results, under DBD::Pg. Just like NPM, having a word in your module namespace or description is probably not always very well correlated to module quality or whether it's actually related to that term, so a bit of active research is best to determine what should be used. Then again, I'm not sure NPM is known for providing mobile namespaces that allow third party modules to interact well in a pluggable way, which is quite common on CPAN.

I would love to see a upgrade to cpan able to handle names converted to lowercase internally. To remind that you must write "use MymoDuleSQL" instead "use myModuLeSqL" can become pretty frustrating for my tired eyes.

This would be a pretty difficult change. Aside from backwards incompatibility, module names are both filesystem lookups and package stash lookups, and in most cases both of those are case sensitive, and it's entirely possible for valid programs to use two modules that only differ in case - at best I could see a warning that searches for a "did you mean?" but that sounds slow.

> Aside from backwards incompatibility

Isn't Perl 6 already backwards incompatible?

> module names are both filesystem lookups and package stash lookups

>> names converted to lowercase internally

Converting names to lowercase internally fixes this.

> it's entirely possible for valid programs to use two modules that only differ in case

Many people (myself included) would see this as a mis-feature not worth saving.

This thread was regarding Perl 5.

1. Carton 2. Function::Parameters, experimental core signatures

Why, after 20 years, are signatures still experimental?

Unfortunate realities of 1) the difficulty of working on the Perl codebase combined with its unpopularity leading to few being both qualified and motivated for such a task, 2) a lack of corporate backing or visionary design purpose driving such features in the language, thus 3) being implemented almost entirely by one individual who had a long period of demotivation and sickness.

And regarding 2): Signatures have been in core for several years now, you just need to turn it on. And for back-compat reasons it’s uncommon in CPAN distributed code.

> CPAN was great 20 years ago, but it's a joke compared to modern dependency management systems.

Modern dependency management systems (at least for language-specific packages) still don't hold a candle to CPAN, IMO. The namespace structure alone is something that's sorely lacking in pretty much every other language-specific package system. I'm glad Perl6 is (finally) gravitating back in that direction (though the prior system of "let's just pull from a bunch of GitHub repos" was still better than 91% of other languages' dependency/package/library/module/plugin/etc. installation approaches, or at least so I felt, having used a lot of such languages).

> Functions don't have explicit parameters, and still shift off of @_

I don't see anything fundamentally wrong with this. It's different from other languages, but not necessarily bad (again: IMO). It makes it easier to reason about things like varargs without needing special syntax for it.

The class system is similarly deconstructed (i.e. you explicitly "bless" arbitrary data structures instead of relying on the language to automagically do something behind the scenes), and I appreciate that explicitness.

---

Like, I find it kinda interesting that the two things you cited as "bad" are also two things I very strongly like about Perl. Different strokes for different folks, I guess.

> 1. CPAN was great 20 years ago, but it's a joke compared to modern dependency management systems.

How so? I use npm/yarn daily and think they are mostly giant insecure playgrounds for teenagers with too much time on their hands. Browsing through node_modules on a large project is enough to make you give up software development and take up heavy drinking. Half the code I see in node_modules wouldn't pass a PR review at my own company. Yet we still depend on it daily.

> 2. Functions don't have explicit parameters, and still shift off of @_.

Never been a problem in my experience. The expected arguments are generally at the top of the sub. You must really not like functional programming then, with heavy use of curried functions and whatnot.

The bigger problem is with passing around an %options hash, and this is true of JavaScript as well, is that the keys can be easily mistyped leading to bugs. Not even TypeScript fixes this (because developers are generally horrible about defining types, which have to be defined perfectly).

To the second point, named parameters as implemented by Function::Parameters do provide this checking if you want it to. Named parameters was a planned feature for core signatures and hopefully it will have similar functionality.

1. Absolutely my experience. NPM is pain.

2. Whether you go positional or use an options hash, you still need to carefully unpack your args at the top of the subroutine. And do it consistently. There are a ton of libraries to help with this, too.

The most important thing is to pick a house style and do it everywhere that doesn't need to be different.

I still use Awk, and when that gets bigger Perl comes in. Nothing wrong with it!

The current state of Perl 5 for Python fans:

----

Perl 5: I'm not dead!

TIOBE: 'Ere! 'E says 'e's not dead!

Internet: Yes he is.

Perl 5: I'm not!

TIOBE: 'E isn't?

Internet: Well... he will be soon-- he's very ill...

Perl 5: I'm getting better!

Internet: No you're not, you'll be stone dead in a moment.

TIOBE: I can't take 'im off like that! It's against regulations!

Perl 5: I don't want to go off the chart....

Internet: Oh, don't be such a baby.

TIOBE: I can't take 'im off....

Perl 5: I feel fine!

Internet: Well, do us a favor...

TIOBE: I can't!

Internet: Can you hang around a couple of minutes? He won't be long...

TIOBE: No, gotta get to Reddit, they lost nine today.

Internet: Well, when's your next round?

TIOBE: Next year.

Perl 5: I think I'll go for a walk....

Internet: You're not fooling anyone, you know-- (to TIOBE) Look, isn't there something you can do...?

Perl 5: I feel happy! I feel happy!

----

But seriously, Perl 5.30 just came out in May. It's not dead yet.

TIOBE is not a relevant barometer, it's just the number of searches and hence a noisy metric. Look at https://www.tiobe.com/tiobe-index/. It indicates that the popularity of C and Java halved between 2016 and 2018 and then made a dramatic recovery, doubling in less than a year. It would be absurd to suggest that there was a real world change to the usage/popularity of these two languages corresponding to this.

A better metric is the activity on stackoverflow and github, which is what RedMonk use. That's much more stable. Java and C have both been #2 and #9 since 2015. https://redmonk.com/rstephens/files/2019/03/toptwenty-2019-0...

Even then I'm surprised to see Lua fall off the table, and Go's stagnation seems kinda odd.

Given how much lua is used as an embedded language in Games, Databases, Servers, etc. I feel I've only seen it's usage increase.

Go I can see as "appearing more popular then it is due to HN" but even then I feel like clis/networking tools have been using Go more and more.

Its usage has increased, but so has the usage of other languages. Its drop in popularity is relative to its share of all users.

If Alice has two apples and Bob has three apples, Bob has 60% of the apples. But if Alice gets four more apples and Bob only gets one, Bob has only 40% of the apples, despite having more than he did before.

It's the same with TIOBE's popularity index.

Reply on news.ycombinator.com