. . . programmers should be blamed for poor security, not languages . . .

If the language makes the easiest way to do something also the wrong way, then I'd say you should blame the language. For instance, C makes it easy to overflow your buffers. By using a language that either has runtime bounds checking (like Java) or automatic growth of those bounds (like Perl), then you eliminate an entire class of bugs. IMHO, it is reckless to use C in a project that doesn't require use low-level details (which is most of them).

does it not alarm some of you?

I would imagine the same individual would have a lot of problems with languages that force you to predeclare vars by default, and with a static type system. That covers an awful lot of languages.

What can we as a community do to promote higher quality code?

Write good code yourself and share it with others.

I know, but it just irks me. I guess I'm too overprotective of perl. It is ironic however than Slashdot is written in perl

---

Grygonos

It irks me too, but consider this: the ability to write terrible code in Perl and have it mostly work is what made Slashdot happen in the first place.

Why are programmers lazy and/or have a lack of integrity in regards to code?

Why are [insert profession here] lazy and/or have a lack of integry in regards to their work?

Because to some people, it's just a job. Just a paycheck. There is no passion, no desire to improve. As long as the paychecks continue, so does the mediocrity. I can respect individuals who treat their jobs as nothing more than jobs; it's a choice I sometimes envy, for I'd have a hard time choosing it myself.

What can we as a community do to promote higher quality code?

Write more of it, and publish it. Good coders learn good habits by example. (Er, like perrin said.)

People are out putting the reputation of perl on the line with these notions of style and maintainability every day.

Perl's reputation, just or not, for being 'write-only' is already established. Nevertheless, Perl is much too popular (i.e., useful) for people to suddenly abandon it. It's important not to confuse a criticism of Perl with a personal attack on one's ideals -- unless perhaps you are Larry. I've never convinced anyone to use Perl by preaching, but I've made many 'converts' by writing good code.

What can we as a community do to promote higher quality code?

The first thing you would have to do is define what is: "high quality code".

Ask that question of 10 programmers and you'll likely get 11 definitions. I can think if 3 without trying:

1. Code that meets it's specification.

   But if the spec. is bad, is the code good?

2. Code that passes all it's tests.

   If the tests are incomplete is the code good?

3. Code that works. (Or rather, it hasn't failed yet!)

   Is this premature? Immature? Negligent?

   Depends.

   1. How long has it been in operation?
   2. • Does it meet the spec?
      • Does it pass the tests?
      • Is the spec good?
      • Are the tests good?
   3. What is the worst that can happen if it fails?

And of course, any given answer to any of these questions is only as good as the person or process that produced it. How do you measure those?

Forgive me, I guess what I was trying to say was well commented,maintainable,efficient,scalable, and self-documenting is a plus. That's my definition of quality code. To me it should be implied that high quality code meets specification (good or bad, you can always code it better than the spec requires) I agree it should also be able to pass as complete a test suite as can be devised. Also it should always exit as gracefully as possible with as few side effects as possible. Personally that's my definition.

---

Grygonos

because use of Java and the extra effort it requires is a filter which removes all but the cleverest and most hardworking programmers

It certainly removes a lot of the cleverest programmers. In many cases because they don't want to have to work harder than they need to.

What can we as a community do to promote higher quality code?

Here's an idea, we should give up on the elusive grail of salvation through best practices and look to encourage individuals to think for themselves. Less cookbook and more debate.

While some debate is quite healthy, too much debate tends to stop people from getting real work done. If anything, the Internet (and the Perl community in particular) suffers from too much debate.

----
send money to your kernel via the boot loader.. This and more wisdom available from Markov Hardburn.

Why are programmers lazy you ask? Judging from the glut os laughable resumes one can receive when advertising for help, I would say that those type of people are not really programmers at all. Not in the peer sense. They are mearly people who are pretending to be programmers to make money. Charlatans.

But heck, don't worry about /. too much. While it can be an informative site, the signal-to-noise ratio is almost as bad as a sociology class.

Like with perl, I'm not always wanting to use strict and warn; I like not having to predeclare all my variables, for one thing...(and sometimes I'd have to lookup how to predeclare some kinds of hashes and arrays...)

I generally only use strict for larger programs, modules and include files that I intend to reuse, and code that's going on the CPAN for other people to see. Warnings are invaluable, but I can see why someone would want to ignore them: there are one or two warnings that *usually* don't indicate any problem. Most notably, the "use of uninitialized value" warning: if it ever did indicate a real bug in my code, I'd never notice, because after hundreds of thousands of times when it was meaningless I've learned to ignore or work around it. OTOH, if you ignore a "useless use of foo in void context" warning you're almost certainly making a significant mistake. ISTR that Perl6 is going to give us the ability to shut off individual types of warnings and still see the others, which IMO will be very helpful.

As far as bad coding: you can write bad code in any language, or decent code in most languages, that much is true, but some languages *do* make it easier or harder to write good code. Something I like about Perl is that it makes it easier to refactor shoddy but working code into better code relatively quickly; in some cases I've found myself going into the code with the intention of adding features and refactoring things "while I'm at it". Often I write quick-and-dirty code initially to get something working and then refactor it once it's running. I didn't do that in the other languages I've worked in, because refactoring was much more painful. For example, I really liked the Inform language, but refactoring Inform code was excruciating, so it was important to think through the design and write it right in the first place. The same is true to a lesser extent of BASIC and lisp.

Then there's C. If ignoring warnings makes bad code, have you ever seen anything of nontrivial size written well in C? It seems to me that every project of more than a couple thousand lines in C (which doesn't go nearly as far as a couple of thousand lines of Perl would go) has compiler warnings coming out the wazoo. It's epidemic. Whereas, if I grab a Perl module off the CPAN and there are warnings during compile I start worrying about whether the module is low quality or maybe there's something wrong with my environment that's causing the warnings (e.g., something else not installed that should be).

Then again, though, tests run the other way. I've not very often seen an otherwise-working C program refuse to install because it failed one of its tests. This happens all the time with Perl modules from the CPAN, usually because either the test is just plain broken or more often because the test requires some other module to be installed that the module itself doesn't require. When it comes to things the Perl community needs to work on in terms of code quality, this IMO is a major thing. That, and one of the CPAN testers should run everything under Taint checking to catch modules that aren't Taint clean.