3 ms·
I once did a lot of Perl too, and I agree that Perl has many design flaws, but I prefer it this way. The main reason is if the same array is contained inside tw
by adrianmonk 7y ago
I once did a lot of Perl too, and I agree that Perl has many design flaws, but I prefer it this way. The main reason is if the same array is contained inside two different data structures, I want this to be explicitly obvious in the syntax of the language.
For example:
my $a = [10, 20, 30];
my $b = { array => $a };
my $c = { array => $a };
$b->{array}[0] = 99;
print $c->{array}[0];
To me, anything the syntax can do to make it clear that the above code prints "99" (and not "10") is a net win. I don't care how cluttered it looks or how much extra typing it requires. If a language hides this from me in the name of cleanliness, then it's creating a leaky abstraction that is going to cause bugs and other forms of suffering.
If you're in a language which has immutable arrays, then this doesn't matter. But Perl isn't that, so that's not really relevant here.
To me, languages that add reference types (like C++'s) or language features that allow passing things by reference just create an extra cognitive burden. I look at some code and wonder, "Is this going to have ripple effects in distant places?", and I have to work through some rule in my head such as, if it's an integer, then no, but if it's an array, then yes.
Contrast that with the Perl (or C) way. I look at some code and the syntax tells me. There's no mistaking what's going on. So less cognitive burden and less opportunity for error.