Re: Apparent Inconsistencies in Perl Function Naming

[princepawn]

Several things have been said above. Summarily, I can reply with

1. intuitiveness --- like I said, to a person versed in Perl's concept of context-sensitivity, something like scalar makes sense. But, to my C++-programming boss who simply wanted the length of an array, then looked in perlfunc under length and then asked me, it was a hassle. So, it may be best for a trained Perl programmer, but think from the mind of your boss or your secretary or someone else who just wants something simple and fast and you will see what the most intuitive thing is.

   Now of course, the first thing that people say is "RTFM"... and my reply to that is: "the manual is very very big." there are much simpler languages out there. REBOL (a next-generation forth) is nothing but English concepts mapped to simple words.... the length word in REBOL works on all series types --- ports, blocks, strings, etc.But there is no industry acceptance of REBOL. So I write modules like Net::FTP::Common and advocate Quantum::Superpositions which bring Perl use nearer to the readability, succinctness, and ease-of-use of REBOL. And I am developing a parser for REBOL in Perl... then the power of REBOL will be available to Perl developers.

2. 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?

[Dominus]

Says princepawn:

> 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?


Since you asked, it works really well. Perl achieves a lot more genericity than C++, which you meantioned earlier.

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};
    }
  }

That's all. One function handles every possible kind of object, as long as the object has a next member. It even handles the classes that haven't been defined yet. It can even be made to handle classes where the link member is named something other than next. (That's a one-line change.) This is impossible in C++. Even the humongous templating feature does not help.

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.

[merlyn]

Perl is intuitive, but not for casual programmers. If you're needing to look up how to get the length of an array, Perl is not for you. Perl is an expert language: very powerful in the hands of experts, but perhaps dangerous to the casual programmer. It's more like a chainsaw than a knife. You must be this tall to program in Perl. Remember the adage: "Make a language that any fool can use, and only fools will want to use it." I'm glad Perl is not for fools.

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

[jontnswift]

> So, it may be best for a trained Perl programmer, but think from the mind of your boss or your secretary or someone else who just wants something simple and fast and you will see what the most intuitive thing is.

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

[princepawn]

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.

[swiftone]

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.

[tedv]

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