Apple Swift Optionals Syntax Rethought

NOTE: This is pretty stream of consciousness stuff. I’m just throwing out ideas.

In the Swift language an optional is a variable that can have an unknown value.  Let’s start with that. I’m not happy with the syntax of dealing with optionals, not that they exist since they have a real purpose.

First, what are the ways in which a variable can become unknown?

• Programming errors, such as forgetting to initialize an optional before trying to use it,

• Code setting it to an unknown value due to:

  • Bad code/memory access
  • External inputs
  • A real life representation of an unknown value (such as an unknown age).

This last really represents the interesting case since it moves us from binary logic to trinary:

  • Yes
  • No
  • I do’t know

Trinary logic lets code deal with the real world in more realistic ways and is similar to NULL values in SQL that can be queried. But, that’s beside the point.

Now lets look at some simple Swift code dealing with optionals:

Screen Shot 2015-08-28 at 9.23.56 AM

This is ok and people like this but I find it feels clunky having to test for unknowns everywhere with the if let idiom when the runtime should be able to do this. There is a lot of inline “boilerplate” that interrupts the logic flow just to handle the exceptional case. Handling unknown optionals inline breaks up the intent of the code.

What if we pulled handling unknown optionals into their own scope?  Let’s steal an idea from COBOL (yes!) and invent a new construct and call it wheneverUnknown.  wheneverUnknown would be invoked automatically by the runtime whenever [no pun intended] it detected an unknown value in an optional.  Think of this as try-catch routing except for unknowns and they are handled out of line from the main logic, which actually helps factor the code.

So what would the new code look like?  Here is a mockup.

Screen Shot 2015-08-28 at 9.21.39 AM

This, to me, seems more streamlined, simpler to “grok”, and is not inline.  A couple of things to note here.  The code after line 49 is only executed if the runtime encounters an unknown valued optional, so for all intents and purposes the logic ends at line 45.

The next thing to note is that we never handled the exception at line 45. This would be an example of forgetting to initialize an optional (bug) as opposed to the other two cases where we may not know the names.  How do we handle this bug? Let’s expand our wheneverUnknown  scope capabilities.  The wheneverUnknown examples in this function are scoped to the function.  Let’s do the same thing at the class level.

Screen Shot 2015-08-28 at 9.30.56 AM

Lines 33-36 is a similar wheneverUnknown that adds an any keyword which would trap any unhandled unknown and is class-scoped.  Actually, this could be moved into the function itself and would work similarly, but would be scoped to the function alone.

No, I have no plans to implement this.  The idea came up looking at a Twitter post and I got into a short interchange about this idea and really couldn’t get the idea across in tweets.  I just wanted to expand on the idea and clarify my thoughts a bit.


A Need for Code Understandability Metrics

I had an interesting Twitter chat with someone during the PhillyETE conference. One of the major takeaways from for me was that source code is written in order to be read (in addition to being executed.) Humans are going to spend a lot of time reading your code (even if its only you). The code should be written in a way that enhances its understandability. The chat got me thinking.

Testing is a hot topic. Many developers do TDD, BDD, unit testing, integration testing, deployment testing, etc. But when it comes to testing whether or not our code is understandable, we mostly fall back on code reviews. We don’t test the understandability of the code we review.

What does a code review test? I’d argue a code review’s purpose isn’tt to test anything, its purpose is to assess the quality of the code, its functionality for overlooked defects, to share knowledge amongst peers, and its readability.

For the most part code reviews are highly subjective and personal, guided only by experience and the process established to run them. “Readability” is often used interchangeably with “understandability”. A program with no white space is a lot harder to read than a program with white space. That doesn’t make the program any more understandable.

One point that came up in the chat was that whether the code is understandable is dependent on the business and understanding the business processes. It’s domain driven. (Assuming a non-DSL programming environment). I’d argue the domain information is independent of whether or not someone can read the code and easily understand what it does.

Knowing what code does is functional (no pun intended). The domain information is the purpose or reason for the code and function. You need to know how your bank implements a funds transfer, that’s domain information. Understanding that the code takes a value out of one database structure and adds the same value to another database structure is functional and independent of the banking domain.

Understanding why the code does something is different from understanding how it does it. These are two different levels of understanding.

So, why am I focusing on understandability? I’d argue that the greater the understandability of the code, the easier it is to manage, debug, pass on, etc. Read, “easier” as “more efficient” if that helps.

