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.