This is a very early work -- I wrote it in my first semester of college. I feel reasonably safe in saying that it's blather. Sincere blather, yes. I meant it (except for the parts where I was kidding), and I still think that what I meant was accurate. But I didn't say much of anything.
In fact, I only include it here as a footnote to my Biography of a Programming Project essay.
If you want to know what I was getting at, read "The Programmer's Stone", by Alan Carter and Colston Sanger.
The big trend of the modern computer age is structured programming. Everywhere you turn, you see program modules, self-contained subroutines, localized variables, daisy-chained lists. Friends, programmers, this movement has gone far enough! The insidious danger of top-down programming can be ignored no longer. It is time to for the world to recognize HOLISTIC PROGRAMMING.
Holistic programming is a style that understands the relationship between you and your computer. Programming is not a one-way street! Yes, you're the one who has the goal to reach -- but the program is the one that talks to the CPU. You're partners, working together to reach a goal that satisfies both of you.
You have to work together. Every real programmer has some intuitive feeling for this, a feeling that you can't just insult your program or pound on it when it doesn't work right. You have to be with your program -- understand its side of the problems. Remember, programs don't like crashes or bugs either! A crash is a program's way of saying, "Hey, I need you. I need you to help me." Don't go looking through your diagrams of program logic to see what might be wrong. Take time with your program; approach the problem from a few different directions; find out what the program thinks about the problem. Then fix that. Don't restructure a whole section of code just because the algorithm needs work! Would you amputate an arm and grow a new one just because a tendon was too short? Fix the problem where it is! Add only what the program needs to make it right. Your program will thank you.
When starting to write a program, conventional style says to write out what you need each part of the program to do, then write the parts, then fit them together in some way -- top down, or bottom up, or whatever. But think what that does to the program! How can you have a meaningful relationship with a piece of software when you've decided on its into a role in life even before it was born? How can you understand its problems when you refuse to admit they're even going to exist? The two-way communication of programming just isn't there. Write like that, and your program will be balky; you'll have to whip it into shape, which will only make things worse. Forcing a program into shape with structured logic is like training a horse with a whip and cattle prod. He'll do what you want, oh yes, and he'll stop doing what you don't want him to do -- but just wait. You'll never know when he's planning something nasty, because you won't have the intuitive empathy with him that only comes with long hours of shared company and practice together.
You have to let your program grow. Sure, you can write a module -- test a module -- write another module, but what do you wind up with? A bunch of bricks glued together! As streamlined as a cow and as efficient as a square wheel. It works -- clunk clunk clunk. Is this the way you want to live? Is this the way your program wants to live? Doesn't a dynamic, clean program feel better? A holistic method of programming is to start with the core of the program, the real guts of the algorithm. Write that, and test it. Now embed it in the next level of code. If you can re-use some of what you've written, move it to the end and make it a subroutine! If a data structure turns out to be useless, take it out! Now you're assured of having two parts of your program done, with maximum speed and efficiency. Put the third level around the first two, and increase the efficiency even more. The program flows, instead of bumps.
You see, structured programming is designed to assure correctness. Does it work? Of course not. When was the last time you saw an absolutely bug-free program of any size? Structured programming may help reduce bugs, but so does being with your program. Holistic programming, though, assures efficiency in a program -- and you don't need absolutely perfect efficiency to be pretty damn good.
But don't let "goals" like "efficiency" or "program correctness" tie up your style. Let the program flow out of you, let the needs and feel of the program flow back into you, and it will happen all by itself. Remember: knowing what a block-box piece of code does isn't worth half of knowing how and why your code works, and knowing that your code wants to work, with you, not against you. Give your program trust and understanding, and it will be loyal to you.
-- October 16, 1988.
Updated November 29, 1999.