Programming Paradigms

That's the question Apple was asking in its pre-Christmas commercials. Apple's answer, predictably, was that Newton is what the world needs now: love and understanding, peace and productivity.

After buying a Newton MessagePad and accessories; reading numerous magazine articles, online chats, advertisements, press releases from both Apple and third-party vendors, and technical docs from Apple's PIE division; attending the first Newton Platform Development Conference; working through the sample code in the beta Newton Toolkit (NTK); and playing around at writing simple Newton apps, I've come to the conclusion that the real issue is what Newton is not.

Newton isn't simply a handheld personal digital assistant manufactured by Sharp and sold under Apple and Sharp logos. The Apple Newton MessagePad (or Sharp ExpertPad, which is essentially the same device) is only the first product based on Newton Technology. Others will be announced this year.

Newton isn't one form factor. Future Newtonian devices can be expected to look like anything from telephones to clipboards to blackboards.

Sorry, I shouldn't have said, "look like telephones." I should have said, "be telephones." At that point, these devices will start to be actual consumer products, which Newton isn't today, despite the charter of Apple's PIE division (to which Newton belongs).

Newton isn't just a line of Apple products. Apple is licensing the Newton software technology to other vendors, who will build their own devices and sell them under their own labels. Thus, the future of Newton is not solely in Apple's hands.

Newton isn't dependent on a single processor. Although current devices use the ARM610 RISC chip, the applications written for Newton compile to a byte-code representation, completely processor independent. No doubt, the Newton software itself will be implemented on other processors. My guess is that the PowerPC chip will be an early port. (Yes, Newton pays for processor independence in speed--more about this shortly.)

Newton is an operating system. MacWeek columnist Don Crabb has even suggested replacing the current Macintosh Finder with something more Newtonian. But it isn't a computer operating system. Newton devices aren't computers and aren't designed to do things that computers do. The concept behind Newton, apparently, was something like this: Who hasn't said, "I can handle the big things; it's the nagging little things that hang me up."? Newton is for the little things.

While I'm saying what Newton isn't, I will also address some of the initial (mis?)perceptions of the MessagePad.

Perception: The handwriting recognition is inadequate.

Reality: The MessagePad suffered for not being what editors and writers wanted it to be, taking some really excessive abuse for the perceived deficiencies in its handwriting recognition. But it's not supposed to be a substitute for a reporter's notebook. In a more appropriate use, say as a tool for a field-service technician, handwriting recognition is less important. That said, I agree that MessagePad's handwriting recognition is inadequate. But that doesn't make the device unusable.

Perception: Some pieces are missing: If this is a communication device, where's the communication?

Reality: Dead on. But since release, Newton has collected some communication aids. The Connection Kit lets you move files to and from a Mac or a Windows machine (there are two versions) and supports some file synchronization. There's a 9600-baud fax modem the size of a cigarette pack, a modem on a PCMCIA card, a pager on a card (plug the card in and the page messages become text you can save or edit), Apple's NewtonMail electronic-mail service with links to most other services, a third-party service that bridges from an e-mail service to a paging service so you can get e-mail via the pager card, and some other things. These all cost extra, of course. A future version of the MessagePad may have more communication capabilities built in.

Perception: At $700, it costs too much.

Reality: By the time you've added the necessary connection kit, fax modem, RAM card, and battery pack, it'll cost you a lot more than $700.

In December, MessagePad in hand, I attended the first Newton Platform Development Conference. Usually I cover these conferences as press, but this time I was there as a developer.

Nonetheless, my journalistic antennae were up, scoping out the crowd. As soon as I arrive at one of these events, I ask myself, who are these people? In this case, I got the impression of a motley group. There were surely more women than at any developer conference I've attended. And more nontechnical or at least less-technical people. There were more people who did not identify themselves as developers. A man with whom I ate lunch seemed typical: He had hit upon a vertical-market niche about which he knew a thing or two, he said, and was planning to sell Newton MessagePads, with his software installed, directly into this market.

