According to Code Complete 2, a number of studies have shown that, to a good approximation, the amount of code written per day in a programming language is independent of how high level that programming language is. Therefore you can estimate the productivity of people working in that language from the efficiency of saying things in that language. With that in mind he produces a chart of, based on real world code bases, the approximate relative number of statements needed in different languages to say the same thing.

By his figures, Perl is 6 times as efficient to say things in as C, which is within the 5-10x estimate that Marshall gave. Incidentally by his figures, Java is 2.5x as efficient as C, which would make Perl over twice as efficient to code in as Java.

About linked lists, one of the most common use cases for linked lists in C is that someone wants a queue or a stack which can grow arbitrarily without having to know the size first. For that use case, Perl arrays are a great replacement. For the case where you wish to insert or delete in the middle of an array, it is true that a linked list written in Perl scales better than using splice. But the overhead of Perl is so much that if your arrays only have hundreds of elements in it, the simple splice solution is more efficient than writing a linked list. (There is even more overhead if you want to keep your double-linked lists from leaking memory.)

So while Perl arrays are theoretically not replacements for linked lists, for a great many practical purposes they are.

I would have said that functionally, a linked list is more like a hash than an array, so the argument seems prone to falling off a cliff and accelerating exponentially as it enjoys the gravity.

An irony might be that I would bet that perl hashes are implimented via C pointer arrays (just a guess).

Another guess: 6X is bang on, bytes of code wise (but how long you took with each line may be another thing?...the only real "efficiency" may be comprehensibility, which should have to be wildly Subject-Oriented)

Actually a linked list is orthogonal to both C arrays and Perl hashes, but is somewhat similar to Perl arrays. Given that Perl arrays are partially implemented using linked lists, that shouldn't be too much of a surprise. Although, at the end of the day, anything written in C (and Perl is written in C) uses combinations of C arrays and pointers in any case - that's pretty much all there is in C.

It is easy to argue, because of the greater complexity arising from the greater size, that it takes longer per unit (lines, bytes, whatever) as the size increases. One could also argue that as the functional density increases per unit of size so does programming time (that's the comprehensibility thing). The implication is that somewhere there is a crossover point and a further implication that as functional density increases so does scalability. The interesting conclusion is that Perl is faster to code and scales better than C. And, because opportunity for bugs tends to be size related, Perl code likely has fewer bugs than the equivalent C code.

Update struck bogus comment.

---

True laziness is hard work

You can argue until the cows come home what the appropriate Perl analogy for a linked list is. But there is no question about whether they are often used in the two use cases I presented, and about whether Perl arrays are appropriate as a replacement for that use case.

I don't know what you meant by saying that Perl hashes are implemented via C pointer arrays. They certainly are not just internally an array. But as is normal for implementing a hash table, Perl hashes are implemented using both a C-style array for the lookup of the hash bucket from the hash value, and linked lists for the contents of each hash bucket. For the details you can look in perlguts, and for the really gory details read hv.h and hv.c in the Perl source code.

To answer your rhetorical question about how long it takes to write Perl, multiple studies across multiple language, backed up by anecdotal experience among Perl programmers that I know, says that X lines of Perl takes roughly as long to develop as X lines of other mainstream programming languages. Furthermore comprehensibility is more an effect of the programmer rather than the language. Though if you wish to write incomprehensible code, as Larry Wall says, In accordance with UNIX philosophy, Perl gives you enough rope to hang yourself.

No, I didn't mean Perl array. I meant Perl list. Please explain what you think the difference is between a Perl array and a Perl List. I think this just some kind of nomenclature difference.. Not any real disagreement!

Maintenance of a Perl "list" is expensive CPU wise and I didn't say that it wasn't.

@arr = grep {...} @arr is essentially a scan of of what would be in C linked list, but as I said, even more powerful from a language standpoint.

Update: I am still not "getting it". A simple Perl list is similar to a C char ** array (array of pointers of pointers to strings), but more flexible and more powerful.

Please explain what you think the difference is between a Perl array and a Perl List.

When someone talks of lists in Perl, they are usually talking about one of the following:

• A list of values on the stack.
• The n-ary operator which creates a list on the stack. (e.g. "EXPR, EXPR, EXPR")

There is also "list context", a context in which expressions can be evaluated.

In contrast, an array is a type of variable. There is no list variable type.

I'd be hard pressed to find similarities between list values, list operators, list context and array variables because values, operators, contexts and variables are fundamentally different from each other. It's not just nomenclature.

I am still not "getting it". A simple Perl list is similar to a C char ** array

A Perl array is similar to T* array in C, except it automatically resizes itself when needed (like C++'s std::vector). Due to C's type system, C doesn't have anything similar to Perl lists. (Same goes for C++.)

In contrast, an array is a type of variable. There is no list variable type.

I would agree with this.
@xyz= (1,2,3);
xyz is the name of an array with a list of: 1,2,3.
But the problems is, is that this confuses folks. I often simply say that xyz is a list.

Please explain what you think the difference is between a Perl array and a Perl List.

Arrays are variables, lists are values. It's the same difference as between $foo and 3.

I think this just some kind of nomenclature difference.. Not any real disagreement!

Differences in nomenclature are not something to trivialize - specially not when it's about important concepts.

A simple Perl list is similar to a C char ** array (array of pointers of pointers to strings)

No, it's not. First of all, a char is not a string, but a (small) integer. Depending on usage, a C char is equivalent to a Perl integer, or a Perl string consisting of exactly one character. Secondly, in C, array elements all have the same size - all elements are integers, characters or pointers for instance. (Pointers in your example). In Perl, values of a list can have different "sizes" - or rather, different types (mixed integers, references, objects, strings, etc) - as the "size" of a value isn't a useful concept in Perl (it is in perl, but not in Perl). Third, and this is the big one, elements of an array may change (both in C and in Perl). But in Perl, lists are unmutable (of course they can be changed by perl, or by using XS - but not from a Perl POV). They are as unmutable as the value 3.

Yes, a char is a character. But char*, is a pointer to an character. And char** is a pointer to a pointer to a character (array).

Ok some examples:
in Perl:

#!usr/bin/perl -w
use warnings;
my @list = ("a1", "b23", "c45", "d1");
print join (" ",@list),"\n"; 
#prints: a1 b23 c45 d1
[download]

In Perl, the list "knows" how big it is.
This is not true in C! In C we have to do stuff to help things out! Like this:

include <stdio.h>
int main ()
{
   char *list[] = {"a1", "b23", "c45", "d1",'\0'};
   // list is an array of pointers to chars 
   char **mover;
  
   for (mover=list; *mover ;mover++)
       printf ("%s ",*mover);
   printf("\n"); 
}
// prints: a1 b23 c45 d1
[download]

For me, the difference is obvious! The Perl version is cool!
The alternative way in C would be to keep track of the number of items in the list array instead of a NULL value sentinel (and yes, there are more ways than than one I showed above). All ways are a pain in the rear compared with Perl!

Perl lists may be changed at will just like in C. I don't understand this comment: "lists are unmutable". Please explain, I just don't understand what you mean.