If programming a microcomputer isn't a safe sandbox for experimentation, what is? The problem lies in humans trusting other humans. Banks trust data processes who they should not; shoppers trust sites they shouldn't (I'm sure I'm guilty of this too, and the credit card changed their ToS long ago so that only in extremely unlikely cases am I protected); everyone seems to want to trust an operating system that time and time again proves itself unworthy.
It's easy to accept something once you fully understand (or largely understand) why it exists. Bees serve an extremely important purpose in nature. Not to draw a close analogy, but I often attempt to explain Java's success and importance to people who only see the superficial verbosity and its pretense of seriousness. That'll be another rant.
Big balls of mud don't bother me and I don't mind working on them other than that doing so is a huge undertaking with slow results. What bothers me is management so eager to accumulate code debt but never pay it off. The blame for the lack of productivity of programmers working on their code needs to be placed squarely on them -- punishing the programmers for doing what they're told to do (keep adding features!) is a sick practice I've seen too much of.
Newbie code isn't inherently evil. Blame management who refuses to heed warnings again.
Half finished code isn't evil.
Insanely over-engineered code isn't evil -- that's the gist of my Java rant, actually. The Java style of handling projects amounts to programmers covering their ass. If they document the hell out of everything, formalize everything, and code every anticipated thing as something controlled by an XML config file, then the facts that humans are notoriously terrible at anticipating things and that smaller code is easier to change than massive projects become immaterial. By embracing management in their hubris, there's no question at all where the failure lies -- the management. This is like making a wish with one of those bottle genies -- management gets exactly what they ask for, which is of course not what they need, at least no more so than something much more easily sought after and gained.
I'm not anti-management; in a previous installment, I wrote at length in defense of management. The tone followed this post's, actually -- understanding why management does the things they do and thinks the way they do. The key, as usual, is understanding.
It's not all management here either. Novices who completely pull stuff out their asses and think that there's only one mistake in it and think that as soon as it's fixed, the thing will magically work frustrate #perl but they mostly frustrate themselves. They'll learn eventually that "the one last bug before it all works" is an exceedingly rare beast for non-trivial programs. You can tell these guys all day long that they're doing 1,000 things wrong and that they're thinking about it all wrong.
I hate the Matt's Script Archive guy whose refusal to accept fixes or take his code down wound up making perl, indirectly through formmail.pl, the second largest spam relay on the Internet for ages. His code was bad but I don't hate it; he on the other hand attained a level of apathy and hubris that warrants the title "evil".
I recently had a hard time answering the question about what my code pet peeves are. Perhaps it's telling that I couldn't come back with one. I started on AtariBASIC. It was all line numbers, sneaking lines in between lines and combining statements to squeeze things in so you didn't have to renumber your whole program (which involved retyping it). That and global variables and peeks and pokes and data statements with decimal representations of binary data. I guess I'm daemonspawn. Part of my Vegas talk, the theme of which was how Perl allowed us to do something that much larger companies couldn't manage, was how dubious features of Perl saved our asses. Source filters allowed public key encrypted modules (every part of the system is required to verify each other part against tampering) to be decrypted on the fly. Code was bytecode compiled indirectly with the B backend (care of indyperl), again as required by regulations. For some high performance stuff, I was essentially peeking and poking raw memory, care of mmap, and doing pointer arithmetic, all in Perl.
Subscribing heavily to the 80's and 90's school of OODA probably makes it worse. I can have esoteric conversations wherein byzantine logical structures of programs are devised.
How could I hate other people's code? That would be hypocritical.
In all seriousness, anyone can create complexity. Finding the right trade-off between complexity, adaptability, time (to write), speed, maintainability (it's various aspects), and so on is harder. I'm not overly proud of myself for comiting minor autocracies; but I am confident in the decisions I made under time, budget, and requirement constraints, including estimating how much tooling up and reworking and maintaining was going to be required to get it out the door. I've known other Perl programmers who were commendable in this way. A lot of them have moved to Ruby where they would be permitted to practice this craft. I give far fewer props to anyone whose philosophy is single minded.
Quoting Knuth: But there has been far too much emphasis on goto elimination instead of on the really important issues; people have a natural tendency to set up an easily understood quantative goal like the abolition of jumps, instead of working directly for a qualatative goal like good program structure ... What we really want is to conceive of our programs in such a way that we rarely even think about goto statements, because the need for them hardly ever arises. The language in which we express our ideas has a strong influence on our thought process.
I guess that's why I like the 80's and 90's variety of OODA, that the C++ old timers subscribed to. It not only acknowledges but explores with honesty the complexities and tradeoffs involved in design, rather than the thumb sucking rules-of-thumb approach in fashion now.
-scott
