Front page | perl.perl5.porters |
Postings from July 2017
On 14 July 2017 at 04:28, Father Chrysostomos via RT <perlbug-followup@perl.org> wrote: > On Wed, 12 Jul 2017 21:55:03 -0700, public@khwilliamson.com wrote: >> I guess we have a fundamental disagreement about language design and >> the >> direction Perl should go, which makes me sad. > > I agree the disagreement is unfortunate. > >> >> The point of adding synonyms for deceptively-named functions and >> macros >> is to make life easier overall. Forbidding new better-named synonyms >> for problematically named things forces everyone who comes along to >> deal >> with the gotchas and cognitive load that those people already here >> have >> had to deal with. By creating better named things, those people can >> largely avoid these problems. This allows them to work more >> efficiently, avoiding traps, and with less cursing Perl. > > When you first put forward this argument (specifically with regard to av_len), it made sense to me, and I had no objection to it. Later, people wrote to p5p complaining that the new situation was more confusing; in addition, *I* started to get confused. That was when I started to have second thoughts. > > I think Damian Conway was right when he wrote in PBP that one should not use English (the module). Since other people use punctuation variables, you are going to have to learn them anyway. Using the English names just forces others reading your code to look up the names that you are using. It just creates more cognitive burden. > > I think the same applies even to poorly named functions. You just have to learn the gotcha once, and then you can use the function and read code that uses it. (And if you use functions without reading either the documentation or the source, then you are coming close to what I would call autopodotoxy.) > >> Unless Perl is close to death, the number of people who are going to >> come along before it does die dwarfs the number who are already >> expert. >> Some people are knowledgeable in parts of Perl, but not all. They >> also gain if gotchas get removed before they have to deal with them. > > But the gotchas never get removed. You just end up with a larger pile of functions for people to sift through. Not to mention a lot of existing (and correct) code that they cannot read without learning the discouraged parlance. So they have to learn the different forms anyway. > > My personal experience is that what you are arguing for, while it sounds good, does not work in practice. I think the reason that it sounds good is because it does make sense at a micro level. If you are working on company code for instance, or a small code-base, renaming poorly named things means that the old name is *gone*, and cognitive burden is reduced. But with something like Perl we can't just get rid of things, if we want to rename we have to do something for all the older code out there. So we have to support both in some ways. Which means the cognitive burden is increased. Despite this I think sometimes these things *can* be justified and managed, but we have to be extremely careful about the choices we make, and have real plans in place to deprecate the older use cases in some kind of way. So for instance if we were going to get rid of Internals then we can rename things it contained, and then bundle an Internals.pm which does the right thing, people needing back compat can add 'use Internals' and get the back-compat. So i could see us considering the ideas in this thread in the context of the proposed introduction of 'array', 'scalar', etc. yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous | Thread Next