Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jdavidb (1361)

jdavidb
  (email not shown publicly)
http://voiceofjohn.blogspot.com/

J. David Blackstone has a Bachelor of Science in Computer Science and Engineering and nine years of experience at a wireless telecommunications company, where he learned Perl and never looked back. J. David has an advantage in that he works really hard, he has a passion for writing good software, and he knows many of the world's best Perl programmers.

Journal of jdavidb (1361)

Wednesday January 09, 2008
10:44 AM

The Right Way To Do It

[ #35341 ]

Perl's mantra, TMTOWTDI, has been decried all over the rest of the programming world. Allowing people the freedom to choose from many different ways of doing things is a recipe for disaster, we're told. Code will come out terrible and unmaintainable. Programmers will all speak separate, incompatible dialects of Perl. Most of them will look like line noise.

Those of us who have been around awhile know that the reality is different. Many good Perl programmers have some degree of obsession with seeking The Right Way To Do It. When faced with a task, they take some time to think carefully about selecting the right modules from CPAN for the task. When writing a block of code, they take some time to think about how that block is going to look. Without even thinking about it, they reject a multitude of possibilities for spewing that code out, because they are good programmers and they would never write something that will cause themselves or others trouble later on, if they can help it.

They know that sometimes it's going to become necessary to let business needs override perfection, and they'll compromise and write the code before they've finished determining the Best Way to do it. But they feel a pang of regret over this. And if the Right Way pops into their head later (say, in the middle of the night while sleeping, or on an evening walk, or halfway into a luxurious vacation), they will make a note of it and look for an opportunity to go back and do it right later. At the very least, if they know there will never be a chance to reimplement, they'll realize the lesson learned, and they will use it the next time they do something similar.

For the most part, coders I've met who prefer other languages don't seem to work like this. Many of them had their skills cranked out assembly-line style with a few classes or quick-learn books. They don't keep looking to add new ways of doing things. They don't keep abreast of developments in the community for their language (if they have one) that would make them better programmers. And when they code, they spend little if any time thinking about the right way to do it. They just throw it together in the first way that works.

As a result, in my experience, it's been the Perl code I've had that is readable, well-designed, and maintainable. It's been the Java code I've seen that is ugly, poorly-designed, and unmaintainable. There are certainly exceptions to both sides of this. I'm persuaded at the moment that the Java shop I'm working in is largely an exception: we are thinking about the right way to do things, and apparently have been for a long time. And certainly I know that a lot of Perl programmers are not at the level where they think much about the right way to do things, and so a lot of the Perl code in the world looks worse than most of the Java I saw before I got here.

TMTOWTDI is probably a great philosophy for language design. I don't know and can't say; I'm not a good language designer at all. (I wish I'd known and admitted this back when the Perl 6 idea was new and I tried to jump in with both feet and "help.") What the Perl-haters don't seem to get is that this is a philosophy of language design for Perl, but that for great Perl programmers, it is not a philosophy of daily programming practice. We are not coding chaos. In fact we are coding things that look much better than what the rest of the world seems to be coding.

My theory is that TMTOWDTI as a language environment causes programmers who live there to realize that they should take time to think about the different ways of coding available to them, in order to select the best way possible in the time available. Other languages lead people down the way of thinking that there's only one possible way to write the program, so the first implementation that occurs to them is the one they write. Why think about a second or third way to do it when there's only one way to do it?

Of course the reality is that there's not only one way to do it. My recent study of Java Swing certainly shows me that. There are five or more different methods of telling your Swing application to exit the JVM when your main JFrame is closed. I recently wrote myself a little essay to remember them and explain which options I thought were better programming design. I wonder how many new Java programmers do this, or anything like it.

TMTOWTDI is anarchy. It scares people who want to keep order by force. What they don't realize is that liberty (another word for the true meaning of anarchy, which is simply Greek for "no ruler") results in order. No wonder I finally became an anarcho-capitalist, believing that elimination of rulers at the political level would result in the optimum and most prosperous social order for all. I've been seeing that work itself out in programming for years.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • What they don't realize is that liberty (another word for the true meaning of anarchy, which is simply Greek for "no ruler") results in order.

    I am pretty sure that history would prove that wrong over and over again. Anarchy does not in any way result in order. Which is probably why the dictionary definition means disorder.

    Or maybe I didn't get what you were trying to say.

    • Nope, I don't jest at all. I'm quite serious, and it looks like you did understand what I meant. Spontaneous order does result from liberty.

      It's strange to me that we accept as a religious axiom that the spontaneous order which nature produces is more ecologically balanced than what we produce when we interfere, but we don't feel that spontaneous social order emerges in the absence of coercive rule.

      Anyway, even if you don't accept the generalization I make at the end, I've got two examples of spontane

      --
      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
    • I am pretty sure that history would prove that wrong over and over again. Anarchy does not in any way result in order.

      If the first organization of humanity wasn't anarchy, what was it and how can you prove it?

      • Why would I need to do that? I only have to look at history. You see people groups clanning with a definite hierarchy of rule. Even in "primitive" tribes they had chieftains etc. who ruled.

        The first organization very well could have been an anarchy type setup but I would bet (since nobody can prove one way or the other) that it quickly changed into something else.