Programming Paradigms

When I started writing "Programming Paradigms" back in 1988, I chose the title partly because the word "paradigm" was so ambiguous. I didn't want to be shackled to some implicit or explicit "contract with DDJ readers" in which I promised to publish clever TSRs and all the breaking news on Forth development environments while simultaneously balancing the Federal budget. I'd fallen into that trap in my previous job, promising that I would never abandon CP/M. "Just keep the column unfettered," I thought, "a kite to the winds of changing times."

I didn't know back then that I was being Clintonesque.

Not everybody embraces ambiguity. One reader regularly clips and sends me the most egregious uses of the word "paradigm" in the press, apparently on the theory that I am responsible for all uses of the word. This may be the same reader who once pointed out to me that encouraging semantic ambiguity in the use of a word devalues it like a Cold-Peace ruble or a Depression dollar, till a pair o' dimes ain't worth two bits. Me, I like ambiguity.

Philosopher Thomas Kuhn, whose book, The Structure of Scientific Revolutions, popularized the word "paradigm," at least among people among whom books like his are popular, gloated about the flamboyant flexibility with which he used the word. "One sympathetic reader," he said in a postscript to a late edition of the book, "who shares my conviction that 'paradigm' names the central philosophical elements of the book, prepared a partial analytical index and concluded that the term is used in at least twenty-two different ways."

Twenty-two different ways! Kuhn is my hero.

And sure enough, the title has allowed me room to range widely. So widely that a casual reader, picking up the magazine occasionally, might be confused about exactly what the focus of this column is.

Well, with over 80 episodes in the can, the question can be analyzed historically. Statistically, even. I did that. Ran the whole series of columns through a battery of tests. Probed and poked. Squeezed out their essence. Found out what I've been writing about all these years.

Turns out I have been writing four distinct columns under the title "Programming Paradigms."

This seems fine to me; anyhow, it's a whole lot less than 22. But I can see how it could be confusing to that casual reader, so I have mapped out the varieties of meaning behind the title "Programming Paradigms." The four columns you have been reading under the banner of "Programming Paradigms" are:

Paradigms past. Last month, I dug into programming history, searching for the origins of the compiler. The previous month, I wrote about Ada Lovelace and Steve Dompier, asking what it really meant to be a programmer.

I got some feedback on that "Nature of the Programmer" column from Bill Walker of San Diego, who challenged my claim that programming is somehow unusual in that the users of the tools are also the tool makers. "That's true," Bill says, "if you look only at contemporary professions, but not if you look with an eye to history. In their early days, many professions created their own tools. I'd be surprised if, as you say, software development doesn't become more and more specialized, just as other professions have. We've already reached the point where many programmers have never worked in assembly language. How long can it be before a significant number of programmers use only visual programming tools and never write a line of code in a high-level language?"

Well said, Bill. My own attitude here is, um, ambiguous.

On the one hand, it's been a long time since I wrote anything in assembly language, and, as a weekend programmer with modest skills and a short attention span, I need very high-level tools, like visual programming languages (VPLs), if I'm going to get anything done. More generally, some people are probably going to have to specialize in very high-level programming, using tools developed by others, if the debacle of the Denver airport baggage-handling system is not to continue to be the all-too-common example of Big Software Development.

On the other hand, software development may be crucially different from any earlier profession. The ability to create the tools of our own trade may be much more important in software development, because software itself is different from any previous artifact of human labor. It probably didn't matter much when printers stopped building printing presses, if they ever did that. It could matter a lot if software development becomes so specialized that programmers no longer, even in principle, control the tools they use. I continue to worry about this.

Running lite. The term "Running Light" has a long and honored history in this magazine. It means programming efficiently, saving bytes and/or cycles. "Running Lite" is about something less honored.

Running Lite is VPLs, scripting systems, prototyping tools. Code that gets today's job done. The quick and dirty, the slow and easy, the pretty and superficial. Kitchen-table programming, programming for that weekend programmer with modest skills and a short attention span. It's also peripheral concerns, like "Can I make any money writing Newton applications in my spare time?" It's anything but the Real Thing.

"Running Lite" is to "Running Light" as "lite" is to "light."

