note
FoxtrotUniform
<p>The only major thing that irritates me about Perl's
way of doing complex data structures is that the
specification is implicit: you never sit down and
declare a "Hash of Hashes of Arrays", for instance:
you put arrayrefs in a hash, then a ref to that hash in
another hash. And you never sit down and code up a list
of admissible hash keys... if you haven't documented
what's expected to be in the hash, and where it's
inserted, your code can be pretty impenetrable.</p>
<p>On the whole, I think this way of doing things is
better than the alternative: well-defined, rigid data
structures described at compile time. (Yes, folks, I
like LISP too -- conses are your <i>friends</i>. :-)
What irritates me is that these "implicit" structures
imposes an extra documentation burden, and one that's
not always easily satisfied in code. Rob Pike claims
that it's better to put the complexity in the data than
the code, and I agree, but that doesn't help you if the
data is undecipherable.</p>
<p><b>Update:</b> Another possible disadvantage of Perlish
(or LISPy, <strike>Haskellic</strike>Schemeing, etfc) "implicit, on the fly" data
structures is that some compiler optimizations are difficult
or even impossible. <i>NOTE: I haven't actually tested
these assumptions empirically; for one thing, I'm at work,
and don't have the time. I'm going on my understanding of
modern computer architecture and compiler optimization,
which may be sorely lacking. Thou hast been warned.</i>
</p>
<p>For instance, if I want a 3d vector,
I could write the following C:</p>
<code>
typedef struct {
float x;
float y;
float z;
} vec3d;
</code>
<p>Now, the compiler knows that a <tt>vec3d</tt> takes up
exactly 12 bytes (assuming 4-byte floats), and can make a
bunch of optimizations based on that knowledge and some
information about the processor it's compiling for. For
instance, it can pad the struct out to 16 bytes if
addressing is faster on 16-byte boundaries. It can take a
declaration like:</p>
<code>
vec3d vertices[20];
</code>
<p>and allocate 240 (or 320) contiguous bytes for it.</p>
<p>Contrast that to the implicit equivalent:</p>
<code>
my %vert = (
'x' => undef, # placeholder
'y' => undef,
'z' => undef,
);
</code>
<p>Perl knows nothing about the size of this hash: it has
three elements <i>now</i>, but there's nothing stopping
you from adding a dozen more in the very next statement.
And since the size of the hash isn't guaranteed, the best
Perl can do if you put twenty vertices in an array is
allocate twenty contiguous <i>references</i>: that's better
than nothing, but unless you're improbably
<strike>lucky</strike> careful in your memory management,
the hashes those refs point to are going to be scattered
all over memory, which means cache misses and subsequent
stalls.</p>
<p>The Perlish alternative is to create data structures in
scalars with <code>pack</code>, which is just fugly.</p>
<p>The "Perl is slower than C!" thesis shouldn't be any
surprise to anyone, of course. I just want to point out
that the flexibility of hashed (hashish? ;-) structures is
sometimes a disadvantage. Again, I want to emphasize that
I tend to like this way better, but I'd be a fool to
pretend that it's perfect.</p>
<p><b>Update 2:</b> Minor grammar corrections.</p>
<p><b>Update 3:</b> I'm not picking on Common LISP in
particular, just the "add stuff on the fly" way of building
complex structures, which you <i>can</i> do in Common LISP
(or any other LISP, for that matter), and in my experience
<i>is</i> the most common way of building structures.</p>
<p>A good general rule for finding language features in
Common LISP is "it's in there somewhere". :-)</p>
<p><tt>-- <br>
The hell with [paco], vote for [Erudil]!<br>
:wq</tt></p>
169779
169779