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.
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.
Re:Surely you jest...
jdavidb on 2008-01-09T21:26:17
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 spontaneous order emerging from liberty: ecology, and high quality Perl programming. The point about high quality Perl programming was the main point of my journal entry. You may not accept that all order which emerges from liberty is superior, but I hope you'll agree with me that there are many really good Perl programmers for whom looking for the Right Way to do a particular task is an important value, despite the value of TMTOWTDI, and I think there's a relationship between those two values.
Re:Surely you jest...
sigzero on 2008-01-09T22:16:54
I will agree with your Perl points absolutely. : )Re:Surely you jest...
chromatic on 2008-01-10T00:14:06
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?
Re:Surely you jest...
sigzero on 2008-01-10T12:38:43
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.Re:Surely you jest...
Aristotle on 2008-01-10T14:32:16
anarchy [that] quickly changed into something else
Q.E.D., no? Order arose from disorder.
Re:Surely you jest...
sigzero on 2008-01-10T16:04:07
* DING *