If Bill Walker is right, it won't be long before there are hordes of lite programmers using only VPLs and never writing a line of code in a high-level language. Of course, as Mike Floyd reminds me, this presupposes the existence of actual visual-programming languages. Today, visual programming is strong on interface creation and marketing hype but doesn't live up to its promises when you start writing down to the bones of your application.

Interviews. Granted, I don't actually write interviews, except for the questions. But if you've ever had your unrehearsed spoken words pressed verbatim into print and published indiscriminately, you may agree that interview editing is an art. You may also share my skepticism about the desirability, if not the possibility, of automatic speech recognition.

The bleeding edge. Artificial intelligence. Neural nets. Parallel algorithms. Next year's operating systems. (If the brave and bloodied purchasers of version 1.0 of a piece of software are on the bleeding edge, are pioneering Pentium purchasers on the bleeding etch?)

This month's column seems to be about itself, but that's a sham. It's now going to take a sharp turn in the direction of Running Lite, with a lite look at making video and at the lite, third-party software market for that lite computer, the Newton MessagePad.

Connectix of San Mateo, California, is selling a digital camera for the Mac and, probably by the time you read this, for Windows. Street price for the Mac version is about $100. It requires no additional hardware, sending live digital video to the computer via the serial port. It's called "QuickCam," and it's the size and shape of a tennis ball. There's even a microphone built into the ball. It comes with software that lets you shoot continuous video, with sound, and save it as QuickTime files, or shoot still pictures and save them as TIFF files. Other apps let you create a digital photo album or turn your video into After Dark screen saver modules.

You're not going to produce Hollywood movies with this thing. You'll get small movies at maybe 15 frames per second, and they'll be in 16 levels of gray. This is definitely video lite.

All it has going for it are a ridiculously low price, effortless setup and use, and extreme portability. Connectix suggests uses such as videoconferencing, laser-printer-quality publishing (like resumes and snail-mail letters), video-enhanced e-mail, verifying inventory, monitoring the baby, or making training materials. Because it outputs QuickTime, any application that deals with video on the Mac can use its movies; for example, QuickCam movies can be placed in HyperCard stacks and controlled by the Movie XCMD.

I've been testing QuickCam for a few weeks, around the house and yard, in the office, and at a writing soiree where I shot all the participants. I have learned that it is hard to aim a tennis ball.

Other than that, I have no complaints. QuickCam performs as advertised and is a great bargain. Now I want color.

It's not enough to have a perspective on the PDA or the pen-based market. To make any kind of sense of it, you need several perspectives. You need to look at what it is today, what it could be tomorrow, and the odds against that tomorrow. It's appropriate to be a critic, savvy to be a believer, rash to be an investor.

Of course, it doesn't make sense, ultimately, to lump together the PDA and the pen-based computing markets as I just did. But, while the two markets are potentially divergent, at the moment each of them consists of: 1. Newton and 2. background noise. Newton MessagePad sales, though unimpressive, far outdistance the competition. The dominance of a small market is a fragile thing, though, and Newton could become relatively less important as the markets grow. But for now, Newton is where the sales and development work are happening.

What development work am I talking about?

As of last September, when a compendium was prepared, there were over 100 commercial products that Apple knew about. This breaks down into some 50 companies each fielding a product or two and distributing independently, plus 30-some products distributed through Apple's StarCore.

What companies? There are a few established software companies, mostly ones that have experience writing "lite" software, like utilities, and mostly from the Apple universe: CE Software, Dubl-Click Software, Great Plains Software. There are the companies that were founded on a belief in the pen-based market: FingerTip Technologies, Palm Computing, Slate. And there are the vertical intrusions, companies that saw potential applications of Newton technology in their specialized markets: Educational Research Laboratories, HealthCare Communications, KPMG Peat Marwick.

That's the commercial picture. The shareware market is very active, with literally hundreds of products out there already, showing the predictable range in quality from Doesn't Actually Work/Crashes System Routinely to As Good As Mother Makes.

