Anyway, if you read up on the design of Perl 6 since then, you'll discover a lot of things that will (hopefully) make Perl 6 a good language for both the wizards and the non-wizards. There's a lot of power in Perl 6, but we've tried to add that power in such a way that people just trying to get their job done are unlikely to fall into traps. In particular, the entire OO design is based on the notion that there should be one fairly complete and fairly standard way to do OO in Perl 6, so that people aren't obliged to roll their own OO systems. The hooks are still there underneath to break out of that, but ordinary folks aren't going to be tempted to do that if the standard way is nice enough, and just sort of "lays under the fingers".

Perl 5 has a lot of power too, but it tends to make all the options equally likely. It's almost too orthogonal in that respect. In contrast, Perl 6 gives you a default OO system, a default switch statement, a default exception system, a default grammar system, and so on. It gives you standard ways to extend the language without negatively impacting other people's code. Concepts that are confusing in Perl 5 because of excessive overloading are detangled in Perl 6 by use of separate keywords or operators. You can define your own operators, but we try to give you most of the operators you need by default so that you don't need to define your own except for specialized needs. And, of course, strictures and warnings are on by default (though you can still turn them off).

In short, Perl 6 is designed to be just as good for small programs, and much, much better for large programs. People can still write screwed up Perl 6 code and put it into CPAN, but it won't happen by accident nearly as often as it does in Perl 5, and even when it does happen, you'll be much better isolated from its effects because Perl 6 takes lexical scoping much more seriously than Perl 5.

Since the language is designed to much more mutable, it's actually quite likely that stricter subsets of Perl will develop and be enforced by local policy. I doubt ANSI will ever get involved, though. If such a dialect arises it will be by common consent of the community that uses it, not because some standards body decided it knew was good for the community.

The presumption here is that those languages that seek to restrict the idioms and modes of use to some subset of those possible, can and will force the programmer to produce more correct code with less bugs.

History does not support this presumption.

Whilst compile-time type-checking, declarative method and attribute visibility, compile-time bounds checking and a host of other compiler enforced restrictions will often allow many trivial source code and logic errors to be detected early, these are often the same errors that would be detected early anyway, whether through rudimentiary unit or system testing.

Some other diminutions of programmer responsibility can pragmatically reduce the scope for programmer error, especially in those areas that require the programmer to remember to perform certain, often rote, mechanical actions across functional boundaries. Eg. Memory management. Cleanup of memory is often called for at points in the code well away from the allocation of that memory. This is true for procedural code and even more so for OO code. This type of responsibility often requires a quite long-term overview of the flow of the code, and the life of the allocated objects. And it is often well divorced from their instanciation and the main points of use. These kinds of responsibilities benefits from the computers ability to perform rote actions reliably and rigourously. Hence, automated memory management (GC) is usually a big win.

However, many other areas of a programmers skills are less ameniable to automation, and in many cases, those types of compiler enforced restrictions can actually inhibit the programmer from pursuing and achieving elegant solutions.

For example: I've been trying to get to grips with FP languages. These mostly have a strong element of type safety. This is usually seen as a good thing, and when writing code that fits into "known algorithms", I would agree that it does, but there is a downside. It tends to also enforce a bottom-up approach to coding!

It is very difficult to write top-down code where, in the early stages, many elements of the solution one is seeking are unknown. With a relaxed language like Perl, it is very easy to "mock-up" the lower levels of a program as you don't have to specify the types, or numbers of the parameters of functions. Indeed, you don't even have to write the functions (methods) so long as they never actually get called. This can be a great advantage as it allows you to use a very pragmatic approach of "at this point in the code I need to determine if xyz() is true. So you simply code that. If the logic of the code means that xyz() never actually gets called, then you do not even have to code xyz().

