J. David Blackstone has a pointed journal post entitled The Right Way To Do It which praises Perl’s “There’s More Than One Way To Do It” philosophy:
TMTOWTDI is anarchy. It scares people who want to keep order by force.
Allowing people the freedom to choose from many different ways of doing things is a recipe for disaster, we’re told.
… 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.
Yet it’s not about Java versus Perl (and certainly not Perl versus Python).
One of my favorite Larry Wall quotes goes something like “Any language that doesn’t occasionally surprise the novice will pay for it by continually surprising the expert.” I’m not sure that it’s possible to write a language in which it’s impossible to solve useful problems with code that’s immediately at least somewhat transparent to someone who doesn’t know the language or the problem domain. (I’ve also never received a serious and concrete answer when I’ve asked someone for a qualitative enumeration of the design features that make one particular language so much more maintainable than another. Enforced brace placement–or brace invisibility–does not count.)
I suppose that if you’re designing a language for the specific problem of “Most working programs should be readable by programming novices” then you can avoid the problem of not knowing what people will use your language to do. Hands up everyone who’s seen a practical, non-didactic Scheme built entirely out of the six or seven core primitives, though.
Don’t get me wrong; there’s room for a strict hand. There’s room for didacticism and narrow garden paths for novices as they learn — but language designers need the freedom to surprise the novices so as to give them more freedom as they need to solve larger, more real, messier problems. As Reg Braithwaite said, A programming language cannot be better without being unintuitive (and see The word “intuitive” isn’t).
We already shape the language of our software to meet our problems when we choose meaningful identifiers. Why not shape the idioms of our programming language to do the same? Maybe it’s time to admit that a distributed team of Perl fans writing a compiler for the world’s most dynamic language has different needs than a close-knit group of four people who’ve worked together for ten years in the bowels of an insurance company schlepping data onto and off of mainframes have very different needs, even if they use the same language and that, even if they use the same language, you can’t just swap two of them without a major productivity hit, even if there’s only one obvious way to do anything in that language.
Maybe we could have that discussion if programmers could discuss how language syntax affects language features and get beyond “I like enforced whitespace” / “I like sigils”. Maybe next year.
To be honest I think both java and perl are ugly languages.
The biggest advantage with there is more than one way to do it is that you can discard the ways you dont want to use. And in this regard, ruby is better.
I still dont use any lambda stuff simply because I felt its just easier to go with traditional objects+messages. I just dont have a use cause where something i needed can only be done with lambda ways MORE ELEGANTLY.
And to be honest, if i can choose between perl and python, i would stick to python - not because i think there is only one way. BUT because _I_ find readability (insofar that the code is clean) much more important.
(I dont like python though because of its implicit "def __foo__(self):" *grin*)
Most (possible all) of the people I know who use Perl (and Python) learned it by choice, while most of the people I know who use Java had little choice at least initialy. It was either the language they learned in college or it's the default in their industry. I wonder if that makes a difference to the way people approach the language.
Interesting question. I think that the primary feature for maintainability (as opposed to conciseness, or control, or what-have-you) is transparency. When a programmer looks at some code, can he or she correctly predict what it will do at runtime?
Some people call this "The Principle of Least Astonishment."
Transparency is a function of the programmer and the reader as well as the language, of course. (Proof: Obfuscated * contests.) So I think that this leads to two questions for the language designer:
Regarding that second point, I think there's some interesting strategies, such as: using conventions programmers are generally familiar with (e.g., C-like syntax in Java, Unixisms in Perl); using mnemonics; keeping the language very simple and putting everything in a library (e.g., C); and making the language verbose so that it "talks" to you (e.g., BASIC, COBOL). I'm sure there are others.
I like sigils, I like C style curly braces, and I like TWMTODI. To me, it's like anything else in life. You COULD do it that way, but it's not always the best way.
I love Perl. I've criss-crossed the planet numerous times just to continue programming in it. When others criticize it for it's perceived weaknesses, I'm always happy to promote it's strengths. When companies get bought out, or get a new technical director, who believes Java is the one true way, I leave (their programmers weren't happy anyway, so why bother?). That's not to say I have but one hammer, and everything is a nail. I just like to work in places where Perl is the best hammer for the job.
Use the best tool for the job, if you're happy with your choice, great. Don't be so quick to criticize Perl, when you point one finger forward, you always have three pointing back at you (had to throw the corny line in from my mom).
You've posed an interesting question. Do surprises in Perl keep programmers from falling asleep at the keyboard?
I agree with Simon's observation that most people who program in Perl do so by choice.
CS101 classes around the world aren't generally teaching Perl. I also don't imagine that executives in corporate environments remark, "O, you want to use Perl, that's great. It's such a lovely language." It's probably more like "Perl, what's that? Can't you use something I've heard of, like, what's it called--Java. Yeah, use Java. I like Java."
Did anybody else have to read that three times? What was that about transparency?
This is some sort of "you're a good programmer if you can parse this sentence in one swipe" test isn't it?
I also read it three times, and I still don't think it parses. What are you trying to say here chromatic? Do we have to start in with the sentence diagrams?