Volume Number: 13 (1997)
Issue Number: 4
Column Tag: Visual Programming

Building a Visual Programming Language

By Steve Wilson, Palo Alto, CA

Designing and implementing intelligent, user-friendly, commercial software with Prograph

Back in late 1993, my business partner (and father) Dave Wilson and I decided we were going to create a new Macintosh application. We wanted to build an app that would appeal to a wide range of users and would fill a real need in the Mac community. We decided we would write a spreadsheet - but not just any spreadsheet. We locked ourselves in a conference room with a white board for two days, and designed a visual programming language (VPL) for solving the same type of problems typically solved with a spreadsheet. The product which resulted was called Let's Keep It Simple Spreadsheet (or L.K.I.S.S. for short). L.K.I.S.S. 1.0 was first released in May 1996, and was very well received. In January 1997 we released version 2.0 of the product and changed the name to Spreadsheet 2000.

In this article I will give an overview of the VPL we created and also talk briefly about our experiences implementing it. We used Prograph CPX, another VPL to write Spreadsheet 2000, and as you can imagine, this led to some interesting experiences.

A spreadsheet is a type of programming language. It just isn't a good one! Anyone who has ever built a non-trivial spreadsheet knows how hard it is to do without causing unseen errors. One of the fundamental problems with spreadsheets is that your formulas, labels, and data are all mixed together. In fact, a single cell often contains a text-based formula hidden underneath the answer produced by the formula, as shown in Figure 1.

Figure 1. Cell A4 looks like data, but it is actually a formula.

We set out to design a Macintosh-like user interface to fix this and other problems with the traditional spreadsheet metaphor. Spreadsheet 2000 is the program we built. Figure 2 shows a simple calculation done with Spreadsheet 2000 as it would appear on your screen.

Figure 2. The same calculation done with Spreadsheet 2000.

Spreadsheet 2000 calculations are easy to understand because you can see what you're doing. We use visible operators instead of text-based formulas to perform the work. We feel that this will lead to more accurate results, as well as a shallower learning curve. Lastly, we hope that Spreadsheet 2000 makes problem solving more fun.

Figure 3. A screen shot of Spreadsheet 2000.

Is Spreadsheet 2000 really a spreadsheet? I get asked that question a lot, and I'm not sure I know the answer. It probably isn't, but it helps the marketing people to call it one. I can, however, tell you what Spreadsheet 2000 is: Spreadsheet 2000 is an object-based, data flow, visual programming language. I hesitate to say that Spreadsheet 2000 is object oriented, because that term carries so much intellectual baggage, but objects do play a big role in our language. The idea of treating data as objects, is one of the things that makes Spreadsheet 2000 so powerful.

There are 4 major classes of objects in Spreadsheet 2000: Grids, Operators, Charts, and Notes. Each of these classes of object can come in many different shapes and sizes (you might even call them subclasses), and some samples are shown in Figure 4. The two most important of these classes are Grids and Operators.

Figure 4. Spreadsheet 2000 Objects.

Grids are basically collections of cells. Grids usually contain numbers, but you can also add labels which hold strings. Note that grids do not contain formulas, we use separate visual operators instead. There are 4 basic "subclasses" of Grid: Table, Row, Column, and Cell. These types are differentiated only by their shape. A Table is a two dimensional collection of cells. A Row is a horizontal collection of cells, where a Column is organized vertically. The fact that each of these subclasses are treated differently allows for some interesting behavior, which I'll explain as we talk about Operators.

Operators are the objects which manipulate the data stored in Grids. Operators display an interesting kind of polymorphism which resembles function overloading in C++. Basically, Operators perform differently depending on what subclasses of Grid are connected to its inputs and outputs. Spreadsheet 2000's visual language is centered around the idea of overloaded operators. Let's look at an example.

Figure 5. Adding by Column.

Figure 5 shows a simple calculation with Spreadsheet 2000. It is using the + operator to add some numbers together. You will notice that it is adding the numbers by column. How does it know that is what you wanted? Because the output of the + operator is connected to a Row object. Can we get it to add across instead of adding down? Sure we can.

Figure 6. Adding two ways.

In Figure 6 we just dropped in a Column object and connected the output of the + operator to the input of the Column object. Now that the + operator is attached to a Column it acts differently, adding across instead of down. Note that this single operator can service both grids. We can even take this one step further, as shown in Figure 7.

Figure 7. Adding three ways.

Now we drop in a single cell and connect the operator to it. Since we are feeding into a single cell, it adds up all the numbers in the original grid and sums them together.

Let's take a look at another example of Spreadsheet 2000 polymorphism. In this case we'll look at an operator with 2 inputs instead of just one.

Figure 8. Multiply a Table times a Cell.