This allows you to start with the top level premise of the code and, what basically amounts to , pseudo-code your solution, in a top-down manor. Often, you will never get around to coding xyz() because having mocked up the top level of the code and "proof-read" it (with perl -c prog), you realise that the logic of xyz() is better incorporated into pqr(); or that there is no way that you will have access to the parameters that you would require to determine xyz() at the point in the code where you coded it; or that actually there is no need to determine xyz(), because it's results naturally fall out of logic that precedes the point where you need it.

I arrived at a maxim about 15 years ago that has stood me in very good stead ever since:

Define top-down; Refine bottom-up.

Start with what you know: Available inputs and required outputs and define--as a function--what you need to transform the former to the latter. Within that, repeat the same strategy.Decide what you need to produce the return value and what forms your inputs at that level. And so on down.

The beauty of Perl, is that it makes doing this very easy. The absence of parameter and return typing mean that you can easily mock up a function that takes nothing and returns a (hardcoded) something that is exactly what the calling code needs.

sub doSomething{
    return 'Whatever's needed';
}
[download]

This truely makes for rapid prototyping. Defining functions is so cheap that is encourages you to do so even if you are 95% sure that you will later discard it. And once you know you will keep the function, you can, slowly, refine the constraints that you impose upon the parameters, as those constraints become clear. And, if the application warrents it (ie. It's more than a one-time script, or the demonstration of the prototype incites further investment of time and/or money), then you can refine the constraints, bottom-up, to achieve the level of reliability commensurate with the application.

Of course, how much energy will get expended on that refinement depends upon two things: The thoroughness of the programmer; and the perceived value of the time expended.

When it comes to "trusting the programmer", it is just as possible to do only the minimum required to satisfy the compiler in an 'enforcing' language, as it is in a relaxed one like Perl, and the assumption that code that meets the minimal requirements of the enforcing language is "good enough", is a very bad assumption.

Even with the best will in the world, the programmer can just as easily believe that he has understood the requirements of the application, when s/he has actually misunderstood them, when using an enforcing language, as when using a relaxed language. Indeed, I would say that the enforcing language has the ability to delude both the programmer and his customer into believing that if it compiles, it must be correct. This is, and will always be, a bad assumption.

For the sake and sanity of both parties, the only thing that can be trusted, is an accurate specification and correct tests of complience with that specification. Any other criteria for judging the correctness of code will always be subject to debate, misinterpretation and misuse.

Regarding your claim about FP languages:

[FP languages] mostly have a strong element of type safety. This is usually seen as a good thing [...], but there is a downside. It tends to also enforce a bottom-up approach to coding! It is very difficult to write top-down code where, in the early stages, many elements of the solution one is seeking are unknown.

Are you extrapolating too much from personal experience? Because you find top-down coding in FP languages difficult doesn't mean that it is in general. For instance, I work almost exclusively top down when I code in Haskell, and it seems effortless. Could there be another explanation for your experience?

Tom Moertel : Blog / Talks / CPAN / LectroTest / PXSL / Coffee / Movie Rating Decoder

Yep! There are several possible explainations I guess.

• I've been reading the wrong "worked examples".
• I (still) haven't done enough Haskell to have extablished a good approach to programming with it.

  Perhaps you could show me the steps you would take to tackling the sort of problem I have been trying to get to grips with?

  For the purpose of the exercise, I decided to index the words in a bunch of files. To get a start on the exercise, in Perl, I decided to just count the words, here simply defined as whitespace delimited groups of characters, and write the results to a file. This allows me to get something going and I can then work on refining the definition of a "word" and and decide how I am going to store the index.

  My first attempt at writing this program (from scratch, just now) was:

  #! perl -slw
  use strict;
  use G; ## Expands wildcards arguments as would be done by most *nix sh
  +ells.
  
  our $INDEX ||= 'words.index';
  
  my %index;
  if( -e $INDEX ) {
      open INDEX, '<', $INDEX or die "$INDEX: $!";
      m[^([^:]+):(\d+)$] and $index{ $1 } = $2 while <INDEX>;
      close INDEX;
  }
  
  while( my $file = @ARGV ) {
      open FILE, '<', $file or warn "$file:$!" and next;
      while( <FILE> ) {
          $index{ $_ }++ for split ' ';
      }
      close $file;
  }
  
  my( $key, $val );
  open INDEX, '>', $INDEX or die "$INDEX : $!";
  print INDEX "$key:$val" while ( $key, $val ) = each %index;
  close INDEX;
  [download]

  I then ran a quick sanity check:

  P:\test>perl -c windex-1.pl
  windex-1.pl syntax OK
  [download]

  So far, so good. Now try it out:

  P:\test>windex-1.pl *.pl
  710:No such file or directory at P:\test\windex-1.pl line 15.
  710:No such file or directory at P:\test\windex-1.pl line 15.
  710:No such file or directory at P:\test\windex-1.pl line 15.
  710:No such file or directory at P:\test\windex-1.pl line 15.
  ...
  [download]

  Whoops! A quick look and I see I missed out the keyword pop in line 14:

  while( my $file = pop @ARGV ) {
  [download]

  Try again:

  P:\test>windex-1.pl *.pl
  306836-trietest.pl:Permission denied at P:\test\windex-1.pl line 15, <
  +FILE> line 83342.
  [download]

  Okay, I've got 1 file with bad permissions in the directory. And what ended up in words.index?

  P:\test>type words.index
  expletive:2
  $midVal:30
  9f:8
  proven:2
  AT:10
  happpen:2
  inconsequential:2
  perverted:2
  $x;:24
  TTGGGTCAGCGAATGTCACATTTGGAATGGGAATCGGATGATGGGGGCGA:2
  ++$x):2
  greif:2
  yvvvvvvvvvvhvevwvvy:2
  @exclude_keys:2
  $hh2,:2
  scrapped:2
  classe:2
  sod:2
  $array[2]->set($_);:2
  Cleaner,:2
  $expand_ratio,:8
  CACGTCTCCACCCGAAGACTGTGGAATGCTACTATTAAAATACTATTTTT:2
  cdpr:2
  BLANK_NODE:4
  paws:6
  "\n$_:2
  ...
  [download]

  Okay. The word definition is ecclectic, but is seems to be doing what I set out to do, now I can start to refine it. Not a bad start for 10 minutes coding.

  ---

  Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

  Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

  "Science is about questioning the status quo. Questioning authority".

  The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.

Nice post, if for nothing else than making me think about the topic at hand. I think there's a lot of intuitive appeal to the logic that scary, interesting, and clever code is a detriment to code reuse. But I also think CPAN's success is a testament to that idea being a bit off base.

I won't pretend that I can explain why, but people have been posting idiomatic, obfuscatory, excessively clever, and even downright bad code to CPAN for a long time; yet it still seems to work out pretty well. People contribute. People reuse. The net effect seems to be positive, and a lot of good stuff emerges from the chaos.

I agree, and here's why I do.

CPAN provides lots of ways to Test, and CPAN harnesses testing as part of the build process. The effect is that you don't have to trust people to get it right every single time.

By testing for results you must have rather than having hoops programmers must jump through, Perl and CPAN let all sorts of odd ideas, grand schemes, quirks, mathematical verities, lunatic notions, sacred cows, juicy hamburgers, oracular goings-on, lies, damned lies, divine inspirations, hallucinations, high science, low comedy, and too many other squibs to list, coexist. The cream rises to the top.

Trust is fine, but test and experiment and imagination are finer.

After Compline,
Zaxo

Yes, we have tests. Yes, you can choose not to use modules which have no tests. Unfortunately, there are modules (and I'm guilty of creating some) which have only a minimal "it compiles" test. There are others which are damnably hard, if not impossible, to write tests for, and so you can't really be sure that they have adequate tests even if they have lots of them. And then there are modules which have *thousands* of tests, and you know damned well that they aren't all needed and so get suspicious about the quality of the tests for yet another reason.

Now, there's two ways of approaching this need to trust the programmer. Languages like Java say "I'm only going to trust you as far as I have to, but no further." This may be perfectly valid in some situations. I know that if I'm coding with a bunch of people I don't know, I'd prefer to do it in Java instead of Perl.

On the other hand, languages like Perl and C say "Since I have to trust you, I might as well TRUST you." And, so, they leave as much as possible up to the programmer. The major difference between Perl and C (which is what BrowserUk alluded to) is that Perl provides a lot of scaffolding for you. Little things like automatic memory management, useful types, and dynamic recompilation.

My reasons for this prediction were that corporations and other large organizations have less use for brilliant code that only to a small number of Perl wizards can grok, than for mundanely-written code that even the non-wizard can follow.

This point deserves a special response. There is "brilliant code" in every language that only the wizards can grok. When was the last time you read the Perl source?

My last contract was at a place where the code that underpinned half their applications was truly understood by only 4 people. Yes, others could have come in and studied the code and become experts, if there was a business case to do so (and there are arguments either way). The same goes for the steaming pile of Javascript crap I was handed, as well as any significantly complex application. Just because the code is simple to read doesn't mean that application is simple to understand. And, just because the code is hard to read doesn't mean the application is hard to understand.

Remember this - reading code is hard. If it was easy, then no-one would pay use the big bucks. It's not supposed to be commotitizable. If it was, then outsourcing would actually work in the average case.

First off, your title. I disagree. TIMTOWTDI, and, by definition, they're correct - for some situations, and not all of them are applicable to a given situation. There are "solutions" that never work, but I don't classify those as ways to do it, but ways one thinks you can do it. Perl still generally has many ways to do any given task, and this is just counting the ones that work.

Second, as I've said before, the flexibility in perl actually works well in the reverse. In C++ or Java, one presumes that the author of the framework or reusable object (or, in C, reusable ADT - feel free to extend ad nauseum to other languages) is the most intelligent person, and lesser persons use them. For cases like the Standard Template Library, this may very well be true. For most other reusable software, well, maybe not.

In perl, due to the DWIMery of the language itself, its pure dynamic structure, you can actually have a module written by someone with less than 12 months of experience be used in ways they didn't imagine by someone with 6 years of experience, mostly because the original author didn't check parameters very well.

I take this flexibility that Anno complains about exactly the opposite way.

Besides, I've been known to hack C++ header files to change functions from private to public just because they never should have been private in the first place, IMO. Does the fact it's C++ make me, the end-programmer, any more trustworthy? ;-) (I was a student programmer at a small software development company at the time... I'd be very careful before trying it again, but I just wanted to point out how easy it is to hack those other languages in non-trustworthy ways, too.)

Having taught a course in Perl for a couple of years at school, I was consistenly amazed at the number of weirdly thought out programming ideas that my students came up with. For example, I once had a student who wanted some help thinking out a programming assignment. The task was to write a subroutine that took a 3-letter sequence of DNA, and translate that into the corresponding amino acid sequence. I gave it as an exercise in using hashes (which I had just lectured on that week). Basically, the student wanted to use two arrays of DNA and amino acids as an associative array, so that to translate AAA to amino acids, you would look up the array position of the AAA element in the DNA array, and then find the amino acid at the corresponding position in the amino acid array. To me, this is a perfect example of a "way to do it" that shouldn't be used, because:
• It's not as efficient as using Perl's built-in hashing-function.
• It's significantly harder to read and understand for other programmers.

A quick re-hash (hah!) of the lesson on hashes set the student on the right path.

Anyways, wrongness is in the eye of the beholder, but I think that it's a good idea for a programming language community (whether it be a work environment, a course, or a site like PerlMonks) to recommend and enforce some sense of quality in programming.

I wouldn't cite C or C++ as hallmarks of programmer discipline either. I've seen some stuff with pointers that would make my CS professors absolutely cringe. :)

Note that we have very little evidence that Paul Graham is a decent programmer. His chief accomplishment was selling an e-commerce startup during the Internet gold rush. I'm inclined to take his opinions about what makes a good programming language with a grain of salt.

I'm curious - what would you consider evidence that someone is or isn't a good programmer? I'd be willing to bet we could find a number of examples of his code somewhere on the Net. Granted, it probably won't be in Perl, but I'd bet the code would be pretty decent.

Likewise, the same argument could be made for Larry's code. I mean, his biggest accomplishment is almost 20 years old. How much of Perl5.8 or 5.6 did Larry actually write? He's just a designer, right?

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Note that we have very little evidence that Paul Graham is a decent programmer.

What about his book on advanced lisp techniques? It's pretty much the lispers bible about macro usage. Or how about his ANSI Common Lisp book. Don't those count as considerable contributions?

I'm inclined to take his opinions about what makes a good programming language with a grain of salt.

Take as much salt as you need. Of course, I'm skeptical that anyone who thinks map is a difficult concept to master would be able to recognize a good language.

But although this was all about OOP, I think the same argument can be reasonably extended to programming in general.

In this particular instance I don't think it can. The problem with OO in Perl is not so much TIMTOWTDI, but that there aren't enough ways to do it :-)

