There may be fifty ways to leave your lover (as the song says) but there's no good one; nor is there any good way to leave a group of readers whom you've been with as long as I have. So I might as well just admit up front that this column brings the curtain down on Structured Programming, Jeff Duntemann-style, after 51 installments. It wouldn't be quite right to spring it on you in the final paragraph.
Part of the reason I'm leaving the hallowed pages of DDJ is that I own my own publishing company, which has now grown big enough to be several simultaneous full-time jobs. Certain people are hinting that I have some focusing to do if I intend to see my fiftieth birthday, and an unexpected tussle with pneumonia last fall indicated that they may be onto something.
But it's more than just a matter of overwork. The technology has changed enormously over the last four years, to the extent that a "structured programming" column doesn't make anything like the sense it used to. If I were writing in Bucket-Makers Monthly, it would be the equivalent of hosting a column called "Buckets That Don't Leak." Hey, we've won that war.
The column has always been defined more by what it isn't than bywhat it is. "Structured Programming" is the Un-C Column; and with the traditional languages, Un-C today generally means Turbo Pascal. Early on I paid serious attention to Modula-2, but over time Modula withered in the American market. I've touched on other languages now and then (Smalltalk being my favorite, old Xeroxer that I am) but DDJ's demographics indicate that Turbo Pascal predominates in the non-C realm.
Over the last year, some disturbing trends have begun to surface. The number of people citing Pascal as their major language on magazine surveys has begun to drop. Books on Pascal are not selling very well, I've heard from several authors. (I'm bucking that trend nonetheless, and my Borland Pascal From Square One should be very close to publication by the time you read this.) Where are the Pascal people going? And why? I'd love to ask those specific questions on a survey, and I may in time. I've gotten some hints in the mail, and on the networks. (If you'd like to tell me why you've moved away from Pascal, and to what, please write.) I've been able to distill two major forces at work in the market that may provide an answer.
1. The bulk of new PC development is happening for Windows. Many Turbo Pascal people bought Turbo Pascal for Windows, assuming a smooth transition from their DOS work, and hit a very high wall. Working in Turbo Pascal for Windows is a lot like working in Turbo Pascal for DOS and Turbo Vision, with the Object Windows Library (OWL) in place of Turbo Vision. Learning Turbo Vision is brutally difficult, and learning OWL is no easier. Furthermore, OWL is not optional. Using OWL is, in fact, easier than using Turbo Pascal for Windows "naked," and making raw Windows API calls. Both Turbo Vision and OWL rely pervasively and inescapably on pointers, and developing for them feels a great deal like developing in C. I think a lot of Pascal people felt that if they really wanted to work in C and be up to their eyebrows in pointers all the time, that they'd just work in C.
2. Commercial development is under intense productivity pressure. At the same time that understanding and using the preferred platform (Windows) has become enormously more difficult, market pressures are requiring that products come to market faster and with less labor. Even the C people are hurting in this area, though they're not likely to openly admit it to me. The pressure is especially intense in vertical-market shops, where vendors are finding it harder and harder to coerce $10,000 from users for a market-specific application anymore. If the price of the box goes down, the stuff in the box had better come together more cheaply. Pascal development has traditionally been fairly fast, but it may no longer be fast enough, especially when the spaghetti-tangle that is Windows must be catered to.
Caught between the twin pincers of market pressures and the hassles of working in Windows at a low level, I think a lot of Pascal people have simply jumped ship and taken up with one of the visual programming languages. The one whose name I hear far more than any other these days is Visual Basic.
I confess I didn't care much for Visual Basic in its first incarnation, for reasons that didn't come clear right away. In the interim I completed Mortgage Vision, a modest application with TP6/Turbo Vision, and used Blaise's Turbo Vision Development Toolkit to ease the way. When I came back to Visual Basic to check out its 2.0 release, it felt like home in a way it hadn't before. In fact, what had bothered me about VB1.0 was not VB at all, but the idea of drag-n-drop, which I hadn't really used at length before. (Even Smalltalk, for all its graphic style, remains a typing-intensive environment.) Once I had drawn all my menus and dialogs with TVDT and gotten used to the feeling (and once I had suffered through enough event-driven programming to make it seem natural and easy) Visual Basic abruptly became very compelling.
I have to make a point here that Microsoft won't like: The Basic-ness of Visual Basic is close to irrelevant. And this too: that in Microsoft's capable hands, Basic has evolved syntactically to look a great deal like--gasp!--Turbo Pascal. Visual Basic is a fully-structured language, with procedures, functions, and every control-flow structure present in Pascal. They even write it now using the same standard indentation conventions that Pascal people have been using since Year One. What's significant in Visual Basic has nothing to do with any individual programming language at all: It has placed the bulk of the Windows UI machinery behind a curtain, from which it emerges in its naked terror only in dire need. The language behind Visual Basic's forms and controls could be any language at all. Rumor has it we'll see a Visual C++ from Microsoft in time. Meridian Data is about to present its own drag-n-drop C++ called C++ Designer, and we've had VZ Programmer (an early but excellent visual dialect of C++) for some time. There's no reason at all that somebody couldn't present a visual Pascal, and if a certain Somebody would just get off their collective butts and do it, Visual Basic wouldn't be bleeding the Turbo Pascal market dry.
Some people may well enjoy fencing with Windows at a low level, and we'll always need a certain number of such people. But more and more people are finding it un-fun in a big way, and a lot of companies are coming to feel that working cheek-by-jowl with Windows costs far more than it is worth, when other roads are rapidly opening up.
Let's talk about yet another one.
I've been hoping for years that the traditional languages would extend themselves in the direction of database development by incorporating verbs implementing relational concepts. Clarion did exactly that, and reached something close to the ideal mix of interactive tools and underlying language expressiveness, but Clarion is a proprietary language from a small company and thus won't even be considered by a great many shops. (Besides, the 3.0 release, with the globally-optimized TopSpeed code generator, is now so late that some folks are beginning to wonder if it will ever happen.) What I'm seeing instead is that the major databases are extending themselves toward the traditional programming languages by allowing users to write traditional structured code "behind" the usual interactive features for maintaining tables and generating queries and reports. The Big Blur between traditional languages and database managers has begun, and if it's coming from the direction opposite that which I expected, well, hey, I reserve the right to be surprised.
The best example of the Big Blur I've encountered recently is Microsoft Access. I sure hope you all took them up on their $99 intro market-share grab; you're unlikely to net a development tool of that magnitude so cheap for awhile. Yes, it's a database, and while I haven't used all that many database managers on the PC, it's as good as any I've ever had, and certainly better than Paradox 4.0, which while quite fast has this ugly habit of generating cross-links on every hard disk I've installed it on. I doubt I will ever use it again.
Access is a Windows-specific database manager, fully relational by my standards, and beautifully designed for interactive use by advanced end users. It has the traditional macros that users have come expect in products like this--but behind the macros is another and still more powerful layer that is essentially Visual Basic with access to all the power of the database manager. Access Basic can manipulate the very high-level objects (databases, tables, forms, queries, and reports) you create interactively with Access's interactive tools, much as Visual Basic manipulates the forms and controls you draw. (I should point out that while Access refers to things like tables and forms as "objects," they are not true objects in the OOP sense, but are simply large data structures with documented interfaces and internal layouts mostly hidden from the programmer.)
If Access has any severe limitations from a coding perspective, I haven't encountered them yet. It can act as a DDE client, and make DLL calls. This allows you to add system-level code like a serial terminal window without much difficulty, assuming you know how to write such code in a language like Turbo Pascal for Windows or a DLL-capable C/C++. Access Basic has a richer suite of numeric types than Turbo Pascal, and has great little functions like Weekday (which returns a day-of-the-week code for any date passed as a parameter) that I've always had to cobble up on my own.
Obviously, you're not going to create little hacker utilities in something as massive as Access. But for creating business applications, I'm finding it brutally effective. By building what amounts to Visual Basic into Access, Microsoft is very intelligently recruiting traditional programmers into its database corner. At this writing, Borland has not yet released Paradox for Windows, so I haven't yet seen it. However, Paradox for Windows has at its heart an object-oriented extension of PAL (Paradox Application Language) which may be solid and useful, but which looks nothing at all like either C++ or Pascal. Over the next few years, this may come to be seen as an extraordinary mistake.
I don't want you to miss my point, so let me take a big long roundhouse swing and hit you over the head with it: The language wars are over. The war now, if there is to be one, will be between visual development and traditional development. There's a lot more at stake in such a war than you might first perceive. Here's a point that may not have occurred to you: In visual development, the highest-level design issues (and hence the shape of the created application) are defined and controlled by the shape of the tool being used.
In other words, if you create an app in Visual Basic, the code you write is limited to procedures and functions, each with a fairly narrow scope. The shape of the application is the shape of Visual Basic itself.
This may seem obvious, since Basic code has traditionally had all the shape of a cup of water thrown into a spring breeze. But consider the situation of C++. Many of the gnarliest C++ features are in fact very high-level "shape-definers" that impose a design vision upon the application being written. Templates, multiple inheritance, operator overloading, and things like that have an influence that permeates every corner of the eventual application. These are the sorts of things expressed by the nature of the underlying kernel within a visual language. I don't think they'll be easily changed. The design vision of a visual language will become the design vision of the applications it creates. The code that the programmer writes will almost invariable be local in nature.
What about the role of CASE tools? Well, there have been CASE tools for years. Why haven't they come to dominate the development world as they probably should? The answer to that is simple, and it should make all of us squirm: Because programmers much prefer coding to design. A tool that produces a live, working, wonderful-looking application will always win the war against a dry design tool that produces nothing more compelling than reams and reams of bubble charts and structure diagrams. The tool that produces the code will rule.
Count on it.
These developments will have a profound effect on most traditional languages, and on C++ far more than any other. I hope you all read Scott Guthery's slightly grouchy complaint published in the December 1992 issue of DDJ, entitled "A Curmudgery on Programming Language Trends." Scott is concerned that C++ will be the death of structured programming, for reasons he can express far better than I. I can respond simply by saying, Not to sweat. These effects are to some extent self-limiting.
Bjarne and his gang are having loads of fun piling every conceivable expression of program logic and abstraction into C++, making it easily the largest, most complex, and least-understood programming language in history. Remember that for them, the design of C++ is art, and basically a good time. They don't really have to use the damned thing--not the way working programmers have to. Only a handful of C++ programmers probably understand the language well enough to use all of it. Those handful who do use all of it frequently create code so arcane that their fellow C++ programmers have a hard time understanding just what it was they did, or even how. Recently, I'm hearing whispers of shops where you have to get management permission to use operator overloading or multiple inheritance--what a concept!
And how long, long overdue. It's way too easy to forget that the most important part of weilding power is knowing when not to use it.
Scott's article expresses justifiable concern, but I take the long view: We are currently seeing the beginning of the last days of steam. Early in the development of the steam locomotive, there was an incredible parade of mutant locomotives working the High Iron. Locos called crabs and camels, humpbacked monstrosities with walking-beam linkages; all manner of weird and wonderful machines that expressed what each designer thought was the current state of the steam art. Some ideas worked better than others. Many ideas worked well but were too fragile to maintain. (Locomotive fanciers may recall the cranky poppet valves on the Pennsylvania Railroad's wedge-nosed behemoths, the T1's.) Some ideas were mere decoration that earned no mechanical advantage. However, each idea that came to mind had to be tried.
That's what's happening right now: We're trying every programming language concept that comes to mind, especially in languages like C++ that well from restlessly-creative teams of brilliant human beings with far too little to do. And C++ may well be becoming what the ill-fated T1 was: An awesome engine with tremendous power that was simply too fragile to maintain. We should know in a few years.
While the bizarre and brilliant locomotive ideas were being tried and discarded, the design of conservative, workaday engines was converging on a near-standard shape: that of the familiar, undecorated 4-8-4 that worked the rails until the end came. I'd like to think that, away from the excesses of C++, most workaday programming languages are converging to what ANSI C, Microsoft Basic, and Turbo Pascal all are: Structured programming languages with simple but robust designs. Ample power without too much fragile complexity--that's structured programming in a nutshell. A little object-orientation doesn't hurt, and may help a lot. Too much takes a language right over the horizon of comprehension and beyond the bounds of maintainability.
In the last days of steam, (back in the Thirties) a new idea appeared: The deisel-electric locomotive, incorporating twentieth-century rather than nineteenth-century technology, and in another twenty years it swept the rails clear of steam. I won't go so far out on a limb to say that visual programming is to traditional programming what the deisel was to steam, but lordy, I get these feelings sometime.
The people who love steam locomotives (and I remain one of them) sometimes forget that the whole idea is not locomotives but transportation, and that what gets the load where it's going fastest and cheapest wins. Admiring steam as art doesn't pay the bills. As programmers we have to remember that creating a working, reliable application the fastest way possible is the goal of the game. Programming as we know it is indeed the most intoxicating kind of fun (or maybe the second most) but if something better comes along, we're doing no one any favors by clinging to the old ways.
Obviously, the tough one is knowing what is better, and what is merely more of the same old...steam.
I don't see any discontinuities in the programming business for the next several years. (That doesn't mean they aren't there.) Intel CPUs and their clones will continue to rule, expanding to own perhaps 95% of the CPU market for desktop machines. Workstations will suffer terribly once Pentium is out there and cheap, and may vanish entirely once Pentium's successor (Hexium? Sexium? Why can't we just call a 686 a 686?) hits the streets. The Power PC will come out in the classic IBM/Apple position: Overpriced and underpowered, and will elicit the Big Yawn. It may eventually come to own .08% of the desktop market. Windows will utterly dominate the platform game, especially once Microsoft releases a credible midmarket embodiment of Win32s. Bill Gates will eventually become rich enough to get his million-dollar car out of hock.
I've long hoped that Apple would go out of business before 2000. It may take a few more years than that, but I will continue to hope.
This is kind of a dull future; most changes will be changes in scale and not in shape. It may well be the ideal future for the small software developer, however, especially one who knows how to work fast and keep a small turning radius. The world market for English-language PC software will be in the 500 million range by 2000, and if you can't pay the rent on that, you belong in a government job.
Small will be important for another reason: We've just elected a good-hearted but weak president who has all but invited Congress to walk all over him, and they're rubbing their hands in anticipation. Congress is dominated by a party that hates business above all else, and they will be taking more and more of your money and throwing more and more roadblocks in your way as the Nineties progress. The only way to duck some of these roadblocks is to stay small and get the hell away from the big cities and their dark nimbus of murder, drugs, welfare despair, and trial lawyers searching for something, anything to sue.
The good news is that a software development firm with eight or ten employees can work very well and keep all of those people in jobs. Forget any thought of getting rich, relocate to a small town in a temperate climate, and rediscover what it's like to simply live.
That's pretty much all I wanted to say. People who haven't been with me since the beginning may wonder what all this "shower curtain" business is about, and I think I'll close by recounting my confusion on getting out of school in 1974 with a degree in English and no favorable prospects to speak of. In scanning the papers, I saw a lot of ads looking for people to do peculiar-sounding things, and one that made me smile was an ad for "manufacturer's rep in bath fashions." I had an older cousin who worked hard running around pushing shower curtains and peel-off stick-down cartoons of fish and bubbles to discount stores in the Midwest. He went to shower-curtain conventions and probably read shower-curtain trade magazines. He was in on the scam, and it didn't seem to bother him: Call it representing bath fashions if you want, but what it amounts to is selling shower curtains.
Things got dark enough so that once I thought I might call Cousin Sammy and see if there was an opening in the Illinois territory. Instead, I got a job fixing Xerox machines, and with time and luck faked my way into a job as a self-taught COBOL programmer.
A couple of years in, it occurred to me that there was no hokey euphemism for programming. The work was good; why gild the lily? It's worth remembering that garbage men are called sanitation engineers, and shower curtain salesmen are called bath fashion reps, but programmers are called...programmers.
The next time the bugs are biting and the deadlines are looming large in the shadows, keep in mind that you, too, could be selling shower curtains. Of all the work in the world, ours is among the best. Keep doing it. Do it well.
I'll be out here with the coyotes if you need me.
This is Jeff Duntemann's final column in Dr. Dobb's Journal.