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

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.)

  • Comment on Re: TMTOWTDI... and most of them are wrong

Replies are listed 'Best First'.
Re^2: TMTOWTDI... and most of them are wrong
by biosysadmin (Deacon) on Jun 27, 2005 at 04:40 UTC
    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. :)