Figure 8 shows the use of the A*B operator. In this case it is multiplying a Table times a Cell. As you can see from the figure, it is multiplying each value in the Table object times the value contained in the Cell object. Now what would happen if we multiplied a Table times a Row? Let's grab the resize box on the Cell and stretch it into a Row. This effectively changes the class of that object. Then let's put a number into the new cell that's created inside the Row object.

Figure 9. Multiplying a Table times a Row.

Can you see what it is happening in Figure 9? It is multiplying the first column in the Table times the first cell in the Row, and the second column in the Table times the second cell in the Row. Since we changed the class of that Grid from a Cell to a Row (by stretching it) the A*B operator now changes its behavior. That's pretty cool, but you're asking why would I do that? Let's build a simple "real world" example using these ideas.

Let's say that we want to build a simple budget, so that we can see our expenses for the year. We have a set of expenses which occur on a daily, weekly, or monthly basis and we want to see what comprises the bulk of our expenditures. We can use the two operators we explored in the last section to accomplish this.

Figure 10. Our Budget.

Figure 10 shows the document we constructed to solve this problem. Since daily expenses will occur 365 times each year, weekly 52 times, and monthly 12 times we can use the A*B operator to compute the total amount spent per year on each item. We can then add the columns in that Grid together to get a single Column using the + operator. Lastly we feed that Column into a Chart so we can see our results.

That's pretty cool for simple stuff, such as addition and multiplication, but can you do anything sophisticated with this? We certainly hope so. There is a set of 90 operators which are built into Spreadsheet 2000. These include operators for trigonometric functions, scientific functions, date and time functions, sorting, searching and even Boolean logic and loops. That gives you a lot of flexibility, but we can't claim to have built in every conceivable operator. That's why we let you build your own! Let's look at an example of doing that.

On our palette full of operators we have objects for computing Square and Square Root. These are commonly used functions, and we wanted people to have easy access to them. Now let's say that you often need to take the cube root of a number in your calculations. We don't have a Cube Root operator built into the program, but we do have a two-input operator called Root, which can take the n-th root of any number. You could use that (as shown in Figure 11).

Figure 11. Finding the cube root of 27.

Now that works fine, except it seems like a like of work for something you'll want to do often. That is what Custom Operators are for. Let's look at how we could build a new Cube Root operator. First you need to select the items which are central to your calculation. You can do that by shift-clicking or drag-selecting. Once you have these items selected you'll want to choose the Crunch menu item.

Figure 12. Building a Cube Root operator.

After you choose Crunch, you'll be prompted to give your new operator a name. The result is a new Cube Root operator which can be used again in this document or in other documents. You can even save this operator into one of your own custom palettes. You can then give these palette files to your friends, or even upload them to the Internet. We hope to build a cottage industry around people building and sharing custom operators and other Spreadsheet 2000 documents. We have even built a site on the web where people can upload and download Spreadsheet 2000 documents and operators. Visit Emergent Behavior's Spreadsheet 2000 web page http://www.emer.com/s2k for more info.

We always get a good response from people at user groups and trade shows when we demo Spreadsheet 2000. Developers, in particular, seem to really like it. After the demo they often ask me what I used to write it, and I tell them Prograph CPX. After the poor programmer pulls his jaw off the floor, and puts his eye balls back in their sockets, he asks me if I'm kidding. If you haven't yet heard of Prograph then you should check out some of the great articles from past MacTechs which are referenced at the end of the article or stop by http://www.pictorius.com. Figure 13 shows an example of some Prograph source code. In this article I'm not going to dwell on the technical details of Prograph (there are many fine MacTech articles which do that). I want to give you my general impressions from using it to build a large application.

Figure 13. The Prograph source for closing my about box.

It seems that many people have heard of Prograph, and some have even tried it, but few people believe that Prograph can be used to write a "real" application. I'm here to tell you that you can. Prograph often get's lumped into the same category with products like MicroBrew (formerly AppWare), HyperCard or MacroMind Director. The fact is that Prograph is a much more powerful general purpose programming tool. With tools like MicroBrew, HyperCard or Director you can very quickly build certain types of programs, but you generally run into a wall where you must write some kind of C code to get a particular behavior you want. HyperCard XCMDs are an example of this. Although Prograph can import existing C code, Prograph doesn't have these limitations, and Spreadsheet 2000 illustrates how powerful Prograph can be. Let's look at some facts about Spreadsheet 2000.

Spreadsheet 2000 is written in 100% pure Prograph, and supports the basics you expect from a real application. It is a stand-alone, double-clickable application which supports multiple windows and documents, floating toolbars and cut/copy/paste. It even supports some things you might not expect, such as Drag Manager. One thing to keep in mind is the fact that I didn't write any external C code. Prograph gives you full access to the Mac Toolbox, so there isn't any kind of application you can't write with Prograph. One key detail that shouldn't be left out is that Spreadsheet 2000 is PowerMac native. Prograph has compilers which generate real 68k and PPC assembly language. (An Intel x86 compiler is also in Beta.) You don't need any run-time baggage, such as byte code interpreters or run-time engines. You are a first class citizen on the desktop.

