in reply to TMTOWTDI... and most of them are wrong

Three fundamentals come to my mind thinking about programming: After much reading here and elsewhere, I decided to put them in the above order.

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.

Flavio
perl -ple'$_=reverse' <<<ti.xittelop@oivalf

Don't fool yourself.

Replies are listed 'Best First'.
Re^2: TMTOWTDI... and most of them are wrong
by Anonymous Monk on Jul 01, 2005 at 18:49 UTC
    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