Basic encapsulation is much harder than it needs to be in Perl. There are not "natural" ways of doing it. Sure you can do it with inside out objects and code refs, or using one of the many different CPAN modules - but it's a lot more complicated than it needs to be.

Compare to Ruby or Perl 6 where there are language constructs that support encapsulating state and hiding implementation naturally and simply.

Ruby and Perl 6 have more ways of doing good OO than Perl 5, not fewer. However since these mechanisms more naturally support what people want to do you end up with clearer code. Which is as it should be.

The problem isn't too much freedom, but lack of features. TIMTOWTDI is only causing problems because different people have invented N different ways of getting over the lack of features and they don't always play nice together.

I suspect that the philosophy behind Perl 6 is not very different from that behind previous versions of Perl:

It isn't. However Perl 6 makes many of the things that were hard in Perl 5 easy by providing more and better tools.

I'm pretty new to Perl, but its key attraction is how much you can do with how little. I think Perl loses a lot of its advantage when you a start writing large chunks of code with it.

To misquote a little: Easy things are quick and hard things are possible. Although hard things are possible, they may take a long time and be troublesome to get right and to maintain. Other languages that provide more type safety may prove better in the long run than Perl for "hard" or large projects.

Good programmers can write good code in pretty much any language. Bad programmers write bad code in any language. Average programmers who are trying really benefit from the discipline imposed by some of the heavy duty general purpose languages like C++.

