Reliable and performant multi-threading applications, like advanced graphic-intensive GUIs, are probably the most visible problem for Perl right now. Any operating-level code is out, too, since Perl is based on C, and the standard C library functions are in general not reentrant. That probably also eliminates Perl for a lot of embedded device code.

Another, more disturbing problem for me is that, IMHO, it is very hard to develop with large teams in Perl, since there is no means to express the interface of a function in code. You have to rely on POD to document your interfaces. This makes it very hard to check programs for interface consistency. Also, the variety of parameter passing idioms ("my $arg = shift;", "my ($arg) = @_;", "my %named_args = @_;", "my ($fixed_arg, $ref_to_hash_of_options) = @_;", "my ($fixed_arg, %hash_of_options) = @_;", etc.) in Perl makes for a nice array of hard-to-find bugs when combined with lack of documentation.

That said, for small teams or single persons Perl is *the* most productive language I have seen till now. This is largely because of the amazing CPAN. Says Bruce Eckel (in: Thinking in C++. Prentice Hall, 1995. Translated from my German version.): "The only possibility of achieving really impressive increases in productivity is using other people's libraries."

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

... it is very hard to develop with large teams in Perl, since there is no means to express the interface of a function in code.

In discussions like this, it helps to quantify "large". For someone who has been working solo on 300 line CGI scripts, 3 people and 10,000 lines of Perl might seem large. For someone who has worked under the covers in, say, a large open-source project, 3 people and 10,000 lines of code may seem trivial.

Here's a data point: I've worked inside of a system that had 80,000 lines of Perl (not counting the CPAN components we used), of which the Perl part was about half of the code base (other parts where DHTML templates, some Java, some C++ for web server plugins, and a bit of SQL). The product was developed by a core of around 6 developers, and maintained by a core of 4, with quit a few non-core people contributing. In Perl, we had about 50 classes for major objects (and at least that many classes for helper objects -- I didn't read the entire code base, so there may have been twice that number). The lack of first-class support for interface specification was not a major impediment. The major impediment was getting new people (a) up the Perl learning curve, and (b) getting them up to speed on the theory of operation of the product.

We did use POD, though we put more effort into keeping it up-to-date than we spent reading any of it.

Thanks dws, I am glad to hear that.

The biggest Perl based system I have worked with till now is a commercial content management system called "Imperia" that has a little bit more than 175.000 lines of Perl code (with comments) in the last version I worked with.

I agree with you that "theory of operation of the product" is the biggest impediment in learning to work with such a system, and Perl is not a trivial language in itself, too.

Still, I find it very annoying that in Perl, your only option to be sure how a function is called is to wade through the actual big lump of code. And you can't auto-extract this information easily, either.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

But what about totally different problems? How about expert systems, where Lisp and Prolog rule, or functional programming where ML seems hot right now, or device-driver writing, or realtime systems, or embedded systems with 1K of RAM?

In theory, all languages that we would consider calling languages are "Touring Complete", meaning that they can all compute anything computable. So to that degree it can do anything, sure.

—John

<pedantic>

ack. that's "Turing complete", as in Alan Turing and Turing machines.

</pedantic>

anders pearson

The thought came to me that Perl could very nearly be the BEST resource a programmer could learn how to use, if it can be applied to most any facet of programming necessity.

Programmers get very attached to their favorite languages, and I don't want to hurt anyone's feelings, so to explain this point I'm going to use a hypothetical language called Blub. Blub falls right in the middle of the abtractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language.

And in fact, our hypothetical Blub programmer wouldn't use either of them. Of course he wouldn't program in machine language. That's what compilers are for. And as for Cobol, he doesn't know how anyone can get anything done with it. It doesn't even have x (Blub feature of your choice).

As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.

When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn't even have y.

...

I know this from my own experience, as a high school kid writing programs in Basic. That language didn't even support recursion. It's hard to imagine writing programs without using recursion, but I didn't miss it at the time. I thought in Basic. And I was a whiz at it. Master of all I surveyed.

--
Mark Dominus
Perl Paraphernalia

Well actually, I have grown up on other languages besides Perl, and can therefore make a better judgement of which languages I think are more useful than other ones ... hopefully that explains a bit of my thinking, Dominus.

Andy Summers

I would suspect, bladx, that you (like me) know a number of what I call C-type languages. Languages that are in the model of C and either are simpler or more complex that it, but use it as a base. Pascal, VB, Perl, Java, Javascript, C++, etc. Of there, Perl and C are the clear winners. Perl is for development speed and C is for execution speed and memory usage. (I'd use a C++ compiler to make C strongly-typed, but that's a personal preference.)

However, Having taken a (very) quick look at LISP and Prolog, for example, those are completely different languages from C, requiring a completely different paradigm. Not having a lot of experience in either, I wouldn't be able to say how their execution/memory usage compares, but I suspect that, for certain applications, it's very favorable.

Somewhere on PM, someone posted the four basic paradigms of programming languages. They roughly correlate to four different ways of tackling a given problem. I wonder if someone could bring that back up?

------
We are the carpenters and bricklayers of the Information Age.

Vote paco for President!

I've used perlcc and perl2exe and have found the results sometimes unpredictable when trying to distribute applications so I have aborted this method for all except the simplest of Perl programs. It may be my lack of knowledge about the internals as well. :-)

Keep in mind that there are languages which perform certain tasks better than others. Use whatever is best suited to the task.

I agree with this point ... isn't it comparable to what would happen if someone were cloned into 1000's of people, and then a disease came along that the original person was very susceptible to, and it killed all of them right off, since they were homogenized. (I think it could also be similar to microsoft and it's history.)

Anyways, I can see where you are coming from on this point, and agree that it's not good to consider one language to be the 'end all' of all other types of computer languages, it can only end up hurting the language itself, and prevent those who think it is from becoming developed programmers in today's changing world.

Thanks for the insight!

Andy Summers

There are a few applications that perl can be used for, but probably shouldn't. Real-time 3D comes immediately to mind (mostly because I'm a graphics geek, and that's what I do). Sure, I can use the OpenGL or SDL::OpenGL modules, but if I want to push 12 million tris per second I need to worry about vertex formats, video card cache optimization, memory alignment, and so on: sure, I could do that (probably...) in Perl, but it would require far more effort than just doing it in C. Of course, I could write it in C and do XS magic, but then I've done it in C, not Perl....

I'm still very new to Perl, but I would say Perl could do virtually anything that one needs it to be used for.

Almost certainly however, any language can do virtually anything. You could probably^* make a port of the Linux kernel to perl, or to visual basic. I believe it comes down to 'the right tools for the job'. In some instances, Perl is the best thing to use to get something done, and at other times the language will do the job just as well as a select few others. (I'm thinking of PHP and ASP for web development in particular).

There's no great language in my opinion. Perhaps, after learning enough computing and programming concepts we can identify what language is the most sutable for our task, use it, or (hopefully) learn enough of it, to get our job done. FoxtrotUniform mentions one application (Real-time 3D) where perl may be akin to using a screwdriver on a nail or maybe a hammer on a screw.^**

^* Okay, you may or may not be able to re-write the linux kernel in Perl or VB, but I think there are quite few programs that can be. I don't want to start a long thread on whether you can/can not do this with Linux as this is not what this meditation is about.

^** Bad analogies are my forte.