Due respect noted. IMHO, your statement is wrong. You can have any combination of the three factors. You can also have many shades of grey, such as code that is 90% clean and 80% useful which may be chosen over code that is 95% clean and 60% useful.

> I can certainly sympathize that having
> working code condemned as a bad example
> is painful, but I'm prepared to learn
> from my mistakes if there's a better
> way to do something.

I too enjoy learning from mistakes. My point is not that I reject criticism but that I reject a community that is poor in its maturity about giving criticism. After awhile, and I did so for many years, it just gets tiring.

Case in point...you say..."if there's a better way to do something." In it, there is the underlying suggestion that you feel that I have done it in a less than 'correct' way.

What can I do about this argument? It is fundamentally against one of the foundations upon which Perl was built which is that there is more than one way to do anything. Yet it is an argument that I constantly see.

While I am not a complete relativist, I do believe that there is nothing cut and dry in programing and that people who worry about "the better and best ways to do things" are often focussed more on algorithms than on people or business. Not that this applies to you, but just that generally I have foun this to be true, ESPECIALLY in the Perl community which in my qualitative experience tend to be much more snobby than the Java and COM communities.

I believe that having code that is legible to a manager can be just as "desireable" as having swank algorithms.

People who think there is a better way to do it usually mean that there is a more effient algorithm to do it. Taking a three line REGEX and compressing it to one for example.

But to me, their code is to various degrees more cryptic.

Many times, their code is so much more cryptic that the code is no longer legible to a manager....or to a beginner....or to an intermediate....or sometimes to other gurus.

In my world, as a pointy haired boss, I sometimes prefer the slower algorithm that are more supportable for certain types of code and efficient, fast code for other types of code.

This can be for one of many reasons. For example, suppose the price of hardware acceleration is FAR cheaper than software support and training. What should the business do? Especially given that 9 out of 10 software projects fail and that technology undergoes a revolution every 3 or 4 years.

Code quality will depend on a zillion factors and to me is often 100% in the eyes of the beholder.

But in the Perl community this is too often not the case. In the Perl community, sometimes in the last 6 years,this all changed. The community as defined by Larry Wall went towards the specialist in a glass tower. Algorithms, in my own personal experience with the community, have suddenly become more important that solving the problems. And those of us who prefer to be mediocre at code and excellent at solutions are derrided as either ignorant, dangerous, or bad programmers.

I can take criticism like the rest. Please don't turn this into some personal immaturity (although my reaction to being called ignornant was) :)

My point is that the Perl communnity should take a look at itself and ask why someone who was such a staunch supporter for many years should be fed up.