[NTLUG:Discuss] Direction Recomendations

[Richard Cobbe]

Lo, on Thursday, 20 July, 2000, MadHat did write:

> Richard Cobbe wrote:

<SNIP>

> > (Note that neither Perl nor Java are in that list.  Java is, at best, a
> > mid-level language.  True, it's higher-level than C++, but that's rather
> > damning with faint praise.  Perl, as Steve said above, is just a mess.
> > Avoid it wherever possible.)
> 
> Please...
> It is easier to avoid 'Language wars' if you don't spout bad things
> about languages (that apear to be based in personal opinion, but are
> presented as fact).  Perl is a great language.  There is nothing wrong
> with it, and just because you choose to not like it does not mean that
> it is a mess or bad.

In fact, I do have several objective, factual statements to back up my
statement that Perl is a mess; I simply didn't include them because I
thought they were somewhat off-topic.  However, since you asked for
them....

MEMORY MANAGEMENT: Kevin Brannen already mentioned Perl's memory management
system as one of its strengths.

Um, no.  Perl uses a reference-count garbage collector.  This is basically
the `bubble sort' of the garbage collection algorithms, for the following
reasons:

1) It's probably the simplest GC algorithm to understand, and therefore the
   one that most people tend to arrive at first.  (This is not necessarily
   a bad thing.  However:)

2) It's not particularly efficient, although unlike the bubble sort, it
   tends to fool people into thinking that it is.  True, you don't have to
   sweep across memory in the same way that you do with the other GC
   algorithms that I know (copying, generational, mark-and-sweep), but
   there are some significant performance hits inherent in a ref-count GC
   that many people appear to overlook.

   Consider: in a language without a ref-count GC, changing a
   reference/pointer is a very fast operation.  On a RISC machine, worst
   case: load the new value, write it into the register containing
   the pointer, and write the new pointer value back to memory.

   With a ref-count GC, this becomes (also worst case):
      - Dereference the old pointer value, bringing the referent's refcount
        field into a register.
      - Decrement the refcount field and write it back to memory.
      - If the new refcount field is 0, delete the object.
      - Load the new value into the pointer's register.
      - Dereference this new pointer value, bringing this referent's
        refcount into memory.
      - Increment the refcount by one and write it back to memory.
      - Write the new pointer value back to memory.

   That's a total of 6 memory references, as opposed to 2, not even
   considering having to delete the object (or other problems, like page
   faults).  Memory accesses are SLOW compared to other operations.

3) It's not even particularly *correct*.  It can't handle cyclical data
   structures.  Thus, the only options the programmer has are
     - avoiding cyclical data structures, which isn't always possible
     - breaking the cycles manually, which rather defeats the purpose of
       having an automatic memory management system
     - leaving the structures hanging around but inaccessible until the
       process terminates.  (Even THAT may not work in certain situations
       on Windows!)
   Especially for programs which are supposed to remain running for long
   periods of time, none of these are particularly acceptable.

The CS community, and especially the language folks, have known of GC
implementations which don't suffer from these problems for DECADES.
They're really not all that hard to implement; I wrote a copying GC in less
than a week back in school.

(To be fair: Python has the same problems, although JPython uses Java's
innate GC, which isn't ref-count.)

Before you say, ``But that's an implementation issue, not a language design
issue,'' I think it *IS* a language design issue.  Here, the choice of GC
algorithms directly affects the actions that a programmer can take; see
point 3 above.

(All this said, I will concede, quite readily, that Perl's memory
management system beats C++'s hands down, only because C++ doesn't HAVE
one.)

There are a number of other things I can say about Perl, but I won't get
into those here.  If anyone's interested, send me private mail---and be
prepared for a lengthy response.

> It is a very easy language for a lot of people to learn.  It is very
> powerful and versatile and portable...  but so are other languages.

....which manage to be powerful and versatile and portable....without
Perl's shortcomings.

Richard