Among the better shareware products are some good developer utilities, ranging from Jason Harper's BeamToSelf, which lets you develop infrared beaming apps without buying two Newtons, to Chris Christensen's memory-manipulation utilities. There are also a lot of debugging aids, communications tools, and code examples in the free/shareware directories on GENie, AOL, eWorld, CompuServe, and on the net at comp.sys.newton.

The mandatory development environment for Newton development, though, is still Apple's Newton Toolkit (NTK), which is still priced for committed commercial and corporate developers at about $700. NewtonScript, a Newton-platform-specific object-oriented language, is the language of NTK.

But alternatives are emerging. As I write this, it's still not possible to write Newton applications in C or C++ (or even Pascal), but you can program the device in LISP, Basic, or a LOGO-like language called "Newt." The initial versions of these third-party language implementations are all pretty rudimentary, but it appears that it's about as easy to put a new language on a Newton as it was to put Tiny Basic on homebrew computers back in 1976.

Note that I said on a Newton.

NTK is a Macintosh application, with a Windows version hinted at Real Soon Now, but these languages run on the Newton. It might seem to make no sense to try to write programs on a Newton, even though handwriting recognition has matured to the point that Palm Computing is claiming 100 percent recognition at 30 words per minute with its recognition system for the Newton and other pen-based systems. But there is a nice shareware product that makes using a Newton for development at least a little less crazy: Typo turns any connected computer into a keyboard for the Newton. Doesn't have to be a Mac: Any machine running any communications software and connected via a serial cable can become the Newton's keyboard.

These developments are maybe interesting, maybe suggestive of further possibilities, but they are not C. I was trading phone messages with a developer last fall who had a massive project that he had ported to various UNIX systems, the Mac, and the PC, and now wanted to move to the Newton. It took several messages before I got him to realize that this was simply not possible. He could rewrite it from scratch in NewtonScript, or I could, but there was no way to port it, because Newton does not support C.

That may be changing, in a small way. Apple is apparently accelerating and extending its plan to open up Newton programming on a module-by-module basis. NewtonScript, an interpreted language, will remain the language in which apps are written, but it will be possible to compile selected chunks of code, and there is talk of providing hooks for modules written in other languages.

In defense of the current approach, it's worth noting that: 1. NewtonScript isn't that hard to learn; 2. the platform is so different that porting whole apps doesn't make much sense anyway; 3. NewtonScript does a lot of the interface work for the developer; and 4. Newton apps are necessarily small and simple and can be developed in far less time than commercial computer apps.

But NewtonScript is interpreted and can be criminally slow. Providing the ability to compile selected code is something Apple really needs to do.

There are a lot of things Apple needs to do. I think Apple has a mixed record on developer support for Newton.

Admittedly, these are unfamiliar waters.

What's interesting about the products available for the Newton today is that these are all small products, developed over a short time, with small investments. It's a different financial model, with a different profitability picture. Old models don't work here, and Apple is learning along with the developers, I suppose.

But should Apple teach this baby to swim by throwing it in unfamiliar waters and letting it learn by floundering?

As one developer whose company isn't yet supporting Newton pointed out to me, Apple isn't talking to Newton users. It seems to do more promotion of HyperCard add-ons than of Newton third-party products.

Ah, well. It's a new market, and it's still small. At best, a few horizontal vendors are making money.

But the vertical strategy looks very promising, at least for those who already own their target customer lists. Publishers of professional magazines and newsletters and organizations and so forth would seem to have an edge, which could pay off for those who are persistent. Apple is doing the right thing in picking vertical markets to push, the medical market in particular.

Some have criticized Apple for the high price of the NTK, saying that it costs four times the street price of the machine itself. I don't agree that it makes sense to compare price of MessagePad to the price of the NTK, but I do think Apple made a mistake in its recent revamping of its developer-support program. Restricting the developer CD, formerly free to all NTK purchasers, was a questionable decision. It sends a bad message when you discontinue any developer-support program. Sure, big developers who are in it for the long run will buy into a subscription program; but not all Newton developers are big guys.

Some of these developers are not rich enough to be an income source for you, Apple. That doesn't mean they aren't important in building markets and credibility for Newton. Don't overlook developers just because they're running lite.

Copyright © 1995, Dr. Dobb's Journal