CPAN: Mr. Graham talks about code reuse as being the holy grail. If so, then CPAN is the castle where the grail is kept. Users of other languages such as OCaml and Lisp always talk about how they wish their language had something similar. They're jealous.

Community: PM or crack -- which is more addictive?

Natural language: According to my understanding of Perl, Mr. Wall designed Perl to be like a natural language. This is in sharp contrast to Lisp, which is rooted much more mathematically and is tough for a lot of people to think in. The upside to the natural language approach is that it meshes with a human's own system of thought and the language is easier to think in for most people. Plus you can create concise idiomatic expressions -- just look at the obfuscations.

It would be interesting to see if programmers finally cracked the elusive goal of an english language programming language in 100 years; maybe we'd all use that or a subset.

I agree with Mr. Graham that in the future the goal of programming languages will be to reduce programmer development time at the expense of processor power and memory. To this end, Perl is part of an evolutionary step.

As processor speeds continue to creep up and memory becomes even more abundant the need to be efficient in terms of cycles and memory decreases. As a result it will typically be more efficient to use a very high level languague like Perl to get stuff done. This is because IMHO you can get a given task done faster in Perl than say trying to do the same thing in.....ASM, C, C++, Java in roughly that order. So it will be more efficient/cheaper to do it in a VHLL.

If you look at the Microsoft .NET framework you will see that they are abstracting like mad adding Intermediate Languague, Bytecode and JIT compilation layers into their language model - it makes Perl look positively like a thoroughbred race horse. But then I am a firm believer in the intel/M$ consiracy. M$ write more and more bloated software in slower and slower languages to justify people having to by faster and faster intel hardware.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

As processor speeds continue to creep up and memory becomes even more abundant the need to be efficient in terms of cycles and memory decreases.

That's a dangerous thing to think. While it is true, to some extent, you have to be very careful that you don't become less efficient faster than the machines become faster. Otherwise you end up with software whose newer versions run slower than the older versions, even with hardware upgrades.

It's also a dangerous thing to think as you quickly end up with software that won't run on older, or even current, machines for no particularly good reason. (Burning time and memory to give you more time to play Warcraft is not a good reason)

And, of course, thinking "my time is more valuable than any computer's" is incorrect for a not incosiderable number of programmers...

I don't understand your argument. Are you for or against "layering" and abstracting? The way I read Paul G.'s article, he is for layering. (See the paragraph beginning "Another way to burn up cycles is to have many layers of software between the application and the hardware..." and the subsequent four paragraphs.) In my experience, it has proven to be a useful technique.

Now, if you are arguing that layering, done badly, is a problem, then I agree (also through experience) whole-heartedly.

...every application I have ever worked on is a glorified munger...

One thing you'll note about the article is that the author (not incorrectly IMHO) measures the long-term fitness or longevity of a language not in terms of how long programs continue to be used that were written in the language or even how long people continue to write new programs in the language but in terms of how much the language itself continues to be improved and how other languages borrow from it. In other words, the two largest branches are C and lisp, since almost every language (except extreme novelties like befunge) borrows extensively from one or the other of them. (Perl of course borrows from both somewhat.)

In this respect, Perl 5's pattern matching is probably the thing that brings it closest to what the article calls the "core". Designers of other languages are positively wetting themselves in excitement over the prospect of having Perl-style regex support. CPAN, as someone else here pointed out, has that quality too. I wish my Linux distro had an install/upgrade process as convenient as CPAN.pm

With Perl6, it's going to be the object model, and possibly also rules.

for(unpack("C*",'GGGG?GGGG?O__\?WccW?{GCw?Wcc{?Wcc~?Wcc{?~cc'
.'W?')){$j=$_-63;++$a;for$p(0..7){$h[$p][$a]=$j%2;$j/=2}}for$
p(0..7){for$a(1..45){$_=($h[$p-1][$a])?'#':' ';print}print$/}
[download]