> uniformity/genericity --- you know those generic sorting algorithms that
>need the length of the data and a generic comparision operator? How easy
>is this in a non-orthogonal language like Perl?

The specific feature you brought up doesn't cause any problems in practice. Let's take your example and suppose that you wanted to write a sorting function. You write it, but it only works on arrays. In C++ it might also work on a string, because a string is an array. But in Perl, if you pass a string, expecting the characters in the string to be sorted into order, it doesn't work.

Is this a big deal? No. Why not? Two reasons: First, sorting the characters in a string is a very unusual operation, so it does not come up very often. But primarily because if someone did want to use your function to sort the characters in a string, they would just use split to turn the string into an array and pass the array of characters.

Perl's genericity mechanisms are a lot stronger than those in C++. Consider several C++ classes where objects in each class will be joined to gether in linked lists. Each class has a 'next' member which will be used to point to the next object in the list. Now you want to write a C++ function that will traverse a list of objects of any class. Oops, you can't. The only solution is to use the ridiculous templating mechanism to tell C++ how to generate one separate traversal function for each class!

But in Perl this task is trivial:

  sub traverse {
    my ($head, $function) = @_;
    while (defined $head) {
      $function->($head);
      $head = $head->{next};
    }
  }
[download]

I'm going to stop picking on C++ now. It's unfair, because C++ is such a shoddy language.

The short answer to your dig about Perl being a 'non-orthogonal' language is that Larry is really smart, and he put in the orthogonality in the places where it was important, and not in places where it wasn't.

Perl does offer genericity at the OO level, provided you follow standard OO design techniques. The low-level things in Perl are not objects, by design. Think of it in physical terms. I can tug on a bed or a desk or a car in a uniform way, but when I get down to the atomic level, the way I attract a proton is different from the way I attract an electron. You're trying to look for orthogonality at the "atomic" level of Perl. No. Stop looking there. Build it at the higher levels, and all will be well. Perl lets you make interesting things, but Perl also lets you make crappy things too.

-- Randal L. Schwartz, Perl hacker

The boss and the secretary do not code in Perl. That's what they pay me for. ;->

Programming is the practice of converting human thought to computer syntax. Programming has seen an evolution from punched cards, to machine language, to assembler language, to C and to Perl. In each case, the language has moved further from "speaking to the CPU" to "here's what I want to do."

An acid test of such evolution is the ability of the commoner to codify his thoughts in working programs. While Window-based menu systems go a long way towards providing such functionality, to date they are not as configurable as a scripted program and hence the need for a language allowing for expressiveness by everyone, not just the person trained to convert human thought to computer syntax.

Programming is the practice of converting human thought to computer syntax. Programming has seen an evolution from punched cards, to machine language, to assembler language, to C and to Perl. In each case, the language has moved further from "speaking to the CPU" to "here's what I want to do."

I'm going to weigh in with heavy support for this statement. One of the great things about Perl is that Larry questioned some of the assumptions other languages made, and thus moved the line between DWIM and DWIS closer to DWIM. There has to be a limit somewhere though, which is why I also disagree with the initial post.

As has been mentioned, there's always been a faction that dislikes the can-be-misleading name of length(). This is the first time I've ever heard a complaint about array slices, and I can't say I agree with that complaint.

The approach to take is not "This is wrong" but "how can I make this right in all cases". Length,as has been mentioned, shouldn't be too hard to change with no real loss. If you can come up with new examples where a "commoner" would think something, and a fix that doesn't break the flow of a long-term programmer, detail it. Submit a proposal to the Perl maintainers, write a patch, or whatever.

On one level you're right. Languages are designed to fit with our personal understanding and methods of thought. The early programming languages took none of this into account, which made software design difficult at best. Most languages take the approach of, "The reason software design is difficult is that you're not using enough (functions|variables|comments|linguistic_names|classes|libraries). In truth, the reason programming is so difficult is that thinking is so difficult.

Most people have a prefered method of thinking and do not want to change that. Programming opens you up to new ways of thinking, and Perl opens you up the most because it encourages so many different ways of attacking a problem.

So in some sense, princepawn, you're also wrong. That's because if the language doesn't make sense to you, the programmer, the problem is with the programmer for being unwilling to adopt the language's mindset. And this is as true of Cobol as it is of Perl, although Perl definitly encouages more ways of thinking about a problem.

Princepawn, I feel like your view of the perl mindset is, "Whatever makes sense to my mind should be easy to describe in perl." You're claiming that you are the "enlightened" one and that it's perl's job to enlighten itself. In reality, each time you say, "This doesn't make sense to me-- someone else must have done this wrong," you move further away from understanding the true purpose of perl.

The true purpose of perl is to serve others, but it can only do this if you humble your mind. But much like enlightenment, I suppose that needs to be experienced, not explained.

-Ted