So, I don't think "standard Perl" is likely to be a crippled Perl. It would be nice for use strict; use warnings; to be default behaviour (for script, but not for one-liners) to make it harder for "bad programmers" to write bad code. Perl should continue to make easy things easy (and quick) - hard things are likely to be hard no matter how you do it.

I think Perl loses a lot of its advantage when you a start writing large chunks of code with it.

From my experience, length has nothing to do with things, for the most part -- any large chunk of code is just an assemblage of small chunks of code. Of course, because you can do so much with so little, some people may try to use techniques that they would use for throw away scripts for larger programs.

Larger programs take a different mindset on the programmer's part -- making sure that you choose effective variable, subroutine and package names; adequate comments and documentation; etc. I don't think the language plays as much as a factor as the programmer in these sorts of situations.

From my experience, the main issues that I have with Perl are when assumptions are made, that you may need to supress -- like autovivication, or that a scalar can hold a number, string or reference, or that the first argument to print may be a filehandle.indirect object syntax with print

I've never found that I couldn't work around any of the problems that I've had, but there are times when you're writing something, and things don't behave as you expected (this tends to happen more with non-core modules -- I've lost way too much time redoing large chunks of the serializer in SOAP::Lite so that it behaves how I prefer it to work.)

In times like this, I have yet to find that I couldn't work around the issues, but it can be a time suck, as you sift through documentation, websites, the code, etc. -- this is the time when I find I lose any advantages.