What makes one piece of code more understandable than another? Uncle Bob Martin’s book, Clean Code, is a good place to start. But there is a big problem. How do you quantitatively measure whether a piece of code is more understandable than another? One may argue that itâs highly subjective. I’d argue not. Here is a simple example:

What does this do? +/X>100 This is a real programming language.

What does this do?    for number in X
                                        if number > 100 print(number)
Which one is more understandable? You say that you need to know the language to understand the code. Of course. But I can give both of these examples to random non-programmers on the street and a majority could figure out what the second example does. It’s more understandable. “Well it’s more English-like.” True.

If you’re a c/C++ programmer, what does this do?

main(a,b)char**b;{int c=1,d=c,e=a-d;for(;e;e–)_(e)<_(c)?c=e:_(e)>_(d)?d=e:7;

(this from the Obfuscated C contest.) The understandability is [intentionally] bad even though you may know the language.

We need a way to measure and objectively compare one piece of code against another for understandability. We need metrics. We need tools.

This is an extremely hard problem to solve. It encompasses the language, white space, all of the “clean coder” concepts and others. It is, however, I’d argue independent of domain knowledge.  I believe it’s important.

Any volunteers? Flame on!

Philly ETE In Review

Welcome to my new blog.

First, a little about myself. I’ve spent most of my professional career designing, developing application solutions, and training people in massively scalable, massively distributed, “reactive” systems and relational databases. I’ve done project management, consulting and programming in more languages than I can list here. I develop iOS apps in my spare time and am teaching myself Android development. I’m also an author/writer, ham radio operator, cook, and beer brewer. I also stir the pot on Twitter.

Second, a little about this new blog. I hope this will be a place where I can toss some of my ideas about technology (specifically IT) to the internet winds and see what hits me in the face as it blows back. I’m going to try to post on a more or less regular basis as time and ideas permit. Why now? I’m looking for new opportunities and I have some time.

Third, so what’s a tesseract? It’s a four-dimensional cube, a hypercube. So the name references the idea of thinking a dimension or two “outside the box”. I like to challenge ideas and thinking.

So, enough about me. You probably dropped by to read about The Philadelphia Emerging Technologies for the Enterprise conference which had its 9th year.

PhillyETE, as it’s affectionately known, is organized by Chariot Solutions and is held at the Sheraton Society Hill and is the premiere technical conference for developers, managers, and thought people in the region. I’ve been attending for most of the years it has been put on and I have to say it is an amazing conference. This year was no exception.

The lineup this year was top notch including speakers from all over the country and attendees all over the world. If you’re interested in the details head over to Each year PhillyETE has a core topic. This year it was reactive programming and design, but as usual there were topics related to management, products and other technologies.

The firehose of information and knowledge, along with the conversations, food and location are both exhilarating and always leave me with more ideas and things I want to try than anyone can achieve. It’s a way to recharge and motivate myself as well as to meet new people on areas I normally haven’t had a chance to work in.

This year, PhillyETE’s topic seemed to be reactive programming. I’d heard about it for a few years now and really hadn’t had a chance to dive into it much. The ironic thing is I have been working on reactive systems and application designs since the 80s. The session called “Go Reactive: Blueprint for Future Reactive” by Roland Kuhn, Akka was stuff I already knew and used. The main difference was the language. The architectural design and paradigm was second nature to me and I was sensing déjà vu.

“Back in my day…” we called it “event-driven programming” on desktops. On servers we call it “message-driven”. On the server side the architectural differences are minor. I’ve worked with message-driven reactive operating systems as well. Who knew! Cool!

Now I just need to learn Akka well enough I can put it on my resume.

Dave Thomas did a great presentation on the programming language Elixir, and how it helps to learn new things and ways of thinking. He presented a video of a tribe that could not distinguish certain colors because they had no words for them. The analogy being you can’t see different ways of doing things if you can’t talk, describe, or code about it. There was a lot of startled murmurs in the room after the video. I have “collected” programming languages for years. I have done everything from APL to assembler to NewtonScript to ObjectiveC and a bunch in between. Elixir is different and interesting enough I should give it a try.

Those were just two highlights of the conference for me. At the end of every year I always feel a mixture of wishing it was a week long conference, and relief that it was done and would I ever use any of this “cool” stuff. In either case, I always look forward to the next year’s event.

Thanks much PhillyETE, Chariot Solutions, speakers, Sheraton, and new friends. Learn on!

Sent from Auteureist