That was one type of attendee, the vertical expert. There were also a lot of professional developers and quite a few marginal hackers (like me, doing my bit to pull down the curve). But on average, this seemed to be not quite the technical audience you'd see at OOPSLA.

Another attendee told me afterward that he had talked to several Windows developers at the show. Were they concerned that Apple hadn't released the Windows version of the NTK yet? No, they were willing to buy a Mac to program on. Although not interested in developing for the Mac, they had no objection to developing on the Mac. At the very least the story shows that Newton is being perceived correctly as a new platform, having nothing to do with the Macintosh.

The conference was organized along three tracks: International Newton Marketplace (marketing), Orientation to Newton Development (summaries of chapters in the NTK manual), and Advanced Newton Development (the good stuff). I skipped back and forth between sessions in the last two tracks and picked other people's brains during breaks to get the goods on the marketing sessions.

I attended sessions on NewtonScript and the Newton object model (soups and stores are the key words there) and view systems; prototypes and communications; and a session on intelligent assistance, or IA.

IA is a technology that you can implement in your apps that allows the user to select some text (or sometimes let IA guess what text should be selected), tap the Assist button, and have the text interpreted as a command, which IA will then attempt to execute. Commands that IA already understands include things like:

• Remember trim hedge (adds "trim hedges" to your to-do list).
• Call Mom at work (finds any name entries that include "Mom" as part of their data, offers you the list if more than one matches, retrieves the work phone number for the selected Mom, checks to see if area code or dialing prefix is necessary, and offers to dial Mom).
• Lunch with Jake Tue (schedules a 12:00 appointment with Jake for next Tuesday).
• Fax this to Larry (prepares a fax cover sheet and offers to fax the current document to Larry, using his fax number, of course).
• Birthday Mike 12/10 (creates an annual reminder of Mike's birthday on December 10).

Nevertheless, I think IA is an interesting interface element. Consider: The user may invoke your app via some verb like "pay" without ever clicking on an icon or really thinking about the fact that your application is what's doing the job. Applications that use IA effectively can feel like disembodied capabilities. Intriguing.

On the last day of the conference, there was a special, unannounced session typical of Apple conferences. It was announced early on the first day--typical for unannounced Apple events. Speculation was rife that this would be a sneak peek at the clipboard-format Newton. Nope. It was, atypically, something with more substance than flash.

The problem: Compiling to byte code for portability incurs a cost in execution speed. Newton apps that I have seen tend not to be horribly handicapped by this, but even the bundled apps can be annoyingly slow, and it's not hard to imagine apps that will drag the machine to a grinding halt.

The solution: The Father of NewtonScript, Walter Smith, is working on an enhancement to the Toolkit that will allow native-mode compilation and optimization for specific hardware, on a function-by-function basis. He showed some examples. A QuickSort routine, written in NewtonScript, was speeded up by a factor of 40 by taking it native. A compute-and-draw routine from an early version of the Maze game Claris is distributing was speeded up by a factor of seven.

This isn't going to be of any use for Toolbox calls, but for compute-intensive code, it ought to be very nice.

Here's how it will work when Newton is ported to other processors: You write one app, but flag the functions that you want to have run native. You deliver it on various platforms. On those platforms that have implemented native-code optimization, this will be applied to your routine; on others, you'll just get the usual byte code.

Right. In neither case do you get to program in the native language of the target processor and do your own optimizing. That's the price of portability.

As I run through some of the components and capabilities of the NTK development system, please understand that this is not a review. NTK is not, as I write this, a released product. Some chapters in the doc are yet to be written in the version that I have, and much of the sample code is "unblessed" (in other words, back up your system before you download it).

NTK consists, primarily, of the NTK application, something called BookMaker, scores of pieces of sample code, and what's shaping up to be pretty decent printed documentation.

NTK itself looks a little like Symantec's Think environment, but has a flavor all its own.

As with Think, your application in progress is called a "project." Its components can be viewed and accessed via a Project window; there's also a Layout window, any number of Browser windows that you create, and an Inspector window, where you can enter NewtonScript code, execute it remotely on a connected Newton, and get back results.

The Layout window is a visual representation of the Newton screen; although it is not an emulator, it does have a preview mode that shows how objects will appear on the screen. There's also a palette of object prototypes (not the right terminology) that can be dragged onto the Layout.

There's an additional file named MessagePad, which you drag into a folder named Platforms. When there are other platforms, you will be able to drag a different platform file into the folder, and the Layout window will reflect its form factor.

NTK will let a lot of people develop applications who would not be able to do so for the Mac or for Windows. Simple applications can be put together via visual programming methods, using supplied components.

The protoApp template is one such component. In NTK, you can select the protoApp template from a long list of templates or click on its icon in a palette, then drag out a rectangle in the Layout window. This gives you a standard application with frame, title, and go-away box. Standard buttons and text-entry windows can be dragged into the application window just as easily.

These visual elements are called "views." They are the visual representation of objects whose properties reside partly in RAM, partly in ROM, dragging one of them inside another establishes an inheritance relationship between them. But the beginning developer doesn't need to know all this. Nor does he or she need to know that building from templates draws on a different, independent inheritance scheme, or how these inheritance schemes interrelate. The beginning developer can just drag the pieces into place--adding text to titles, picking properties from lists--and build the app without writing any code.

As a result, some simple Newton apps have appeared very quickly. Some of these are highly content oriented. NTK includes the BookMaker application (not supplied with the first betas) which is particularly accessible to nonprogramming developers, like those people I saw at the conference.

BookMaker is an aid to creating electronic books that are to be delivered on Newton platforms. Is this a good format for reading books? I consider it part of my job to take such questions seriously, so I actually read, on a Newton MessagePad, Joseph Conrad's Heart of Darkness, which someone has poured into an electronic book. My conclusion: Fewer typos would have made this homage to Conrad more convincing, but it was easy enough to read, way more convenient than a PowerBook. (And yes, I have done the dirty work to support that comparison: Last summer, I read Jurassic Park on a PowerBook, so you don't have to.)

