(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.

Each problem you address is an improvement. You can't always stop a determined idiot, but you can try.

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.

Help! My brain is melting...!

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?

I can't speak to .NET but I've written plenty of Java and a little VB without any tool but a text editor. But then I worked in a *nix/Perl environment before I ever touched Java or VB so I didn't need the crutch - didn't like it actually.

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!

I've written Java without any tools other than vi. An IDE would have made life easier, perhaps; that's the point of an IDE. I wish there were a decent IDE for Perl, but there isn't.

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).

The point of programming isn't to "think creatively", or to excercise "linguistic freedoms". If you want those things, join a poetry group instead!

Programming isn't about creativity; programming is the art of documentation, reduced to terms so simple a machine can understand them.

If you have to be creative, or to "think", then you're not ready to program yet: you're still back at the design phase. First you need to develop the algorithm, then you need to prove it works, and then, once you actually know what you're doing, and how you will do it, you can code it.

But remember, the design and proof of new algorithms is already being done by the CS department at major universities, by people who are probably smarter than you will ever be, and what you're out to prove has probably already been done. There's not a lot of room for creativity; because "novel" is the opposite of "tried and true".

Code is supposed to be boring, and obvious. It's supposed to be obvious what code does; like a well written piece of tech writing, good code doesn't look hard to write -- the point of each line is obvious, and they fit together in a clear and cohesive manner to explain a concept in a clear and unambigous way.

It's not supposed to be fun, or challenging, or interesting. Programs are supposed to: (a)get the job done, and (b)to be understandable and maintainable (ie. as simple as possible)

That's it. That's all. No fuss. No drama. No chest-puffing, or whining about "power", or "freedom", or "creative expression", or other unrelated concepts: just code that works, and is correct and obvious.

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.

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

In cases where adhering to standards is critical to the project, Perl might not be as useful as some more restrictive language.

Which programming language in use or existence today mandates the use of meaningful identifier names? How about test coverage? What about well-factored functional units? Non-duplication? Effective and usable documentation?

If you can't perform code reviews and have your team adhere to minimal coding standards, use that language.