Swift Java Boat Adventure: Part 2

Before we begin our programming adventure, there are a couple of things we need to cross off the list. "Articulate the obvious" I always say.

As programmers of (whatever) there are some things to think about. Being a programmer of a computer versus a user of a computer are two different things. Much as being the designer of a boat is different than being the pilot of an boat. 

Developers need CPU performance, cloud storage and screen real-estate to spread out and work. They need chairs and desks that support long hours of sitting, along with exercise and fitbits to improve quality of life.

The developer versus user mindsets are different, although we frequently do both. There is the mobile migration consideration:

Swift can migrate to iOS and

Java can migrate to Android

so we have some excellent symmetry for our Swift Java Boat experiment there.

For our experiment we might require that we be able to develop on more than one H/W and O/S platform, in deference to some degree of platform neutrality. For Swift we will use XCode on the Apple MacOS platform, knowing that it gives us the ability to export our work to iPads and iPhones. For Java we will use Netbeans on a PC or Mac platform knowing that we can then export our work to a host of Android devices, PC and even Mac desktops.



To first order, we have doubled the work necessary to field an app, but we have obtained something worthwhile - platform independence and even language independence. We might wonder if we should write our application in some third meta-language and then simply compile it for the destination language and hardware. 

Let's explore that idea:

One symptom that we are doing something right in the computation process is that the tool we are building is useful for the tool we are building. This kind of self-reference occurs in the real world too. I recently built a shelf out of cubes. I carried the hardware for the shelf of cubes in the cubes, so there is self-reference and utility in the mundane that gives us a clue we are on the right track. 

So in this we have a definition of a possible task, a task that uses itself and solves a problem at the same time. Consider a simple box and arrow system that lets us draw a box with some inputs and outputs, execute that as a program and draw the result on either platform, Swift or Java, Desktop or Mobile, PC or Mac, Apple or Android. Since we can use this to build other apps we have a healthy dose of self-reference. A portion of it should be written in itself!

This BoxAndArrow System will be complete when we can define a simple program like solving the quadratic equation, displaying the inputs and outputs visually with a proper user interface.

Fig. 1: A Simple Boxes and Arrows Application

Figure 1 shows a high level view of the program and how its execution environment would look on the destination device.

The internal structure of the program is illustrating in boxes and arrows graph form below. 

Fig. 2: Quadratic Graph internal Details

Note that it contains primitive operations like unary negation, addition, subtraction, division and, name distribution. But it also contains a composite operation that is a placeholder for blocks of IP that come from other sources. It would be implemented here as simply a chunk of code that executes that portion of the diagram. Note also that exception conditions that must be handled by the caller are provided for as part of wiring the module. These are details that will be "handled in the implementation", the most famous of software excuses ever.

We could market this tool as a simple equation grapher and monitor sales through the Apple and Google monetization portals respectively. This would accomplish the goals enumerated in part one of this series.

One Practical Note:
Building for the Apple platform requires $100 of Apple Developer Network payola. Building Java under the NetBeans and Android platforms is free.