January's thesis that programming is unique among professions brought some thoughtful mail. Several readers agreed with my (obvious) observation that programmers are both tool users and tool builders, but challenged the (not-so-obvious) conclusion that I drew from it. They pointed out that this observation may have more to do with the comparative youth of programming as a profession than with any unique qualities of the software art, citing examples to show that the phenomenon of the workers building their own tools is common in the early stages of most crafts or professions. Only as the profession matures does the sort of vertical specialization I described creep in, and a clear distinction grow between the tool makers and the tool users.
And all of this is, my correspondents argued, a Good Thing. It is, in fact, the main reason that fields like medicine and physics have been able to advance as impressively as they have.
The argument is compelling, and I accept it. Not only is it compelling, it clearly applies very nicely to programming. If everyone were to code at all levels, from the bare metal up to the GUI: 1. Only a few would be able to do it; 2. it would take a long time to write a program; and 3. software development wouldn't progress very fast, since everyone would be endlessly reinventing the wheel. Vertical specialization, with one group of programmers developing tools that another group uses to develop more powerful tools (that, perhaps, another group uses to develop even more high-level tools, and so on) is crucial to progress in the software art. Vertical specialization in software development is a Good Thing. Point taken.
But the unmixed blessing is as rare as the free lunch. Good Things have their dark sides, their hidden costs. The skeptic in me wants to know, what's the hidden cost of vertical specialization?
In the case of Western medicine, the hidden cost of specialization seems to be decades of blindness to the virtues of Eastern and traditional medicine. The Western model of treating the disease differs in a deep way from the Eastern model of treating the person.
The difference is a classic example of a paradigm clash.
A paradigm is a very broad thing, conceptually. It is a fundamentally different sort of thing from an algorithm or a heuristic or a plan or a method. Algorithms, heuristics, plans, and methods are all ways of solving problems. A paradigm includes ways of solving problems, but it also includes ways of formulating problems. More than that, it must include (generally very informal or implicit) decision processes for deciding that something is in fact a problem. What appears to be a difficult problem in one paradigm may not be seen as a problem at all in another.
In Western medicine, when the patient has been diagnosed as healthy, the problem space is empty. There is no disease, there is no problem, there is no action to be taken. Eastern medicine, with its emphasis on health maintenance, sees plenty of actions to be taken with a healthy patient. For the Eastern practitioner, the problem space becomes empty only when the patient is dead. Not only are the methods of Western and Eastern medicine different, their goals and their perceived problems are also different.
This characterization of Western and Eastern medicine is a gross oversimplification, of course. Preventive health measures have always been a part of Western medicine, too, and Western medicine has now begun to adopt some approaches of Eastern and traditional medicine. As penicillin and the wonder drugs of the mid-20th century begin to lose their wondrous properties due to the adaptations of viruses, Western medical researchers are turning their attention to certain lichens, like Usnea, long believed to have health-promoting properties. Even politicians get it: Last year's tragically fruitless debate over health-care reform included a surprisingly enlightened emphasis on preventive health care.
But from everything I've read on the subject, the difference between the two systems of medicine is essentially as I have painted it, even if I have used a broad brush, and even if Western doctors are now beginning to learn from Eastern and traditional approaches.
And the paradigm clash was real. Western doctors were not slow to see the benefits of Chinese and folk medicine simply because they were intellectual snobs, convinced that these old remedies couldn't be useful. That would be culture clash, and that was undoubtedly a factor. But the paradigm clash was something deeper. The Western doctor looked at the practices and writings of his or her Eastern counterpart and couldn't see that the Eastern doctor was addressing the problems the Western doctor was facing. The Western doctor looked for cures for diseases, treatments to relieve annoying symptoms, and didn't find them, and so dismissed Eastern medicine as ineffective, useless.
All methods are useless when applied to the wrong problems, and when practitioners are operating in different paradigms, they have different ideas about what constitutes a problem. As a result, they have no basis on which to evaluate each others' methods. They have no way to compare results, because their results are incommensurable, apples and oranges.
And that, I claim, is where the danger in vertical specialization lies.
Western medicine is a mature, vertically specialized profession, with a highly developed central paradigm of disease treatment.
Or rather, that's the paradigm of the Western doctor. Western drug and medical-equipment manufacturers have their own paradigms, and the various specialties of Western medicine, like plastic surgery and dermatology, have their own variations on the central paradigm. One's paradigms, and consequently the problems one sees, are defined by one's specialization.
What is true of medicine today could be true of software development in the future. Different vertical strata of programming, supported by academic programs that train programmers for a particular stratum, could eventually lead to a situation in which two programmers from different strata are as unable to communicate as Western and Eastern medical practitioners recently were. In fact, the danger could be much greater, because the fact that programming tools are typically programs themselves makes vertical specialization much easier in programming than in other professions. There is no obvious limit to the sequence of programs for building programs for building programs for_.
That's the dark side: two programmers, possibly working on the same project, but unable to communicate effectively because they do not see the same problems.
But doctors are resolving similar problems, and Western medicine is learning from Eastern. How do such problems get resolved? In theory, by deconstructing the paradigms, going back to common goals or a common technological basis. You tear (some of) it down and build it up again.
So I guess I'm not so concerned that every programmer should be able to build a complex system from assembly-language scratch. But I think that some, if not all, programmers should be able to tear down the edifices we construct and start the process of rebuilding from scratch.
I forget who it was who recommended that, with respect to operating systems, every generation or so we should tear it all down and start over again. In that spirit, I suggest that every programmer's toolkit ought to include a monkey wrench to throw in the works. I'm not advocating doing it; it may be enough to know that we can.
I'm leading a double life here in Stately Swaine Manor. At some time every morning I attire myself like an upstanding citizen and go into town. By "town" I mean GIGO Gotham. You know, the virtual village, Baudville, the Web, the Grid, Gopherspace, Cyberspace, the Pleasant Land of Gif, the Internet. I cruise its dark alleys, thread its broad thoroughfares choked with teeming humanity. Crime prowls these streets, too, as do strange creatures who hide behind masks.
But then, we all wear masks.
Time is an ever-present nemesis in Gotham. It expands and contracts and is far too real and comes in different varieties. Connect time is parceled out in slices, and it is beyond your control when your next slice is coming. Meanwhile clock time ticks away in the corner of the screen, scarcely connected to connect time but joined at the hip to your wallet. Hurry up and wait is the anthem of Gotham life.
Most afternoons I descend into the Manor's lower chambers. Here, beneath the towers and battlements is the Batch Cave, where I go into batch mode, descending when the sun is shining and emerging to a dark and chilly Manor. The Batch Cave is a place where time, in the Gotham sense, does not exist, where nothing exists but the current project.
If there were only one project, this monomania might accomplish something of value, but every day I seem to find myself sucked into a different one.
Last month it was Prograph, an intensely visual language for Mac, Windows, and UNIX systems. This month it was VIP-C.
Visual is in.
There's Visual Basic, of course, but there's also a visual anything else you care to name. Visual Smalltalk, no less. Digitalk (Santa Ana, CA) has fixed on the Visual Smalltalk nomenclature because: 1. Its Smalltalk is very visual; 2. visual tools are the hot tool category in the client-server market that Digitalk addresses; and 3. Digitalk wants to sell a lot of boxes. Attaching "visual" to the box is a good way to sell more boxes. Attaching "visual" to the product is harder, but I'm not suggesting that Digitalk hasn't done it. That may be a subject for a later column.
This visual programming language (VPL) phenomenon is understandable. It's hard not to think that programming could be more visual when you work with object-oriented systems. VPL and OOP have an apparent rightness for one another, at least if you don't look too deeply. OOP development makes it easier to think of programs as collections of interacting things, things that might be visually representable. VPL development suggests strongly that the functionality of the program is or ought to be encapsulated in those little pictures, or in objects represented by them. OOP seems to cry out for VPL, and vice versa.
Of course, every advance in software development has to be considered from the standpoint of the dominant programming paradigm, C. And C was never intended to be an OOPL or a VPL. But C continues to evolve.
One direction of that evolution is VIP-C. Visual Interactive Programming C Development System for Macintosh from Mainstay (Camarillo, CA), that is.
VIP-C has at its heart an interpreter. Working with the interpreter, you can rapidly knock out applications, and VIP-C will wrap them up with the support code necessary to produce standalones. The interpreter environment includes a decent source-level debugger, and it's easy to imagine using the product for in-house corporate development.
The interpreter is overlaid by a visual-development interface (hence the name) that lets you grab objects like text boxes, dialog boxes, and buttons and associate behaviors and properties with them, all without writing a line of code. As you build, VIP-C produces a flowchart showing what your program looks like. But the flowchart is not the visual metaphor of VIP-C. The visuality is all in picking those objects and their properties. The central view that VIP-C gives you is, surprisingly, not visual at all. It's a collection of windows, each containing C code. There's a Main window for the Main routine and so forth. When you pick objects and properties, VIP-C interprets your actions and produces the lines of code. These lines of code are just as editable as if you had typed them in; in fact, you can type them in. It would be possible (although not particularly smart) to use VIP-C as a text editor for writing C code, ignoring all the visual frills.
I developed several simple applications with VIP-C. It's easy to work with. You really can put together an app in a couple of hours. Once you've worked through the tutorials, you have a reasonable grasp of the tools and how they work, and of the design cycle. I admit that I have only developed a few simple programs that spin off from examples supplied as tutorials, but "simple" in this context means a bare-bones text editor or paint program.
If that were all there were to VIP-C, it might be useful to in-house corporate developers and hobbyists, but it would be of little interest to commercial developers. But there are some other features that make VIP-C worth a look. These all revolve around exporting to other C development environments.
The ability to export code seems like the sort of extra step that preprocessors always add. VIP-C makes it a little nicer by providing the hooks so that your traditional C development environment can be tightly integrated with VIP-C. In effect, a third-party compiler can be hooked in, so what you have is one big development environment.
And you can move code back into VIP-C for further massaging after you've tweaked it elsewhere. Specifically, you can import any ANSI-C source code into a VIP-C project, with some exceptions, such as that inline assembly code is not allowed.
PhonePro is a VPL of another color. This Mac-only product from Cypress Research (Sunnyvale, CA) is a tool for developing telephony applications: voice-mail systems, software-only answering machines that walk the caller through a menu of messages, and software-based fax machines.
I did some PhonePro development a few months ago when my answering machine had gone south. I'd had enough of malfunctioning hardware and decided to replace the machine with a piece of software. If I were not so deeply mired in the programming paradigm I'd probably see some humor in that, but I'm way too far gone.
PhonePro is unlike VIP-C in that it is very much a flowchart-oriented system. To create PhonePro applications, you drag and drop icons from a palette onto a big sheet of virtual paper, and that's your program. You don't have the option of looking at a textual representation. As with VIP-C, you control the behavior and properties of these objects by making choices from lists or clicking buttons in pop-up dialog boxes.
Because the flowchart is the program, PhonePro gives you full flexibility in moving the icons around to make something comprehensible. You can modularize the code with goto icons and you can add comments to sections of code or to individual icons. The links are real visual objects, too, and when you click on a link (the line connecting one icon with another) you can edit its properties.
PhonePro is definitely a rapid-development environment; I was able to put together a simple answering-machine application in a couple of hours, and customize it over the next few days into something genuinely useful. Because the time-critical elements are all prewritten code, the application had all the speed it required.
But is it programming? I'd have to say that PhonePro is only charitably a language or development system. It is in no way a universal programming language; more a scripting system for creating phone software, presented in a visual programming model.
It does provide all the tools you need for that domain (although you could think up deviant applications that just wouldn't be possible using PhonePro). And that makes me wonder, is this the proper use for VPL systems? Particular domains like telephony applications? It seems that having a clear domain makes it easier to iconize the elements, because there's more agreement about what those elements are. You get around one problem of visual systems: that it's hard to iconize an unlimited domain of objects. Limited domains like telephony are not as open ended.
Postscript: Sadly, the soft answering machine is not presently in service. It fell victim to conflict with a piece of hardware. Last week the fax machine that shares its line went south.
Copyright © 1995, Dr. Dobb's JournalA Pair o' Docs
A Monkey Wrench in Every Toolkit
GIGO Gotham and the Batch Cave
Everything is Simpler in the Batch Cave
C You Can See
But Is It C?
The Soft Machine
But Is It Programming?