A few times, I've had to change my logic to more closely mesh with the modules that I'm using, or otherwise rewrite large chunks of it, but I've never had to give up and move to a completely different language. (well, for some web-based stuff, I'll use JavaScript, too, or use PL/SQL for Oracle stored procedures, but that's been because of how I thought about the problem, not because I tried to do it in Perl, and failed).

Update: I realized I probably shouldn't have singled out SOAP::Lite in the above example, as the reason I had to rework the serializer was to get it to work with a Java toolkit... so in a way, it was actually Java's fault that the Perl wasn't working.

Update: revdiablo reminded me that technically, print doesn't take a filehandle as an arg -- it's a different calling syntax. So I'll complain about indirect object syntax in general.

... an expert who wants to be able to comfortably use code written by others would prefer if the language in which this code was written left little room for screw-ups.

I'll be the first to admit that my experience with programming languages is limited in breadth (let's just say FORTRAN, C, Perl, with small amounts of emacs-lisp and java, and passing exposure to Python and C++). But I have never seen, and do not ever expect to see, a programming language that leaves "little room for screw-ups."

The ability to "comfortably use code written by others" depends much more on the clarity of docs and specs and the use of appropriate tests, than on the particular language being used. In these regards, I don't see how Perl is at any sort of intrinsic disadvantage.

