Sunday, May 6, 2007

I Stand Corrected!


I read in your SQL article that you had never used pointers in your life, or never needed to. But you also mention that you used Perl. This means you have in fact used pointers and absolutely must in Perl, unless you never used anything as complicated as an array/hash of arrays/hashes.

Larry Wall and co. call their pointers "references", either because they didn't know the difference or because of the bad reputation of pointers. But the fact is, a pointer and a reference both point to a location in memory. The difference between the two is that a pointer makes you "take the address of" a variable to get it and do some kind of casting/"dereferencing" to use the data again, while a reference handles all this for you (even in C++).

This is one of the biggest reasons Perl has such ugly, hard to read/write/teach syntax (how many newbies don't understand how to pass two arrays to a function?). And what is worse, they keep pointers in Perl 6. They just add more magic syntax to try and keep them out of everyone's way.


This is a good point!

In that case, I've not only used pointers, I've used them extensively, overused them, gone far out of my way to use them, and even found ways to work around their absence in Ruby.

I disagree with the criticism, though. Anonymous references are absolutely the part of Perl I enjoy the most. I find it very limiting when a programming language expects you to name all your variables. It's much nicer when you can write code to name the variables for you.


  1. I do not agree with that comment.

    When someone uses the word pointer it is meaning a C-like pointer. Perl references, as Python, Ruby, or Java references, are not pointers. If someone knows C pointers you can explain references to them easily: you explain the similarities and then the differences. But they are different things.

    You cannot touch memory directly through references, the language has the control, they have a different metaphor. You cannot perform arithmetic with references in the C-sense (it is legal to add an integer to a reference in Perl, but that just gives numeric context on the reference and evaluates to an integer, it's an unrelated behaviour to the one in C), you are not allowed to address arbitrary memory locations, etc.

  2. That seems like a good point also. Unfortunately I think the only way I can say for sure is to learn C. I do know the basics of C pointers but I have no practical experience with them at all and it really takes practical experience to speak meaningfully about something this specific.

    However, the original post mentioned pointers because I was comparing SQL to manual memory management. Although I don't know how precise or imprecise the corresponded between Perl references and C pointers is, I have to admit, it's pretty clear that manipulating Perl references is a far cry from manual memory management. So I think you're probably right, actually, fxn.

  3. You don't agree? I can't speak for the Perl community, but in the Computer Science community these terms aren't "up for debate", afaik.

    A "reference" since at least the implementation of Lisp was a variable that references a value (transparently). It doesn't require you to "take the address" of something to get one, or "dereference" something to get the data, it is automatic. Basically an implementation detail. As an aside, this has also to do with the term "dynamic typing". Dynamic typing actually means that the variables don't have type, the values do.

    A pointer is something you have to create with a "constructor" (e.g. \$var) and has an "accessor" to get the pointed-to data (e.g. $$var).

    C pointers are completely unrestricted, you can assign a number and cast it as a pointer, increment it to move to the next size, etc. I believe what perl has are generally referred to as "safe pointers".

    But they are pointers none-the-less, and they force the language into all kinds of (IMO) unnecessary complexity to support. Personally, I can't think of a single thing gained by having pointers, or if you must "manual references".

    The case of making variable names on the fly mentioned by Giles doesn't require pointers, you can do it in smalltalk, lisp, python, etc. in a variety of ways. And all of these ways are less trouble then the %${}-> mess of Perl IMO.

    It is simple Huffman-encoding: Things you need to do a lot should be less to type (e.g. working with variables), and things you don't need as often (e.g. list flattening, creating variables on the fly) are ok if they take a bit more to type. :)

  4. OK, calling somebody a liar because you disagree with them is going a little too far. This is totally in the geeks need to learn social skills category. It's just a programming language; it's not the Holocaust or something. I'm going to close the comments on this post.