Tom has contributed to p5p and Perl 5 for years. I think you may be mischaracterizing the person when you ought to focus on the argument instead.

You say he has contributed to p5p and Perl 5 for years, but the quote,

Perl really is a write-only language, and you just can't do production work write-only -

is just a dumb statement. If he is willing to paint Perl as just a write-only language you cannot really be suprised that someone is painting him as a j***a** whatever his contributions...

Perl is a language that a:

(a) philosophically, categorically refuses standardization ("There's more than one way to do it")
(b) has multiple meanings for each function call("context")
(c) is chock full of single character "special" variables that don't behave like normal variables (and the meaning of something as simple as "evaluate this variable" can change via tie() anyway)
(d) has an interpreter that "guesses" the meaning of a construct rather than a clear language standard... the motto is "try it in Deparse and then you can find out what it does"
(e) provides multiple features to allow programmers to alter the meaning of the code being run based upon run-time computations (autoload, eval, symbol table manipulations, coderefs, code filters, ties). Code can't be read in isolation, because what it means depends on what's been executed previously.
(f) can only be probabilistically parsed by anything other than the perl interpreter, because of point (d) above, leaving code management tools to guess and pray.

If that doesn't qualify as "write only", what language does? The only languages that I

The only way to make perl less "write-only" is to write coding standards to prevent abuses, and scale it back into a manageable language again.

However, part of the point of a higher level language is to enforce good coding conventions automatically: for example, no access to pointers in Perl means no pointer errors, even though programmer discipline, and "don't hire monkeys" should prevent pointer errors in C and assembly language. But traditionally, it hasn't.

Replacing human error with machine precision is exactly why we moved from assemblers to compilers in the first place. Then again, I'm sure a ton of people will now protest that "Assembly Language is not write only", and only a "j***a**" would think so...

*sigh*

However, part of the point of a higher level language is to enforce good coding conventions automatically...

... and then the universe makes a better idiot. Read The World's Most Maintainable Programming Language.

As for the interpreter guessing, well, it does not flip coins. There are deterministic rules, even if they’re not easy to determine for anyone other than the interpreter.

As for tie, autoloading, eval and the like, these are features – whether you consider them evil or not. Make a language without them, and you end up with an abstraction glass ceiling that you can look through but never get past – like Java. As a result, Java programs grow superlinearly with the number of features and functions they support, with absolutely no recourse unless you start adding preprocessors to the mix, which, as we all know, are evil (or something like that; the JVM’s source code itself contains multiple ones, but hey, do as they say, not as they do).

Heck, even Java overloads the meaning of + for String objects. It just doesn’t let you use that ability for your own code, because you’re a dumb lowly programmer and not to be trusted with dangerous tools. The result of that glass ceiling is that in order to restore some sanity, the language grows absurd insanities like generics. Funny, it’s starting to look as complicated as C++.

I’ll not say a word about the positively byzantine standard library.

Have you heard of the Waterbed Theory?

Makeshifts last the longest.

I was prepared to argue this point my point, but by the time I got to the end what this really came down to was tools. Perl does not have a lot of good tools (IDE's if you will) to do the work for you.

I have used several code management tools for Java, and VB and .NET. The common theme is that you cannot write your programs WITHOUT the tools! It is a crutch that these programmers rely on because they cannot program without one.

Think about it, can you really quickly and effectively write or VB or .NET code without using Visual Studio? How about writing a Java program without Eclipse or some other Java IDE? The IDEs hide so many complications from the programmer, they would not even know what to do without one! The language is designed to keep the programmer from thinking, being creative and you pervert this into good coding conventions( or GW Bush thinking, to protect our freedoms we have to give them up).

A Perl programmer can write a program with Notepad, VIM or EMACS or an IDE like Komodo, you are not crippled as a programmer without an IDE. Perl does hide somethings from you, but it does not take it away, which is what you seem to advocating.

All of what you say is true. Perl does offer may freedoms that can quickly lead to disaster if you abuse them or don't know what you're doing - and since we're human, we *are* going to make mistakes and create disasters. IMNSHO, that's what makes programming so much fun - I never know when I'll do something spectacularly bad.

I think there is a tension between two competing forces, safety and power. Some languages are so safe, you can't get things done with them (that's an exaggeration, but they can be frustrating to use). They keep you in a sort of Barney-land, where there are no sharp objects and everything is purple. Other languages are like juggling chain saws. They're downright dangerous.

Perl seems to be a good compromise. It gives me enough power to get things done, without (always) erasing my hard drive. As you pointed out, Perl's attitude towards pointers has helped prevent me from executing my data, often something to be avoided.

What I like about Perl is that I have a choice as to how much discipline I'll use. I can follow good practices if need be, but I can also ignore them and play with fire. This works for me - a lone amateur - but it probably would not work for a team, without there being someone to enforce some rules. In cases where adhering to standards is critical to the project, Perl might not be as useful as some more restrictive language.

Much as I hate to say this, Perl isn't the best language for every project. In a large project with many programmers, you are likely to have a wide variation in skills, making it imperative that some order is enforced from "on high". If it's already built into the language (and can't easily be circumvented), then perhaps Perl wouldn't be as good a choice.

Still, I find the idea of Perl being "too rich" to be something like complaining that your job pays too much money. Oh, well...