Please not yet-another-oo-system, let's support frameworks

I'm very keen to be actively deprecating and removing syntactic oddities that folks should already be prohibiting via good perlcritic policies (i.e linting) hopefully in their editors and CI pipelines.

And standard perl is a good way for code bases to prepare for the future and derive real benefits right now. Both build on the meritocracy approach of CPAN.

It is that meritocracy that brought us the object frameworks Moose (which people seemed to feel was too big) and then Moo+Type::Tiny (which people seem to feel is about right). There are many other frameworks (object systems) which perl's minimalist internal object functions enable people to write, if one of them strikes a better balance of trade off's then there is nothing to stop it supplanting Moo as number one.

In ECMAScript (javascript) / Node.js there is a similar pattern with jQuery and now React, Vue, and Angular. Without weighing in on their various trade-offs, they are very much akin to Moose and Moo, although they add much more which might make them more analogous to Mojolocious. Hold that thought.

If you're going to write something in PHP you are also nowadays going to use a framework. Laravel comes highly recommended and sports an inviting website. There's also Symfony, Codeigniter, Zend is still around, FuelPHP and many others. People code in these frameworks not in naked PHP.

Ruby on Rails is similar story. People came to Ruby because they wanted all the benefits of RoR (and seem to be leaving because it's now seen as too heavy).

Returning to Perl, in the 90's people came to Perl largely via a framework that made cgi-bin more bearable. It was the RoR of the 90's.

In Perl today I see people most excited about Mojolicious. It's batteries-included approach seems to have sidelined Catalyst and Dancer. It's sufficiently modular that non-web applications are building on it (Hello Mojo::TFTPd) and it's paving the way for async/await which is very vogue right now.

If you're coming to Perl for the first time you are probably coming to Perl via Mojolicious and likely aren't doing naked OO you are doing Moo.

It's interesting to realize that C, C++, Perl, Python, Ruby, R, Java, PHP, and Javascript are all over 20 years ago. C is almost 50 years old and it's #1 on TIOBE still. For the most part they popped up in the 90s (C# was 2000). The youngest language in TIOBEs top 5 is 20 years old. Top 10? still C# at 20. Every kid going to college is younger than the top 10 TIOBE languages.

If you're coming to C you're probably coming via GTK or similar. i.e. a Framework.

The game in 2020 is Frameworks.

Let's not fool ourselves in to thinking that yet another object system "but this time it's in the core" will have much impact. Which is not at all a criticism of the syntactic merits, rather i make a critique based on strategy. Let's show up for the right game at least.

My observation is that jQuery and Moo where/are successful because they enabled the entire community. It didn't matter if your company forced an ancient browser on you, or if your LTS distribution has an ancient system perl. ECMAscript evolved as a result of jQuery which was updated to take advantage of them if they where available.

Let's do that.

Let's put new stuff in Perl 7+ with an impact that is multiplied via the frameworks that we already use now so they can be better.

Additionally, let's also move stuff we love in to Core perl or perl itself. Stuff that's been in everyone's toolbox for years. Here's some ideas in no particular order.

  • Syntax::Keyword::Try - hopefully you're already using this over Try::Tiny. Let's move it all the way in as part of Perl itself.
  • Syntax::Keyword::Gather - another no brainer to go all the way in to perl
  • Hash::MultiValue - probably not as is, but let's explore it. Plack uses this, so everything uses it
  • Future::AsyncAwait - it's not ready yet, and it is very "me too" but its a nice paradigm even if personally i think "async sub" could be contracted in to one tbd keyword
  • Something like namespace::(auto)clean but built in.
  • The type keyword from cperl. It's tiny, its fast, it very natural
  • Carp::XS or as builtin?
  • Should Net::Time, Net::FTP, Net::NNTP, Net::POP3 and Net::SMTP really be in Core perl?

Related reading "Old Code Gets Younger Every Year"


Dean -- curious to know whether you think standard perl would be better if renamed to be higherstandard perl.

If I'm understanding it correctly, the idea is to prevent the developer from using certain Perl syntax that is accepted by the perl interpreter. I'm thinking that "standard" implies everything that comes standard with Perl. "higherstandard" seems to connote that it's a subset of the standard syntax, and is "higher" in the sense of being a better set of rules (because a program that's written so as to use only that syntax is able to be consistently and reliably parsed using Guacamole and even other languages).

use readable::code;

> The game in 2020 is Frameworks.

I agree completely. In fact I'd argue that it's always been the game. People choose language X or Y because of pre-built libraries and frameworks, and not the language itself. PHP and Wordpress/Laravel, Ruby and RoR, C# and Unity, Kotlin/Android, Swift/iOS, etc.

I'm coming back to perl after a few years hiatus not because I'm excited about some new feature in 5.[23]\d (although many are appreciated) or another object system, or because I care about how the homepage looks, but because of Mojolicious -- I was looking for a web backend framework for my startup. I looked across Python/Javascript/Ruby/PHP/C# and found that Mojolicious is as good or better than any of them.

This partly reminds me of why I learned Perl in the first place -- it was from a book called "Minimal Perl" which laid out Perl as a replacement for awk/sed/grep. In that case, "command line" was the killer framework/application that sold me on the language. This time, it's web development and Mojo.

We're in agreement about the wisdom of prohibiting the thorny parts of the language in order to enable the reliable parsing that's needed for IDEs (such as refactoring) that would be enforced by Sawyer X's Guacamole module. You also called that part a "sane baseline".

I like either of those descriptions better than "use standard."

To me, the term "use standard" says "use every part of the language that comes standard with it" ... rather than "use only the parts of the language that meet a prescribed standard."

The word "standard" is ambiguous... on the one hand, it can mean "out of the box, the stuff you get when you don't affirmatively ask for more" but on the other hand, it can mean "not your typical widget, meets the ISO9000 standard as applied to widgets, a refined version of the widgets that come from the widgets factory."

higherstandard was my attempt to call attention to the latter concept.

These are other words that might be better than "standard" --


Leave a comment

About Dean

user-pic I blog about Perl. I am now in California