He is saying that Perl's freedom is in a very real sense working against the goal of CPAN, and the goal of code reuse in general.

I disagree with your title, your interpretation of Anno's post, and I wonder what you think the goal of CPAN is.

If you want to embrace OO perl with enforced this or that and coding standards and whatever "professional" subset of perl you decide on - and the elitism inherent in these ideas - so be it. It's your choice.

However, perl is used by tens of thousands or people who couldn't care less what accessor methods you or Anno use, or who don't even write OO perl. And you know what? They've just as much a right to use perl and CPAN as you do, and they determine whether code passes muster the same way you do: they use it. As far as a hypothetical programmer or manager choosing X over perl ... I don't see that happening. Maybe you do, but I don't think it's appropriate to blame perl for being flexible. I'd blame the programmer or manager for being short-sighted.

In other posts I have speculated that in the future maybe a more limited and strict dialect of Perl will emerge as the standard (ANSI Perl?), and that corporations and other large organizations will choose this limited Perl over the richer, more idiomatic "common Perl", which in turn will gradually become relegated to the "private sphere."

I think one factor that will always act as a counter thrust to the dumbing down of perl code is speed. Common perl is much of the time faster as it tends to be opcode efficient. While everybody likes to pretend efficiency isn't a factor the truth is that performance matters, and style guidlines will go out the window as soon performance becomes an issue. The trick is knowing when and where such tactics meet an acceptable cost/benefit level. Also most times when people discuss comparing languages to Perl they usually fail to discuss the implications of the fact that in Perl you always have access to the full code base, something that is often not true of "the other language". Imo this has ramifications that are often underplayed or just outright overlooked.

Safe, foolproof programs are like "The Holy Grail".... always to be sought after, but never found.

In other posts I have speculated that in the future maybe a more limited and strict dialect of Perl will emerge as the standard (ANSI Perl?),

• readability and its tight mate, mantainability
• correctness
• efficiency (in a wide sense)

