A quote attributed to Ward Cunningham suggests that Smalltalk failed because its tools were too good — they let people manage small messes in Smalltalk until they grew into big messes.
I can believe it. Think of the C programming language. C programs can be incredibly simple and straightforward; the language itself is reasonably easy to understand, with only a few crazy ratholes related to function pointer declarations. Yet the language provides only the building blocks for programs, and it's easy to believe that the C language is simple while acknowledging that C programs can be exceedingly complex. Raw pointers and pointer offset math may be simple concepts if you understand how CPUs and memory work, but that simplicity does not make C programs simple. (It also doesn't work portably across platforms unless you understand how all of the relevant CPUs work. Hooray for struct padding and alignment concerns.)
Perl occupies a sweet spot in language design and use. Larry describes it as a combination of manipulexity and whipuptitude. Perl has the power and flexibility to let experts twist and turn it until it does exactly what they want. It's also simple and expressive enough that novices can get their work done without worrying about theoretical underpinnings, big O notation, or even how memory allocation and hashing and vectors work.
Of course, it's only a rhetorical device to anthropomorphize a language. Perl doesn't allow all of these things. Perl is merely a tool in the hands of people who make these decisions. Like Smalltalk, Perl will let you go a long way even if what you're doing isn't maintainable. (Try ignoring memory allocation and proper pointer usage in a C program. It won't run well for long.) Like Smalltalk, you can end up with a big mess very quickly.
My colleague Allison once said "The last four hundred lines of this loop are kind of messy."
I have trouble understanding what kind of mindset it requires to write a loop with four hundred lines — and I recall that she had already refactored several hundred lines out of that loop.
Put another way, you'd have real trouble reading this essay — as short as it is — without paragraph breaks. Take out the punctuation and it gets more impenetrable. Remove the spaces. You won't even bother.
I won't pretend that people are great writers. I've read too much fanfic on the Internet and I wrote too much bad poetry as a teenager to suffer that delusion, but people generally understand how to arrange their thoughts into sentences and paragraphs. They know how to hit the Enter key every now and then to separate unrelated thoughts.
Find and replace and automated refactoring tools and cross-referencing and compilers which treat all vertical whitespace as more or less the same and a function of five lines as equivalent to a function with five thousand lines are tools which allow us to manage messes in the same sense that Smalltalk's lovely browser lets Smalltalk programmers manage ravioli code. Our tools let us work around nascent problems until they grow too large for our tools. Then we're in real trouble.
I don't want to manage little messes. I want to eliminate them. Only the relentless desire to eliminate non-essential complexity will work. Will teaching people to think of code — not in terms of lists of statements to execute or methods to send or mathematical formulas to solve — as words, sentences, and paragraphs help?
