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.

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

I found this statement surprising and disturbing. I disagree. Note, however, that I am a rank amateur, not a professional. Reality might well be different for a professional programmer. YMMV

It seems to me that programming has many language metaphors because writing a program is very much like creative writing. You have a certain "thing" you need to say. It should be said effectively, efficiently, and - if possible - eloquently.

First and most important, it must be effective. There is no use writing an efficient program if it doesn't do what you want it. As you stated it, it must get the job done.

Next, it should be efficient. Here you have a less definite goal, because "efficient" can have different measures. Sometimes it's important to make things happen as quickly as possible, in real time - and this could result in highly optimized code that is almost illegible to humans. OTOH, you might value programmer time (both developers and maintainers), and opt for a slower program that is easier to write and maintain. It might even include making it efficient for the user to use. These three goals often are in direct conflict with one another.

Finally, and this is probably a luxury only amateurs could afford, is "eloquence" - the vaguest of the three terms. To me, the one-liners that people often write, that do things for which I wrote a whole script - that's eloquence.

Even omitting eloquence, it still requires creativity to write effective and efficient code. There are decisions to be made, conflicting goals to resolve, unanticitated obstacles to be overcome, all making programming something a bit more than writing obituaries. This requires creativity, IMNSHO. It's not "artistry", not writing obscure code, but it's creatively seeking the optimum solution for the given problem set, within the allowed time.

Finally, though clarity and usefulness shouldn't be sacrificed, there is nothing wrong with enjoying your work. Cranking out line after line of dull, uninspired code may be what bosses are looking for, but that's likely to drive away the most creative people. You'll get your code, but probably no more than that. For many purposes, that's all you need - but that's not where innovation comes from.

I think that some excitement is needed, some fun, "power", "freedom", all that kind of good stuff. Creativity and playfulness seem to be where new ideas are nurtured and developed. You probably don't need new ideas when writing a payroll program... but certainly programming and programs have not yet reached such a state of perfection that we can say, "everything is finished, no need for new ideas".

Oh, and BTW - Perl Monks *is* something like a poetry group. Often a solution is offered here that is both effective and efficient, and occasionally even beautiful - eloquent, as I say. For the working programmer who just wants a solution, there are solutions. For those who want the extra icing on the cake, freedom and creativity and such - well, they can find that here, too.

Programs are supposed to: (a)get the job done ...

Well, now you've taken all the fun out of it. :-P

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.

Hi, [id://chromatic]. I'm not certain what point you were trying to make here. Suggesting that some features are missing from all languages, doesn't negate the value of the ones they do contain. There is a place for, say, strict type checking, and Perl doesn't require that. Other languages do. They are probably a better choice in some instances.

Perhaps your point was that no language features can substitute for adequate code review and testing. This is true. Even so, code review and testing do not prevent disastrous bugs from getting through to production. Review alone doesn't catch all the bugs. Relying on language features doesn't catch or prevent all the bugs, either. If I had to choose *only* one safeguard, I'd opt for code review and testing, having many eyeballs look over the code. But refusing to use other available tools is (IMNSHO) taking unnecessary risks. Just because there are laws and police to protect my property, doesn't mean I leave my doors unlocked.

Understand that I'm not being critical of Perl. I love that language, and it's almost the only thing I use. Still, it isn't perfect, and it isn't necessarily the best language to use in every situation.