The occasion of the last "Paradigms" column of this year is to tie up some long-dangling loose ends and float some semi-detatched observations on parallel processing, transputers, fractal graphics, multiparadigm programming, and hypertext, and other hyperstuff. And to mention a few books that are unlikely to show up in "Programmer's Bookshelf," but that still may be worth a look, for reasons to be explained herein.
Last November, I wrote about the MINOS system, perhaps the earliest practical implementation of neural net technology. I also described an even earlier neural net system in something I referred to as the ADAM system. One reader wrote to ask for sources on the ADAM computer. The body of literature on this device is enormous, but a primary source is Genesis, which, while of disputable reliability and often weak on technical detail, is at least widely available.
Quite some time ago I allowed a probably overly harsh assessment of the transputer architecture to appear in this column. One reader, a former Inmos employee, wrote to take me to task for this, but time and space didn't allow printing his comments then. Belatedly, here is a brief defense of the Inmos transputer:
The lack of a register add is offset by the RISC-like nature of the stack workspace access being as quick as an R-to-R add in 33nS on-chip memory (the 4 Kbytes are like 1000 word-length registers). The 30MHz T800 processor puts the fastest 68030/68882 pair to shame speedwise, in most applications.... I understand that there are plenty of things to be critical of in the transputer, but the structure isn't one of them! I still support the transputer and can honestly say after seeing many benchmarks and comparisons that the transputer definitely keeps up with the other processors and still provides a direct method of parallelization that no other processor can approach.
The latest transputer-based application whose notice crossed my desk is Equator, a 3-D spreadsheet for the Mac II with a transputer board, from Tri-Millennium Corp. (40 Horace Street, Needham, MA 02194). It looks interesting because: Speed and memory size are scalable with additional processors; the spreadsheet will read and save in standard spreadsheet formats; Equator is priced competitively with other spreadsheet software; and it looks like one of the few commercial applications available that could provide some useful real-world benchmarking for parallel processing.
I have recently had a chance to play around with release 2.0 Prograph from TGSSystem (Halifax, Nova Scotia). Prograph is a Macintosh-based development system that purports to be a multiparadigmatic system, supporting object-oriented programming, dataflow programming, and visual programming paradigms. Well purports may be unfair; the product is just described as an object-oriented visual programming language and software development environment. Besides, while it does support dataflow specification of program execution, maybe being multiparadigmatic isn't much of a distinction these days. Prograph is interesting, though, from a couple of perspectives. First, though, the component list and system requirements. Prograph consists of an editor/interpreter for its visual programming language, a compiler, an application builder, and a number of examples and online tutorial aids. It runs on a Mac Plus or above with 2-Mbyte RAM, a hard disk, and System software Version 6 or above.
As soon as you invoke the editor, you're up against the visual programming language, and using it is certainly a different experience from conventional programming. Prograph is not the only visual programming language around, even for the Mac: Prototyper and VIP are competitors. Its approach to visual programming, though, is its own, and my first reaction is positive.
Lots of products and approaches have been labeled as visual programming systems. There are diagrammatic systems that communicate aspects of the structure of the program, or that permit manipulation of that structure, using flowcharts or dataflow diagrams or state transition diagrams; there are table-based and form-based programming systems for producing databases; and there are iconic languages in which icons take the place of linguistic components in conventional languages. Prograph is in the iconic camp, but has characteristics of other approaches. Icons are strung together via dataflow links, for example.
The visual approach in Prograph is not cosmetic: The whole system is fundamentally visual, with multiple windows for editing and executing programs and for specifying classes and methods. Even the debugging environment is visual. The icons and dataflow diagrams constructed from them are not pictures representing blocks of code, but executable items. Click on them and they do their thing. The visual elements really are the program.
So what is it like to program with icons and diagrams? It comes down to a lot of picking items from lists and pasting them where you want them, at the most mundane level. And typing names into newly created objects. Most of the icons are really just variously shaped text boxes, which is to be expected. They are icons, not Chinese ideographs, and the only way the set of icons can be extensible is through the use of existing linguistic devices, meaning names spelled out with letters. Most of the Mac Toolbox calls are represented iconically and accessed as Mac Methods. Their names are not editable, but are fixed to be the names given for Pascal functions and procedures in Inside Macintosh.
With Prograph I get more of a sense that it works than with other visual programming systems I've looked at. The icons and the dataflow links that tie them together do make a lot of sense. Working with the system actually makes programming feel more like building a structure from components, and, at least in the simple examples I've played with, gives me a clearer sense of the structure of the program than I get from programming in a conventional language. A moderately complex application might be another matter entirely.
I also like the commenting style built into the system. Since the program itself consists of graphical elements -- structures of boxes -- the snatches of text pasted next to the boxes or in the margins stand out much more than I've seen comments stand out in any conventional code. They are clearly in a different language. The message that comes through is: If it's a block of text, it's a comment.
The dataflow model is inherently concurrent, and it's a fine-grained concurrency based on data availability. That's true of any dataflow system, and it is completely academic on a single processor machine like the Mac, but TGSSystems hints at the likelihood of making use of the concurrency in some future release that would support a parallel processing architecture, though not necessarily in an Apple box. I had wondered how dataflow specification matches with object-oriented programming, and got at least a partial answer in the fact that Prograph allows the data that flows along the links to be instances of object-oriented classes, as well as elementary data types. More than one data item can be passed along a link, with the node receiving this pool of data recognizing the value it needs and selecting it: This is dynamic dataflow.
There's an interesting point about Prograph's positioning. The marketing copy on the box explicitly refers to HyperCard. This is curious, because Prograph is clearly more powerful and more complex than HyperCard and other products of that hyperilk. The point seems to be to project it as falling midway between HyperCard and Pascal or C on some spectrum. TGSSystems calls Prograph a very high-level language and a fifth-generation tool.
Perhaps what they have in mind in invoking HyperCard is the Application Builder. This is a toolkit of editors and OOP classes for building Mac applications. It's purely an alternative for beginners or for those occasions when building from the ground up is not necessary, but it does give Prograph the aspect of an application generator. This should aid the new Mac developer, for whom the advice has always been: First, read Inside Macintosh Volumes 1-5 (and counting). With Prograph's approach, a developer ought to be able to start programming and refer to IM as needed. And it may explain the reference to HyperCard.
One thing that Prograph doesn't claim to be is hypertext. I don't know why not; everybody in the world seems to be jumping on that bandwagon. Hypertext is creeping into everything I read. There is definitely something there, but the hype can be off-putting. The best source I know of on the subject, touching on its roots and underlying philosophy and current implementations, is Macintosh Hypermedia by Michael Fraase (Scott, Foresman, 1990). Too bad it's Mac-specific.
I don't recommend the book The Society of Text (Edward Barrett, ed., MIT Press, 1989) unless you're really into hypertext. It seems to be oriented toward academics first and people who work with text second; not toward software authors at all. I do recommend one particular article in the book, though, to any readers who suspect that they might find themselves pressed against their will to incorporate a hypertext approach into some software project. It's "The Missing Link: Why We're All Doing Hypertext Wrong" by Norman Meyerowitz, and it could help to argue your way out of something you don't want to do.
Meyerowitz's view is that hypertex has to be integrated into the operating system before it really makes sense. What we have now, he says, are insular tools that may solve some specific problem but that aren't what he has in mind when he thinks of hypertext. HyperCard may not be the best example of the hypertext state of the art, but it amply demonstrates Meyerowitz's concerns. You can do hypertextish things in HyperCard, but the problem is that you have to be in HyperCard to do them. And what you probably want, or would want if you really knew why you should want to do hypertextish things, is to do them where you are with what you've got.
Meyerowitz, who heads Brown University's Intermedia project in hypertext or hypermedia, has the credentials to make his view of what hypertext is supposed to be worth noting. What he thinks is required is to tie the hypertexting into the operating system, and the way to do that is to add the element of a navigational link at the appropriate operating system level. Meyerowitz takes this to be the level of desktop tools in Windows or the Mac or similar GUI systems. Meyerowitz and his colleagues have actually implemented such links in their Intermedia system, but this is a case of prototyping the future, to use his words. The fact is, existing operating systems don't have such navigational links, therefore they can't support true hypertext, and anything short of true hypertext is just pseudohypertext, or in other words, just the current fad. That, anyway, is an argument that you can use.
Since I have previously in this column mentioned ToolBook, Asymetrix's HyperCard-like product for Windows 3.0, I'll pass on the news that Asymetrix is shipping its ToolBook Author's Resource Kit (ARK) for $450. The ARK includes a master copy of the runtime version of ToolBook and a license to distribute royalty-free copies of the runtime version and the DLLs included with the full version of ToolBook. It also includes tech support, a utility program for examining and changing properties of books you create with ToolBook, online books of ideas on design, and Script Remover, an application that lets you remove the readable source from your ToolBook application before distributing them. The telephone number, if you want to order the ARK or to find out about the developer program, is 206-637-1500.
And while we're on the subject, HyperCard itself will, I suspect, begin to evolve into clearly distinguished user and developer versions, now that it is a Claris product.
A poorly written press release resulted in a MacWeek story to the effect that Apple would be selling a crippled version with new systems, basically a runtime HyperCard, with the developer version available at a competitive price. Since anything that could be considered competitive with HyperCard costs an order of magnitude more than HyperCard, and since the HyperCard user community felt that it had a moral commitment from Apple that HyperCard would continue to be distributed like system software, this did not go over well. I read the press release, and the confusion was all Apple's fault.
The true story is -- but come to think of it, I only know what the true story is this week. Apple's reingestion of Claris seems not to be proceeding altogether smoothly, and there may be further burps. When the grumbling stops and everything settles down, we'll have a better idea what HyperCard's future will be. It appears, though, that Claris knows that if it is going to create two versions of HyperCard, it should do so by adding functionality to the developer version, not by removing it from the user version.
I have discussed fractal flora here in past columns. Anyone interested in pursuing the topic of how fractal graphics can be applied to the study and simulation of plant structure and growth should get hold of The Algorithmic Beauty of Plants, by Przemyslaw Prusinkiewicz and Aristid Lindenmayer (Springer-Verlag, 1990). It's a beautiful book, as well as a good presentation of the major algorithms in this field. It is based on Aristid Lindenmayer's L-systems approach, which I was surprised to learn dates back to 1968. The book deals with modeling plant development, particular plant organs and cellular structures, as well as producing animated displays of plants growing. The dust jacket describes the subject matter as an attempt to re-create the structures of life, and that seems pretty accurate to me.
The authors supply enough theory and pseudocode to make their points clear, but there are no type-and-run examples. In fact, the system that the authors used to produce the beautiful plant forms reproduced in the book is not something they'd be likely -- or able -- to reproduce in the book. It sounds interesting enough to justify a book on its own. The authors refer to the system as a virtual laboratory, a microworld which can be explored under the guidance of a hypertext system. Yeah, hypertext again. By microworld, they mean an interactive environment for creating and conducting simulated experiments.
They got the basic ideas for their virtual laboratory from Ted Nelson's Computer Lib/Dream Machines (their reference: Ted Nelson, 1974; latest edition, Tempus Books, Microsoft Press, 1987). Ted Nelson, as the whole world knows, coined the term hypertext and has devoted more energy to its achievement than anyone else in the world. And, just to make sure I get all the links linked, I should mention that Norman Meyerowitz took over Brown University's hypertext research from Andries van Dam, who codesigned the world's first hypertext editing system in 1967 with Ted Nelson and a group of Brown undergraduates.
Wherever they got the idea, the virtual laboratory sounds nifty. I wish someone would buy me one for Christmas. The book is pretty enough to be a gift, though. See if you can get someone to buy it for you.
Shared Minds by Michael Shrage (Random House, 1990) is a book worth taking a look at for what it has to say about the future direction of software development. It's a nontechnical treatment of the phenomenon of collaborative computing: groupware and such-like stuff. What Shrage has to say about collaborative efforts, particularly in science, runs counter to a widespread spirit of do-it-yourself-ism in the personal computer field. As someone who has been in deep retreat from collaborative efforts for the past three years, I found that it made me think a little more deeply about individual vs. group efforts. It may make you question some of your deeply held rugged individualism, or it may make you mad, or it may make a lot of sense. In any case, it makes good leisure-time reading. The Mac Is Not a Typewriter by Robin Williams (a different Robin Williams) (Peachpit Press, 1990) is not a book that DDJ readers need to read, but it is an excellent gift book for anyone you know who is nontechnical and is getting to know the Macintosh. It's filled with simple but useful advice on producing printed output from the Mac that even professionals may not handle well. Things like not double-spacing after periods, using real quotes and apostrophes, handling punctuation and parentheses, advice on typefaces: It's not a complete treatise on grammar or type handling, but a wise selection of the most helpful tips for the broadest possible audience. It's a quick read, and only costs $9.95. Give it to someone you like about that much.
See you next year!
MINOS Addition
Transputer Refuter
Multiparadigmatic Programming
Hypertext and Hyperstuff
Holiday Reading