skynight is correct that Perl 5 contains some fundamental semantic traps.
It does, but only when you're used to different semantics. Perl was my second programming language, but different enough from BASIC to assume no rule would be the same. I never fell into any of its well known traps. (I tend to get bitten by the more obscure semantics.)
Well, that's certainly an interesting point -- sometimes it's better for different things to look different so you won't get them confused -- but it's actually fundamentally different from the way perl was originally conceived. It was supposed to look a lot like things that programmers were already familiar with, so it would make them feel like they knew what was going on.
And I think the larger point here is that it's really okay to criticize the way something was done in perl. You can be totally committed to perl culture and still think that type globs were a mess.
(Or course, these days it's a little late to bother criticizing perl 5, since the design of perl 6 is pretty well fixed.)
| [reply] |
My experience is similar. There are some things I have
misunderstood in Perl and confused myself, but they
are not the typical things, because my language
background is atypical. I too started in BASIC,
then later Inform (hence most of my ideas about OO)
and subsequently elisp. (Ironically, I did not get
my ideas about FP from elisp; I never understood FP
in elisp but have picked it up (err, some of it)
since I learned Perl.)
This is an important point in this thread, because
it illustrates that what constitutes a "trap"
utterly depends on what language you think in,
what semantics you are used to. The first time I
saw someone posting on here about the
print($a+$b)*$c; trap, I thought
he was out of his mind. I had no idea why he
was multiplying the result of the print
by a scalar in void context, or what it was he
intended to accomplish by doing so, because I
don't think in C. (I figured it out eventually,
partly by looking at some of the answers to his
question, but it was quite a surreal moment when
I first looked at his code.) Is that a trap?
It sure as death and taxes
wasn't a trap for me. It's only
a trap if you are accustomed to thinking in a
certain fashion, which is not universal and happens
not to be the least bit Perlish. It's a common
trap *mostly* because so many people come to Perl
from a C or C-like language background; otherwise,
it would not be a trap at all.
I don't think it's possible to eliminate all the traps
for people coming from other languages, because each
other language will have its own set of traps.
When you move from one language to another, you
should expect to get caught by a few of
these misunderstandings until you learn to think in
the new language. As long as you're still thinking
in another language and translating, you're going
to get confused sometimes. That's unavoidable.
"In adjectives, with the addition of inflectional endings, a changeable long vowel (Qamets or Tsere) in an open, propretonic syllable will reduce to Vocal Shewa. This type of change occurs when the open, pretonic syllable of the masculine singular adjective becomes propretonic with the addition of inflectional endings."
— Pratico & Van Pelt, BBHG, p68
| [reply]
[d/l] |
I don't quite agree with that sentiment. That "trappiness" of any given language feature is indeed a function of your linguistic background, but that's not the only thing at play. You can also have pitfalls that are entirely internal to a language simply because two syntactically similar operations have subtle but important semantic differences. I think the whole () / [] distinction serves as a decent example of this. In Python, such a flub is not possible, whereas in Perl it most certainly is.
| [reply]
[d/l]
[select] |
You honestly believe that having different meanings
for parens versus brackets is inherently a "trap"?
You must be using some kind of really bizarroid font,
if they're not easily visually distinguishable.
Where I sit, ( and [ look as different as i and |.
I really think the problem you ran into has a lot
more to do with expectations you brought back
from Python. Comma and semicolon, or comma
and period, have different meanings as well. Is
*that* a problem? (No, I don't mean the scalar
comma operator; that's a problem for a different
reason, because people expect the other comma
operator's semantics, not because anyone confuses
it with the period.)
You admitted in your original post that you had been
using a language that assigns one semantic to the
brackets, then switched back to Perl, which assigns
them a rather different semantic, and got caught
expecting the semantic you would have had in Python.
I posit that this is exactly the sort of scenerio
where Perl's use of brackets will trip anyone up:
when you expect them to have a different semantic,
one that was assigned to them in another language
you've been using. Do you know anyone who was
tripped up by this in any *other* circumstance?
As far as "subtle but important" semantic differences,
I can only say that calling the difference between an
array and a reference to an array "subtle" is like
calling the difference between a bibliographic entry
and the corresponding book subtle. The concept of
references is absolutely crucial, one of the very
basic fundamentals of computer programming, right
up there with flow control IMO; if it seems subtle
to you, you're going to have much larger problems than
confusing parens and brackets.
"In adjectives, with the addition of inflectional endings, a changeable long vowel (Qamets or Tsere) in an open, propretonic syllable will reduce to Vocal Shewa. This type of change occurs when the open, pretonic syllable of the masculine singular adjective becomes propretonic with the addition of inflectional endings."
— Pratico & Van Pelt, BBHG, p68
| [reply] |