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.

Swift Java Boat Adventure: Part 1

I care a lot about language. I care so much that I make my own rules. I even have to turn grammar checking off while I attempt to express myself... done!

I care about programming language:

• How it looks on the 'page'.
• The clarity with which it communicates.
• The ease with which someone can get the gist of my intention.(That someone could be me in sixth month’s time!)
• The degree of reuse I might obtain.
• The scalability of the design approach.
• The number of people fluent readers.
• The rapidity of development.
• The ability to build and monetize applications.

Compiled languages like C require a waiting period before you see the fruits of your labor, while interpreted languages like Lisp give you immediate and nearly constant gratification. I call this dichotomy:

Edit-Compile-Look (ECL), versus,

Interpret-This-Now (ITN).

Barry Schwartz says in his Ted Talk, The Paradox of Choice, that we have too many choices and that this apparent freedom actually ends up limiting us, depriving us of the very thing we sought. That is certainly true in the programming language world.

For many years TIOBE has been keeping track of this choice list as it varies like fashion hemlines from month to month and year to year. Here’s the long term list with the rank of the language by year. Java is currently in first place by a considerable margin with 21% adoption. Next is C with 16% adoption dropping precipitously to C++ at 6% adoption.

I have used six of these languages for production work and I want to say something about each of them, before introducting the current topic, the Java Swift Boat. 'Current' get it? Did you notice the picture at the top?

Java has improved to the point of being a useful language. It is fast enough to do pixel-wise graphics and portable enough to handle many devices, except Apple iOS-based products which we care about. It is properly structured and it is getting past the CLASSPATH and security disasters of years past which complicated doing ordinary and useful things. You can even do Lisp-style lamda functions, the functions of noname. It is among my top choices at this writing, but that is mostly convenience.

I have used 'C' since 1980 or so. Thirty-five years is a long time to endure progress without obsolescence. C is great, my favorite choice for the quick hack to solve problems rapidly. C does not scale particularly well and I have paid the price for that. It forces memory management decisions on the programmer, its principle downfall, but also its principal virtue. Nothing is faster in execution or slower in finding a bug than C. C trumps even assembly language for rapidly and efficiency for large projects. With C you can, with effort, telegraph your intentions properly.

C++ is the spoiled younger sibling of C. Some things are fixed, but at the price of significant and often needless complexity. Strings are safer in C++ and threads, if you care, are supported. I always start in 'C' then translate to C++ to make my code more elegant, compact, or objectified. 

That said, Objective-C is ugly on the page and I refuse to use it for that reason forever. This creates problems developing apps for Apple products since they are a married couple. That will bring us to our timely Swift Java Boat experiment in a minute. 'Timely', get it?

Python is nice on the page, but feels a little old-fashioned and clunky to me so I don't use it much. I've done one-minute videos to express enthusiasm and amusement.

I really like JavaScript. I have done production work with it and it is can excel with clarity. It has been obfuscated somewhat by the advent of new packages which increase capability at the cost of transparency, jQuery comes to mind. But at its base it is a nice prototyping language. You cannot beat the abundance of quality online tutorials for it that show execution real time. It is a little slow for computer graphics, despite monumental efforts, but nothing is better for rendering web pages or just general computation. It is like a blend of C and Lisp, where you can be lazy and not declare your variables. You can pull them out of thin air, willy-nilly and get away with it most of the time. 

I have done some work with Visual Basic .NET. My main objection to VB.Net is that it is a wholly owned subsidiary of Microsoft. The opposite of net-neutrality in the language domain if you will. When I am working in Excel, another wholly-owned M/S I use VB.Net and that's the end of it. It is not an IEEE standard language and I don't like anyone to own the languages I speak or program in if I can possibly help it. Java suffers a taint of this with Larry Ellison's Oracle acquisition of the language from Sun. Swift suffers a taint of this since it is owned by Apple. JavaScript is pure however an ECMA-262 vendor-neutral standard since the days of  the NetScape browser wars.

Perl has gotten a lot of leverage from webmasters and system administrators, but I avoid it for syntactic and historic mashup reasons, perhaps because I am fluent in Linux/Unix text processing tools that are more elegant for my daily grind purposes. I just don't need it.

Fortran was my first date programming language (not counting that fling with the Digi-Comp) and I used Hollerith punched cards to write my first programs on an IBM-360. "All I wanted to do was draw a parabola" properly, a quest  would set the tone for the next 40 years. This was when dinosaurs ruled the earth right before Lady Ada came on the scene.

Speaking of Ada, the Countess of Lovelace really deserved a better language. Ada was designed by committee. Its intended use was flight software and Department of Defense systems that were too important to fail. (Like too big to fail, only with thermonuclear devices.) Ada was slow out of the blocks, and too cumbersome to catch on. A sad story that I fortunately never wasted a moment of my time as it never got past the 'icky detector'. The scary thing is that more than one airplane is flying C code with questionable memory management which is why from time to time they do the nose-up dance at 30,000 feet for no good reason.

There are a couple of languages further down in the list worth mentioning in passing. Haskell is good for people like me who want to make everything a function but I've never bitten the bullet. I fiddled with Prolog because you could ask it questions to see if it really loved you, but our relationship never really went anywhere. My favorite is Lisp which I learned, fortunately, before Fortran corrupted my thinking.

I use wxMaxima for all my mathematics because it is free, in the public-domain, free of taint and pretty close to state-of-the-art, for my purposes anyway. Maxima is written in Lisp and I can solve problems in it, or its lovely base language Common Lisp rapidly. Rarely do I have to venture down to the that level, but when I do, it is pleasant enough to get the job done. It is a symbolic/functional/interpreted language - my favorite - but you cannot truly write deployable applications or do compute-intensive computer graphics with it. You can however solve all the math problems computer graphics and engineering require, but those results must be translated to nVidia, C or Java if you want them to execute rapidly. Yes I know nVidia is a company not a language. But if you're really into it that statement makes sense.

So where does that leave us? Almost ready to board the Swift Java Boat for an experimental voyage. The voyage will be to develop a simple app in both Java and Swift and see which is:

• fastest to develop in
• fastest to execute
• makes the most money per unit time

Before we hop the Swift Java Boat a few words about Operating System (OS), Interactive Development Environment (IDE) and startup process. I hate to be longish or even boring, but this needs to be discussed. A small course correction can make a big difference in where we end up. So drink an honorary cup of Java for finishing this first episode. We will leave those to the next one.