Now that we've established that it is possible to write serious applications with Prograph, we come to the question of whether it is practical. Once again, I believe the answer is yes. Spreadsheet 2000 is implemented using about 450 Prograph classes which contain about 4000 total methods. About 150 of those classes are the ABC Application Framework which comes with Prograph CPX. About 50 of those classes are add on libraries from third parties, and the rest are Spreadsheet 2000 specific. 450 classes is a fair sized OOP project by most standards, and Prograph handles it without showing signs of stress. I should also mention that I use VOODOO from Unisoft for source code management. It does a great job of keeping track of the 100+ source code files which are used to build Spreadsheet 2000.

Prograph's greatest benefit is productivity. Version 1.0 of our application was written using about 2 programmer years of effort. Moving from version 1.0 to 2.0 took us about another 7 months. That may see like a lot, but that is nothing when compared with other productivity applications, especially when you consider that time includes Prograph's learning curve. I'm a pretty fair C++ programmer (I've taught Apple Developer University's course on Advanced C++ many times), but I just can't write code as fast in C++ as I can in Prograph. Add in the fact that Prograph's garbage collector takes care of most memory management tasks, and you can really start to see Prograph's benefits.

The other thing which needs to be mentioned here is debugging. Let's face it, what percentage of your time do you spend writing new code vs. debugging existing code? Prograph has the world's best debugging environment. I make this sweeping statement without apprehension. Prograph's environment is more conducive to debugging than any other. When you encounter an error in Prograph the machine doesn't bomb. Prograph halts the execution of your program and puts up a dialog explaining the difficulty. (See Figure 14 for an example.) You can then rollback execution of the program, make modifications to your source code and continue to run the program. I'm sure you've done the old: Compile, Link, Test, Modify, Compile, Link, Test, Modify cycle. With Prograph you can shorten that to: Test, Modify, Test, Modify.

Figure 14. Prograph offering assistance to fix a bug.

I've now made Prograph sound like the second coming, but I should fill you in on its limitations. Although Prograph can write any type of application there are types of programs which it cannot produce. Prograph cannot create stand-alone code resources which means you cannot build Photoshop filters or Netscape plug-ins. You also cannot currently build OpenDoc parts.

Performance is another issue of concern for many. Compiled Prograph code is not as fast as compiled C++ code. A program written in C++ will also generally be smaller, and require less RAM than an equivalent Prograph app. If speed and application size are your main concerns then you will want to experiment with Prograph some before committing major resources to Prograph.

I should add a couple more comments before closing this subject. First, the Toolbox is the Toolbox, no matter what language you use to call it. For example, a call to CopyBits doesn't take any longer when called from Prograph than from C++. The other comment is more qualitative, bad C++ code is slower than good Prograph code. Although Prograph is often slower than C++ for equivalent operations, your choice of algorithm may still be the most important issue. A bubble sort written in C++ will not be faster than a quick sort written in Prograph. Your skill as a programmer, and your knowledge of your problem domain is ultimately much more important than your choice of language.

Prograph is being actively supported and improved by Pictorius. Right now early versions of Prograph CPX for Windows are available. I've worked with some of these early releases and I was pleasantly surprised. Prograph is going to be a serious choice for developing your cross-platform applications

I hope you've enjoyed this brief exploration of visual programming. Visual programming languages are often quickly dismissed as toys, but I hope that the success of tools such as Spreadsheet 2000 and Prograph will change that. Although text based languages (and spreadsheets) will not disappear anytime soon, I think that visual alternatives will start to become a serious option more often. The best way to figure out if visual programming is right for you is to take a test drive. If you're interested in Prograph, there is a demo CD with a crippled version of the environment available from Pictorius.

In this article I've only scratched the surface of Spreadsheet 2000. There are a number of features, such as our reporting options which let you build simple front ends to your calculations, which I haven't addressed at all. If you're interested in Spreadsheet 2000 then you can get a demo off the web at http://www.emer.com/s2k. That is the best way to get a feel for the program. Have fun.

http://www.emer.com/s2k has all sorts of info on Spreadsheet 2000 and includes a FAQ and a library of documents for downloading.

http://www.emer.com/MadeWithPrograph is a list of over 40 Macintosh applications which have been written with Prograph CPX.

http://cocoa.apple.com Cocoa version DR/1 is a visual programming language for kids. It also happens to be written in Prograph CPX.

http://www.pictorius.com general info on Prograph CPX.