I wrote very elliptically about this warning and received some helpful comments with the standard advice about how to proceed when encountering it. Except unfortunately that advice will be of no use when you encounter this warning.
Namely I should have been less cute about it and made it clear that I was specifically talking about a warning about a wide character “in substitution”. How can a s/// even possibly trigger a wide character warning, you ask? Beats me, to be entirely honest, even now, but: if you have a use locale somewhere, it turns out that it can. Because defeating that is what fixed the warning I was getting:
Ted Unangst:
And now we’re trapped. There’s only one friend variable, constantly changing as we go through the loop, with the most likely result one of our friends will get half a dozen messages, while the other five receive nothing, to the annoyance of both groups.
Funny that Perl got this one right when not only many before didn’t but many since also haven’t.
In Go, as Ted says, they may even change the language to fix it
; in Javascript, they already have.
Graydon Hoare:
[…] Corporate-employed FOSS maintainers working at a firm with these [very common] “growth and novelty” incentives [… are] in a position where their job performance is very likely to be evaluated in terms of visible growth and novelty (it might be dressed up in more abstract terms like “real-world impact” or “visibility” but it still means the same thing) even though that is exactly the wrong thing for the health of the project they’re maintaining.
I’m excerpting the gist of his article here but actually I suggest reading all of it. It’s not very long but gives flesh to this skeleton argument.
It doesn’t help that what he is talking about isn’t limited to employed maintainers; profit is not the only growth incentive structure that can lead to this novelty mindset, so this can exist entirely outside commercial context.
The domain was snapped up by a squatter sometime between July and August. 🙁 What a pity, I always enjoyed those conversations.
Tom Wyant:
Interestingly (to me, at least) they reported that the removal of the /o modifier 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 /o.
They indeed have.
Ironically, it’s 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:
The utf8mb3 character set will be replaced by utf8mb4 in a future MySQL version. The utf8 character 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 utf8mb4 explicitly for character set references instead of utf8.
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.
Or just deader than Ruby?
(Does this constitute a Ruby-o-meter++? Can it increment in reverse?)
Waxing philosophical
