Feb 18 2006
Accidental Syntax
I’m going to take a break from bashing McCain for a while to bash Perl instead. I’ve been thinking about language design again, so it was interesting that I stumbled across this blog post on accidental syntax in Perl (I got there via this discussion on Lambda the Ultimate). The author points out a couple of poorly documented to the point of probably being accidental “features” of Perl. He concludes:
I don’t think it says anything good about Perl that this sort of accidental feature shows up in the language. I can’t think of anything comparable in any other language. (Except APL.) C has the 4[ptr] syntax, but that’s not a feature; it’s just a joke. The for $i qw(…) { … } syntax in Perl seems genuinely valuable.
I’d go a step further: I’d say this is evidence of Perl’s own self-immolation. This is what you get when you have a “postmodern” programming language, and the syntax looks like this:
.
The problem is that Perl really isn’t post-modern, it’s really pre-modern. It’s a throwback to the programming languages that inspired the “modern” style of programming language design, and he’s re-learning the hard way the lessons that gave rise to that school of thought. A number of languages probably had accidental designs- notice the other languages being mentioned, like Lisp (the late 1950’s), APL (the 1960’s), and PL/1 (early 1960’s). All languages designed before the great Modernism revolution of the late 1960’s and 1970’s.
The modernist approach arose out of a rejection of what Larry Wall would call post-modernist languages. Languages so complex that accidental features arose. Languages so complex that people could only know in write in disjoint subsets of the language (consider the OO or functional features of perl- Chia, chime in with some interesting annecdotes). PL/1 was especially notorious for that (note also that C++ is having this problem, as many programmers do not know or really understand one or more of the C, OO, or template aspects of the language).
The reason the modernist design philosophy took over was the problems of the pre-modern (”unbridled complexity”) design philosophy. Features interact with each other- to many features, or poorly considered features, interact in unexpected ways (this is, in fact, how many “accidental features” arise- another name for an accidental feature is a bug). If you start getting programmers coding in distinct subsets of the language they can’t understand each other’s code. I’m not talking about limited knowledge of the language, where one programmer knows X and the other programmer knows X+Y, I’m talking about where one programmer knows X+Y, and the other programmer knows X+Z, where Y and Z are large relative to X. These programmers might as well be writting in different languages.
What I think we need is a new Modernist revolution. Preferably one that is willing to learn from the mistakes of previous generations. Hopefully the implosion of Perl will help this along.
Popularity: 2% [?]
The really concerning part is that I’m not entirely sure what the
for $i qw(...) {...}syntax does. Does it iterate over$iand all the elements in theqw(), setting the singular pronoun for each, or does it iterate through the elements of theqw(...), setting$ifor each? I honestly couldn’t tell you, and would have to try it out. I would think that it would be the former, but since the blogger said “it worked”, I presume he means that it worked as per the latter. That’s certainly a syntax error and a bug in the interpreter.At my current place of work, I’ve got two people who “know Perl”, insofar as they can actually write Perl that runs and do something like what they want it to do. The problem arises in that they learned Perl by way of Shell syntax, so what’s a natural course of events to them is drastically unnatural to me (who came to Perl after learning C++), and they hate the
use warnings/use strictpragma, which I swear by. But, see, that doesn’t let them do things like the following:I consider this to be The Evil, for various and sundry reasons, but it’s just the intuitive action for them.
On the other hand, I’ve got massive chains of maps and greps acting on hashes of arrays of hashes (all anonymous), and I’ve got fun inheritance tricks being pulled through closure-based method-prototyping, and that’s just as bizarre and Evil to them as their code is to mine.
Now, mine compiles under
use warningsanduse strict, so I consider my way to be inherently superior, but that’s just the Hubris talking.The problem with all of this is that there is a modernist revolution coming out of Perl — look at Python and Ruby, both of which have much stricter syntax. On the other hand, there’s three wrong turns that are happening: 1) they’re leaving the middle-tier between shell scripting and applications programming, trying more for the applications programming setting; 2) they’re moving towards run-time type checking instead of implicit static type checking, which is misoptimizing the language; 3) they’re trying to stick to what they know, so they’re just polishing brass on the Titanic.
For all of you just now wandering in because of the Bogo Bison prototype discussion, also check out:
http://enfranchisedmind.com/blog/archive/2005/10/19/34
~~ Chia/Robert/et al.
for $i qw(foo bar baz) {
# do something with $i
}
I as a perl programmer wonder why Mark Dominus thinks that this shouldn’t work. I might be wrong, but I think that the syntax for the for-loop is:
for 'optional alias variable' LIST CODEBLOCK
If you leave out the optional alias variable
$_is used. I his example$iis used.forexpects a list, not an array. If you wrote:for @array
that would be wrong as you would pass an array to the
fornot a list.(@array)converts the array to a list.qw(WORD1 WORD2)already returns a list, so it is not necessary to write(qw(WORD1 WORD2)). The extra()aroundqw(WORD1 WORD2)just enforce a list context that is already there.I realize that this might be confusing, but as an intermediate Programmer that is what I would have expected. In Perl arrays and hashes have no literals (array and hash references do!), so lists are used instead. However lists are not the same as hashes or arrays.
It’s true that Perl carries some baggage from the past, but most people who complain about Perl just don’t know it. I also don’t think the “Perl implosion” is real. Maybe Ruby is a nicer and more modern Perl 5, but the real innovation is happening in Perl 6.
[...] “I’m going to take a break from bashing McCain for a while to bash Perl instead.” (Accidental Syntax) [...]