But the kinds of books that really make sense on this platform are reference books for communications and travel, and job-related manuals for sales and field-service people. A book of 800 numbers, for example. You can already find some good examples of such books on various online services.

With BookMaker, you mark up a word-processing document with a special markup language (simple dot commands, like .Title Heart of Darkness and .Author Joseph Conrad), then run it through BookMaker. You get a Newton package, which you can augment using NTK. Every element is scriptable with the full power of NewtonScript. You can add any degree of power to the book you create through this method, including adding IA. But the markup language itself has a lot of capabilities, such as automatic index and table of contents generation, mixed font specification, inclusion of PICTs and bitmaps, and bookmarks and other navigational aids.

Of course, BookMaker also has limitations. You have to work around the file-size limitation of Claris XTND technology, on which BookMaker relies for reading files. And you are currently limited to the Geneva and New York fonts, which are in the Newton ROM. In the future, you'll be able to download fonts.

That's the low end of Newton development. You can develop real commercial apps without much effort and with zero to very little programming. That model won't work for most interesting apps, though. These will require that you get seriously into NewtonScript, an interesting language. We'll do just that in a future column. You can put a significant amount of effort into a Newton app, particularly if you get into communications and device control. But nowhere does Newton development approach the complexities of Windows or Mac development.

It was encouraging to hear Michael Spindler speak, as he did at the conference, about the need for a new approach to software-distribution channels. He spoke of the need to open things up for the small developer and made it sound like that was a priority for Apple. I hope it is, and that he wasn't just giving a sales pitch for Apple's new online service. This Newton software market is not, or had better not be, a shelf-space battleground.

There seem to be indications that Apple is serious about small developers in the Newton software market. Of the various distribution methods discussed at the conference (PCMCIA cards, NewtonMail, Apple's StarCore and PIE Partners programs, online services, Mac or PC disks), StarCore sounds particularly interesting. It's a comarketing program, but the StarCore folks seem willing to entertain quite a variety of different plans, tailored to the particular needs of the developer. I heard some really small developers who had made their pitch to StarCore and had not received a definite No.

Copyright © 1994, Dr. Dobb's Journal