That is saying something completely different. My contention is that to the uninformed
-
@+ and $LAST_MATCH_END
- $? and $CHILD_ERROR
- $^C and $COMPILING
- $^T and $BASETIME
- $^I and $INPLACE_EDIT
- $" and $LIST_SEPARATOR
are all obscure. If you don't know that Perl has a list separator concept, the name $LIST_SEPARATOR leaves you to
look everywhere for its meaning. I would not know $^I's meaning, but by understanding the naming convention, I know it is a token defined in perlvar; in some cases that may be enough to guess/remember its meaning because I don't need to consider concepts that come from the
-
problem, -- is $LIST_SEPARATOR part of user output
-
general programming, -- or is it about a data structure
-
host system, -- or is it about porting
-
or a specialty domain. -- or a bit of arcana from some lib
Be well
rir | [reply]
[d/l]
[select] |
If you don't know that Perl has a list separator concept, the name $LIST_SEPARATOR leaves you to look everywhere for its meaning.
It's actually worse than that, because of what I referred to above as 'term overloading'. For example, Haskell has the concept of 'list separator', but the new book takes great care to point out that:
Commas are separators, not terminators
Some languages permit the last element in a list to be followed by an optional trailing comma before a closing bracket, but Haskell doesn't allow this.
It's a minor example, but shows that by using the english versions it may induce assumed understanding in the reader due to term overloaading.
The symbolic versions do not suffer from this. Someone encountering $" for the first time will not make the same assumptions and will have to look it up in the documentation. Which is a Good Thing.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l] |
