That's cool...I'm not looking to start a pissing
contest, but the question didn't have any replies
when I started my post, so I didn't have the
benefit of your code.

As far as the difference between a pointer and a
reference...dude, when it comes down to it, aren't
they really just the same thing? Semantically, yes,
they're different. Under the hood? I pass things by
reference, I give you the address. I use a pointer,
it holds the address of something. I make a reference
and I point you to a seperate chunk of code. I'm not
a complete chimp on that respect. I haven't had the
time or inclination to go look at whether or not the
interpreter makes full substitutions at references or
jumps to the sub when everything's said and done.
That's deeper than I've needed to be for a long time.

I _am_ an Acolyte, though, and one who does not get to
code nearly as much as he wants to, so it is my bad
for missing the pretty obvious reference to the
native sort. I shouldn't have done that. I've always
had that inherent distrust of someone else's code that
I haven't thoroughly looked examined, just a leftover
from school, and that's why I made the comment about
picking a sorting algorithm. I know those ingrown ones
are usually good at large data sets, but I like to pull
off the lid and see _exactly_ how it's working inside,
make sure it fits. You can't blame a guy for that.

As far as the difference between a pointer and a
reference...dude, when it comes down to it, aren't
they really just the same thing? Semantically, yes,
they're different. Under the hood?

This is one of my pet peeves, so excuse me if I come across somewhat strong.

A reference is not a pointer. Conceptually, there are many similarities, but the basic use of a pointer (at least in C and assembly) is that the pointer itself can be manipulated. As far as I know, you can't manipulate references without Deep Magic. Discussions of pointer concepts are worth very little to non-C/ASM newbies learning references, and can confuse C/ASM people even more. There is nothing to be gained by bringing pointers into a discussion of references.

Now of course, I realize you weren't trying to bring pointers into a reference discussion, you just used a similar term because you're familiar with it, so I'm not attacking you for that. (I'm attacking you for saying "aren't they really the same thing" :) )

As was already said, pointers and references are different
in a key way. A pointer is a direct address through which
you can get at something. A reference is an indirect way
to refer to it which hides any necessary garbage collection
from you. Therefore there are significant differences both
in implementation and use.

The implementation must differ because
you cannot just use a bare address. If you are doing some
sort of reference counting (which Perl does) then you need
to have the reference modifying reference counts on the
thing referred to. If you are doing some sort of garbage
collection then the reference needs to be kept track of so
that you can know to modify the reference if you move the
underlying object from one place to another. Either way
a reference is a considerably more complicated beast than
a pointer.

The use is likewise different. First of all you would never
be able to do games like pointer arithmetic with references
since that would have to expose too much of the internal
differences. Secondly pointers are an excellent candidate
for all sorts of errors in languages that have them, so you
need to be careful to carefully track when things are
allocated and need to be destroyed. So references are both
more limited and far safer.

This terminology difference is preserved across a lot of
languages. If the language says it has references, they are
opaque and it does garbage collection behind your back. If
they claim pointers then that is up to you but you may be
able to play a lot of Really Cool Tricks.

When it comes to sort, well trying to roll your own is a
Really Bad Idea. The reason is trivial. Perl has a lot
more overhead than a low-level language like C. Therefore
if you roll your own, you have to expect to be running about
10 times slower than the native function. If you are not
then that is a bug in the native function, not an excuse
to start rolling your own! If you cannot accept this and
keep on reinventing the wheel then your code is going to
be slower and more buggy than it needs to be.

And finally, I appreciate the thought of trying to answer,
but the execution is still an issue. Perl questions here,
particuarly simple ones, tend to be answered fairly fast
and completely. So if you don't have an answer that you
are sure is accurate and complete, you probably should
just wait for someone else to answer it. If nobody answers
it for a bit, then give a partial answer if you have one.

I am sorry if I am coming off stronger than I intended. I
just wanted to make sure that my -- vote didn't confuse
you, that you understood the reason for it. As it stood
your answer was one which was misleading in ways that IMO
would result in someone becoming further confused. I am
trying to explain why I think that, and make sure that
you were not left wondering (as has happened to me in the
past) why someone voted against your post.