Maintainability should be a primary goal. This is what allows you to modify the code in response to a bug or to add new features without screwing all things. Consequences are that the code is testable, and if you don't succeed in writing tests you should seriously think about changing the design. Now, Perl's expressivity allows me to write pieces of code like they were pseudo-code or plain english. (Well, I'm probably better with pseudo-code :). With respect the first bullet, I prefer to speak in Italian, then English, and I'm not willing to learn Esperanto. This is because the first two languages allow me to completely express my thoughts in a concise but exact way, while the last one would probably require more sentences to express difficult concepts - which basically breaks readability and maintainability. Today, you don't program Assembler if you don't really need it, and if you do you try to restrict this to the very tightest 5% of code that sucks up 95% of resources.

Then it comes correctness. At the second plase, IMHO. Because, like Asimov's laws, you shouldn't sacrifice maintainability for correctness. This does not mean you cannot use clever tricks - only that you can use them when you thoroughly document them (which kinda allows you to swap the two bullets). As brian_d_foy pointed out, we're always going to write crap that isn't correct, so why should correctness be the most valued virtue? We will have more space to make it definitively correct if it is readable and maintainable. Agile software development practices seem to second this, because they redefine correctness in the sense of what lets you pass the tests, so again readability and maintainability are considered top goals.

As for correctness, I think that only semantic correctness really matters when discussing of languages in general. In Perl, you have tools (like warnings and strict) to deal with other kinds of errors. Yes, a wider degree of freedom allows you to make errors at more levels of abstraction, but on the counterpart I answer that you can keep the big picture better when you don't have to dive in all details. So, I really don't see why a Perl program should be less correct than a C++ one.

But there's more about it. I feel (almost) comfortable with English, which is not my mother tongue, because I think that most of the times I succeed in the communication process. This doesn't require me to really know all rules and inflections. In Perl it was the same: I haven't effectively used map for a long time, but when I discovered it I started peppering my code with it. It's a compact idiom, and it lets me not only reach the goal, but also communicate it better to others ("Hey, I'm building up some array/hash here!"), which a more "prosaic" for couldn't afford without major attention from the reader.

C++ standard evolution seconds this approach as well: if you look at the Standard Template Library, you'll find tons of algorithms which are quite specialised, many of which iterate over a collection in some fancy way. This isn't something that you cannot obtain with a plain foreach or even a good-ol' for, but you should simply refrain from doing it because of readability. This is a big point for Perl, IMHO, because it shows that the path that other "strict" languages is that of skewness in spite of orthogonality.

Last comes efficiency - no need to write anything for this. But I like to remember that "CPU cycles are cheap, Programmer's cycles are expensive". So, efficiency is not only a matter of how fast your code is, but also how fast you develop and maintain it. Well, C and C++ aren't the best choices 100% of time here, because of the programmer's cycles cost. When I do C++, for every chunk of code I write I *know* that I'll have to face an average of 10 compiler errors before starting to look at the correctness (in the above sense). When I do Perl, most of the time my program is correct from the very beginning, because the language seconds my thoughts, not the contrary. This gives me time to verify correctness more quickly, and to get out for an ice cream while the computer is... computing.

To conclude, I'd like to add only one more consideration. IMHO, cleverness in production code is following the above points, together with other best practices. And I see that a lot of CPAN contributors are clever: you find many modules with excellent documentation and complete test suites - and this all gives you more time to concentrate on the Real Life.

A correct program is one that needs less maintenance (by definition).

Sure, that may be so, but not inherently so.

A correct program that is used in production is soon extended with new features. Success breeds maintenance. So a correct program that fulfills a business need may very well need more maintenance than an unsuccessful one that no one uses.

Also, the business environment may be volatile, which may lead to maintenance in the form of adaptations. That has nothing to do with correctness according the previous specs and weakens your defined correlation between correctness and maintenance.

/J

I guess that this question is not refering to perl directly but to a description of these troublesome times. And is the same reason why so many different languages have appeared as incomplete alternatives.

1) We program as a reflexion of our lives.

2) We don't only think with our heads, but with all our body.

3) This corporate times, only show their heads and resolutions. But when there is a problem, we are not able to find anybody to complain to.

4) We want it all, at no effort. We want to be good programmers now! Everybody is able to become everything by just paying what it is required.

But truth will allways reside in the masses. Linux is going to be better that Microsoft just because a lot of people is trusting in everybodies creativity. And in their own common sense.

As nowadays contradictions shall keep on growing we are going to experience a lot of troubleshooting with programming languages. So, what is the excuse to keep on going through this path of loosers? That the language is not good. That we should study new ones, spend our time learning new experiences that would solve all. Ensure that there are no 'terrorists' programming with that language. Then, the purity of the OS, etc. But, still, contradictions are going to be there.