Apple's Language Holy War

In the late 1990s, we used to joke about language holy wars at Apple. Apple had purchased NeXT, in December 1996, for WebObjects and the NeXTSTEP operating system (which became Mac OS X and was recently rebranded as macOS). Since NeXTSTEP's release, in the late 1980s, the OS was built on Objective-C (a superset of ANSI C that was object oriented [OO]). In the mid-1990s, Java came along, from Sun Microsystem, and it quickly became the first, mainstream, OO language leading to a holy war between Objective–C and Java.

WebObjects was originally written in Objective-C, but, by WebObjects version 3.5, in 1997, it was fully bridged with Java using the cheekily named JOBS (Java to Objective-C Bridging Specification). A WebObjects developer could write code in Java and most every Java object had a corresponding Objective-C object wrapped and running in the background.

Java vs. Objective-C

Around WWDC 2000 or 2001, Apple settled the holy war by stating that Objective-C would be used on the client (Cocoa desktop development) and Java would be used on the server (WebObjects server development). But we'd still argue about the pros and cons of the two languages.

The strength of Java was that it was a strongly typed language. The strength of Objective-C was that it was a weakly typed language. So, the pros and cons were subjective. It really depended on your needs. Objective-C would let a developer "touch the metal" meaning a developer could write code to interact with a computer's low level memory. This is very powerful, but it requires a lot of responsibility on the software developer's part since they'd have to manually manage their program's memory usage by using pointer arithmetic. Pointer arithmetic allows a developer to directly touch values in the memory of a computer. If the developer makes a miscalculation, such as terminating a string incorrectly, it could cause the program to crash.

The selling point of Java, which was very similar to Objective-C, is that it didn't use memory pointers. Instead, Java code ran inside a virtual machine that acted like a sandbox between the executable code and the operating system. Since Java couldn't directly touch computer memory, it used references instead of pointers. The big joke in Java was, if you tried to call a method on an instance variable that was null, you'd throw a NullPointerException, which was a poor choice for an exception class name since Java didn't have pointers. That message class should have been NullReferenceException. An excellent solution for avoiding these bugs, called optionals (option types), has been implemented in Apple's Swift programming language, three years ago. But I digress.

Since Java ran inside a virtual machine, it was a little more complicated to talk directly to the OS. For example, if you needed to access the computer's file system then you probably shouldn't hard code something like "c:/ProgramFiles/tmp" since that wouldn't work if your Java code ran on a Mac (c:/ is the path to the main hard drive on a Windows computer, whereas macOS doesn't care about the physically drive, but, rather, the medium being accessed with a path like "/Volumes/Macintosh HD/Users/jmoreno/tmp."

Since the path to a file or folder (directory) on each OS was different, it required the software developer to use global variables that the Java virtual machine populated when it started up (on Windows, it's "c:/" and on macOS it's "/Volumes/Macintosh HD."

Not hard coding OS paths requires a bit of discipline, but it keeps the software developer honest and prepared if their code needs to run on a different OS than was originally intended. This type of discipline was key, in 2005, when Apple switched the Macintosh CPU from IBM's PowerPC chip to Intel's CPU. Without the public realizing it, Steve Jobs announced that Apple had been secretly developing Mac OS X for both CPUs and the time had come for Apple to switch to the same CPU that Windows ran on. This had the side effect of allowing Windows to run natively on a Mac using Apple's Boot Camp utility software.

Code Reviews

I have written a lot of sloppy code, in my time, and I discovered that group code reviews, weekly or biweekly, were a great help. This was the place where we could show off our code to the rest of our team; and the rest of the team could question anyone on the code they wrote. Most teams usually don't go out of their way to review someone else's code if it works as expected. Typically, it's not until a particular software developer has left a team when someone else has to read and review the departed team member's code. This can raise a lot of questions as to what the original purpose of the code was.

Good coding practices and discipline will pay dividends years down the road, so take the time to do it right. If not now, then when?

Reverse Planning

Reverse planning, also known as backward planning, is a simple concept that took me a long time to learn.

I was raised in a very "casual" family where 90 minutes late, to family gatherings, was considered on time. Sometimes, we'd arrive at Mass after the Gospel (very late into the liturgy). The Marine Corps was less tolerant of tardiness; 15 minutes early was considered on time. In the military, being late is referred to as UA/AWOL – a punishable offense.

I had two key experiences in the Marines that got me focused on time management. Reverse planning is a cinch once you learn it since it requires minimal attention. Simply start with a place you need to be, by a certain time, and work backward.

12:30 PM: Airline flight departs.
12:00 PM: Airplane begins boarding (unless it's Alaska Airlines, they begin boarding 45 mins early).
11:30 AM: Allow 30 minutes to get through security.
11:15 AM: Allow 15 minutes to get your boarding pass and check-in your baggage.
10:55 AM: Give yourself 20 minutes to park and walk into the terminal.
09:10 AM: Drive to the airport. Give yourself an extra 50% for traveling. So, if it typically take 30 minutes to drive to the airport, then give yourself 45 minutes.
09:00 AM: Allow ten minutes to gather your stuff and load it into the car.
8:00 AM: Reveille, reveille! Wake up at 8 AM if it typically takes you 45 – 60 minutes to shower and get dressed. Add an hour or so if you need to pack.

There's nothing difficult about reverse planning other than having the discipline to do it and being honest on your time allowances. I frequently do it, even for trivial events, to keep my skills sharp.

New Art Installation: 'The Daily Duty'

I have pictures of people pooping in my potty.

The Daily Duty art collection installation in my bathroom

Ok, I know that sounds weird, but it's true. I got the idea from Buona Forchetta, which has the most authentic Italian wood oven pizza in San Diego. Buona Forchetta (good fork) has large pictures of celebrities and heads of state on the throne in their public restrooms. You can't not notice it (apologizes to my English teachers). The first time I walked into the restaurant's bathroom, I immediately asked myself if this was tasteless. But, the artwork is so well done --- with fine creative taste --- that it inspires as it pushes the boundaries of art. Even my mother got a big kick out of artwork. After all, "art is what you can get away with."

Cristina Guggeri, AKA Krydy, Born In 1973

The Artist and Her Art

Cristina Guggeri, AKA Kyrdy, is the Sardinian-born artist who's created hundreds of photo-realistic pictures of celebrities on the throne. The collection, The Daily Duty, includes pictures ranging from the Pope to the Queen and Albert Einstein to Freddie Mercury. Rather than purchasing the prints, which you can do, she encourages fans to purchase the digital images to be printed, locally; and that's exactly what I did. The JPEGs each cost €22 – €27 (about $30) which I had printed on poster board. I installed this art collection in my bathroom with simple binder clips, thread, and thumbtacks. The poster board might warp a little from the humidity. If it does, then I'll velcro the bottom, which has worked very well for me in the past.

Cheeky or Tasteless?

Even though my socially conservative mother enjoyed this art collection, I still questioned its tastefulness. Would I want someone to display photo-realistic pictures of me, or my mother, on the toilet? The short answer is, "It depends." Like all art, its value is based on the artist who created it. While I wouldn't want random photos sold of my mother or me on the throne, I wouldn't mind at all if Guggeri created it.