User Experience for non-Perl users

Programming Perl 5
1

I’m currently weighing up the pros and cons of making changes to exercises geared towards object oriented programming, to remove a potential obstacle for people unfamiliar with Perl.

Currently, OOP exercises suggest using a module called Moo. I’d be inclined to call it an industry standard for OO in Perl.

Perl has recently introduced built-in OO features, which are still in development, but sufficiently functional enough for completing any exercise on the track.

If I replace Moo with the built-in functionality, it eliminates all additional dependencies for CLI users, they would have to do nothing more than install the latest version of Perl, or a helper module if that otherwise isn’t possible.

If I keep Moo, there are more resources and guides available for using it, but every CLI user unfamiliar with Perl has to go through the process of either installing a new package or figuring out for themselves an alternative way to build their implementations.

Do you think either of these approaches is more preferable than the other?

1 Like
2

It’s a tough one! As you mentioned, there are prons and cons for both. One big downside to changing the exercises would be that existing solutions would become invalid (I assume they’re not compatible?). Maybe for new exercises you could consider not using Moo?

3

The existing solutions would still be compatible, and Moo would still be supported, its just the stubs given to new users that would change.

The tests are written to be broadly compatible with various OOP modules.

4

Then I think changing the stubs to not use Moo makes sense. I assume that in general people will start using the built-in functionality?

5

But are you forcing people to upgrade their available Perl? A conservative distro like Ubuntu is typically slower to upgrade.

6

I would move toward deprecating Moo but as we go. Like you mentioned, a user that uses a newer version of Perl will have the support, not changes required (except if the tests are requiring something they do not have, such as the Moo package), but hopefully we have avoided that as a dependency of the tests themselves.

At the point that the older version of Perl is deprecated we can then remove the Moo references.

Meta: Can we move this discussion to the Perl category? This does not seem relevant to the Building Exercism CLI category.

7

No, it should still be possible to use older Perls, possibly all the way back to 5.20. 5.40 should be completely seamless, older Perls need to install Test2::V0 and Feature::Compat::Class. 5.40 is not currently seamless due to some stubs using Moo.

8

I like the idea of ​​the new builtin Perl OO system. I’m familiar with Moose/Moo/etc, but I think it’s easier for people to adopt Perl if they can just install the latest package from the distribution and use that.

9

I absolutely love that Cor is being adopted into Perl and have done a lot of experimenting with it, but I’m very conflicted about introducing it as the canonical way to write OO Perl in Exercism.

The fact of the matter, to me, is that most people learning Perl in 2024 and onward are going to see a lot more legacy code than greenfield projects. Legacy code simply will not be using the built-in feature class for many years. I feel that we’d be doing students a disservice by encouraging users to adopt techniques that they won’t actually see in production, while at the same time failing to teach them about existing methods that they will see.

Perl versions is definitely a concern. Debian Stable still only has v5.36, and Testing is likely to go Stable next year, so it is fairly likely to be stuck at 5.40 or 5.42. It is unlikely that feature class will be as complete as other implementations by then, so that could mean at least around 4 years before Debian has comprehensive support. 5.40 just got the :reader attribute and still does not have the :writer attribute (this is in Object::Pad but there’s no guarantee that it will make it into 5.42, I don’t think).

That said, I’m ambivalent about Moo also. If we must use an external module, I might actually lean more towards full-fat Moose instead. I personally prefer to use the more light-weight Moo, but I see Moose more often in the wild, and it is also the one that is most often discussed in books (it is used in Modern Perl, which I think is the gold-standard for Perl books and which is available for free online).

If we are concerned about external dependencies, we could just teach people to bless those references! For most exercises, it would be completely sufficient and given that the setup for Moo objects are already defined in the stubs, the setup for blessed references would be done for them also… People don’t really have to understand what either are doing at a deeper level. I don’t thing that there are any exercises that are dependent upon the advanced OO features which get simplified away by any of the existing modules or by Cor.

I know that a lot of people do not like blessed references, however, I don’t entirely understand why. They build very naturally on simpler Perl concepts (ie. classes as packages, methods as functions, and addressing object data from the blessed references exactly how you would expect to in many other languages: $obj->{'data'}) using just a couple of extra keywords. Moo uses these under the hood anyways, so it is not a bad thing to expose students to things like @ISA being used to track parents, etc., even if they do move on to something more mature for their own projects eventually.

1 Like