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 CGI.pm... 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 old. 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"
I blog about Perl. I am now in California
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).
Whatever "readable code" is, is subjective.
Whats nice about perlcritic+perltidy is that your organization (company, project) can decide what "readable" means to you.
JSON for example has decided that trailing commas are unacceptable. The perl interpreter doesn't mind, but you might agree they can be a hazard.
Returning to davebaker's question as i understand it (which im not convinced i have fully).
I'm not hugely worried about the name of 'standard'[1], my interest is largely in the utility. The main utility is avoiding problematic syntax when as it's being written.
Anyone who has worked on large code bases has probably spent hours chasing things like mixed up "." and "," or other strange situations where lists and blocks and things got confused. Stuff like this is where the "write once" myth comes from.
Historically organizations I was involved with would lint with perlcritic policies picked from the freenode and pbp sets, plus many we made ourselves. Our in house rules generally grew because we had some sort of outage due to quirky code.
So I applaud the effort of coming at the language from scratch and picking out a sane baseline, rather than collecting best practices as things break.
Additionally, having it implemented at compilation is nice, rather than having to wait for CI pipeline.
From the perspective of external tools, transposing languages is rather academic and probably something to write a thesis about and never revisit.
The commercial utility is found with faster linting, code search indexes, better integration in IDE's etc. Automated bulk refactoring is also going to be much more successful. Testing semantics is also going to easier with more clear semantics.
Let me add a little bit of context if people are willing to stick with me.
My observation is that perl coders have a lot of experience under their belts and tend to just write code in vim or emacs. Some use ide-like enhancements to assist, most just rely on experience and the delayed feedback of CI.
If you're coming at perl for the first time, then vim+ci is a slow and long feedback loop. With lots of "well do this but also sometimes this...". All perl places I have worked at are like this, some take days to provide repo access or even a workstation!
So if you want to hire people and have them start committing code on day one in a language they have no prior mastery of (a very silicon valley ideal), the answer I have seen is to prohibit thorny parts of a language, to provide an IDE with formatting rules + linting built in. Asynchronous testing as you save is also helpful.
This is a very positive experience for new comers... they are succeeding in the language and their code i going to production on their first day! The automation in their IDE environment provides a tutor, pair programmer, adviser, and trainer wheels all in one.
When I see this coming out of Booking, and I'm also aware of their efforts maintaining perl IDE functions IntelliJ. Putting two and two together, they are refining an environment that's making their new hires successful in writing Perl.
1. I'm not thrilled with anyone taking generic top level terms in CPAN.
> 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 perl.org 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" --
bounded
bridled
calibrated
clarified
clean
clear
coherent
consistent
coordinated
deliberate
directed
disciplined
explicit
fitted
focused
hardened
harmonized
higherstandard
managed
measured
moderated
modulated
orthodox
polished
pragmatic
predictable
rational
refined
regimented
regulated
restrained
robust
sensible
sharpen
sharpened
sifted
smooth
solid
specific
steady
straightened
straightforward
streamlined
structured
synchronized
tamed
taut
tempered
tuned
untangled
I think within an organization 'use standard' is reasonable since it would be your org's 'standard'. For CPAN I agree that something like your suggestions would be better. Perhaps creating a prefix instead so that people could select differing profiles.
Grammar might not even be too bad.
use Grammar::standardized;
Then org's could have their own tweaked versions:
use Grammar::Shadowcat;
use Grammar::GSG;
etc