The domain was snapped up by a squatter sometime between July and August. 🙁 What a pity, I always enjoyed those conversations.
Interestingly (to me, at least) they reported that the removal of the
/omodifier made their case 2-3 times slower. This surprised me somewhat, as I had understood that modern Perls (for some value of "modern") had done things to minimize the performance difference between the presence and absence of
They indeed have.
qr objects which don’t get that benefit. On the machine I’m typing on, the following benchmark…
Strictly speaking not news exactly, given that it dates from early 2018, but it was news to me, and since I haven’t seen it make the rounds I still find it worth disseminating. From the MySQL 8.0.11 release notes:
utf8mb3character set will be replaced by
utf8mb4in a future MySQL version. The
utf8character set is currently an alias for
utf8mb3, but will at that point become a reference to
utf8mb4. To avoid ambiguity about the meaning of
utf8, consider specifying
utf8mb4explicitly for character set references instead of
This a declaration of intent rather than a change that has happened… but still. It’s been a very long September…
(To prepare for this you’ll want to note what you need to take into account regarding the way
utf8mb4 and indexes interact.)
The contemporarily unique strengths of CGI as a deployment strategy are that CGI scripts ⓐ can just be dumped in the filesystem to deploy them and ⓑ do not have any of the issues of long-running processes: they tie up no resources when not in use and are extremely reliable because of the execution model, in which global state always starts from a blank slate when serving a request and there is no process that outlives the request and could wedge itself. Anyone who consciously chooses CGI over alternative deployment strategies nowadays probably has a fire-and-forget use case where the script will be seeing too little traffic to be worth any effort to tend to it regularly.
In his article about modern CGI, Grinnz suggested using Mojolicious rather than CGI.pm as a framework for writing CGI scripts. Mojolicious is explicitly intended for users who are willing to keep changing their own application code in order to enjoy a framework whose API design can be changed (hopefully for the better) without sacrificing the framework’s code quality. In the Venn diagram of the CGI-for-deployment and Mojolicious-for-framework audiences, there is no overlap. So I consider Mojolicious an oxymoronic alternative to CGI.pm.
A much better alternative to CGI.pm is simply raw Plack. It is lower-level than Mojolicious, so the code will be more verbose, but Plack’s stance on compatibility matches a fire-and-forget use case far better. CGI::Alternatives does not do a great job of selling that option, so let’s just see what it would look like in practice for the given example.
Wow, you people.
Or just deader than Ruby?
(Does this constitute a Ruby-o-meter++? Can it increment in reverse?)
Posting grand pronouncements about what Perl 5 has to become or the new name it absolutely must adopt won’t do anything. That’s irrelevant.
“What people manning the booths at non-Perl conferences say is the perception of Perl among those outside the echo chamber is irrelevant; I know the REAL problems Perl is having: they are the ones we think mu…
I’ve decided this is so important to me that I’ll no longer attend or speak at conferences that don’t adopt and publish a code of conduct. I’ll also be using whatever clout I’ve got to encourage conference organizers to adopt and publish anti-harassment policies. […] So why, given the issues [with codes of conduct that] I outlined above, do I take this so seriously?
He makes the point, but does not emphasise it enough in my opinion: the code of conduct is not there to communicate to attendants how or how not to behave (in which capacity it is superfluous with the well-behaved majority and ineffective with perpetrators): it is there to reassure members of minorities that they will be heard and their concerns are understood.
Calling it Perl 6 was sensible at the time of its inception, for all the reasons chromatic outlined there in caricature. But the premise and direction of The Language has evolved dramatically since the time its name was chosen. In premise it’s a similar idea now, and at the same time one with naught in common with the original. And still, the name persists.
As programmers we (yes, us, us all, not editorial we) should know of the importance of naming: any good programmer spends a lot of time in agony over variable names and function names.
What we (the editorial, this time) have done here is refactor the entire codebase rug from underneath the variable, yet insistently kept its now-misleading name the same. Become, became: we left the frame.
On the other hand – of course! –, names create. There are no things until there are words to name them. And also: names identify. You don’t rename your son or daughter because they’ve grown and changed.
And Perl 6 is Larry’s baby.
I don’t know what to say.