The Beauty of Apple Swift Emojicode…

Swift (and to be fair other languages) supports unicode characters within the language. It sounds a reasonable feature; to allow non Latin-1 characters to be used, such as Kanji. After all, why should a native Japanese developer be forced to name variables, classes, methods et al using a predominantly English character set?

But, unicode supports far more than just language oriented characters, and in the hands of – shall we say – more playful software engineers, there may be trouble ahead… you could possibly expect to see code like this floating around the detritus of the crap-ladden shores of the grand interwebnet…

And remember, this code compiles and runs

Let’s create a class object definition; (apologies for the line spacing, WordPress simply doesn’t care.)

class ?

{

    private var ? = “”

    private var ? = false

    

    init(?: String)

    {

        self.? = ?

    }

    

    func ??() -> Bool

    {

        //  ? likes Charlotte’s Web! Some ?!

        return true

    }

    

    func ?(?: Bool) -> Bool

    {

        // ? likes ?s so if given one, ? eats it

        if(?)

        {

            ? = ?

        }

        return ?

    }

    

    func ?(?: Bool) -> Bool

    {

        // ? does not like ?!

        return false

    }

    

    func ?() -> Bool

    {

        // is ? full?

        return ?

    }

}

“What the?” you may ask. No, dear reader, your eyes do not deceive you. All those cute little emoji’s are correct, and not code characters mistranslated by WordPress.

We can indeed create a ?(pig) class, and ask it if it likes bacon with func ?(?: Bool).

Now let us say we want to breed some ?s… a Pig Factory object would be useful…

class ??

{

    static func ??(?: String) -> ?

    {

        let ?? = ?(?:?)

        return ??

    }

}

And of course, now we can ‘breed’ pigs, we need a farm to manage them, and feed them (provided they like Charlotte’s Web, of course)… one hundred pigs should just about do the trick…

class ?

{

    func ???()

    {

        let ?? = 100

        

        var ?? = 0

        

        while(?? < ??)

        {

            let ?? = ??.??(?: “Bob”) // every ? is called “Bob” as they probably don’t answer by name anyway

            

            if ??.??()

            {

                if !??.?()

                {

                    if(!??.?(?:true))

                    {

                        _ = ??.?(?:true)

                    }

                }

            }

                

            ?? = ?? + 1

        }

    }

}

And finally, for irony’s sake, we’ll use some clear English to get our farm to create some pigs…

        let farm = ?()

        farm.???()

I can tell you, stepping through this in debug to make sure it ran, was a pure joy… while the code runs and does indeed create ??s, Xcode’s debugger simply would not have any of it, and jumped around like a crazed kangaroo on acid. Nice. I wonder what kind of experience our Japanese colleagues have trying to debug their natively named methods…

Glibness aside (and above is very glib!) there is value in supporting unicode ‘in language’, however, Apple, please restrict it to actual ‘text’ language instead of stupid symbols? Naturally, allow anything inside string objects or quotation marks as you may validly want to display them in UI, but for the actual code itself, text only! Also, try actually testing that all the toolchain supports them? Like, say, the debugger? Slightly important, not too easy to miss… really. I can only hope that actual software engineers can resist, and if they can’t that whoever’s reviewing their code uses a damned big stick to smack the emoji’s back into real text.

As an aside, apparently Apple did ban all the unicode line/border characters to stop developers drawing unicode art boxes around everything in their code. So they clearly realised this would be abused by someone.

Several steps too short, yet again Apple… though who cares, really, right?

Swift

Of late I’ve been turning to (finally) learning the Swift language developed by Apple, notably for their iOS platform.

The Swift language is now on version 3.0, and by now should have settled down, ironed out all it’s kinks, and generally matured.

Wrong-o.

I’m not a ‘hater’ – I have written software in some many different platforms, languages and IDE’s that I’ve honestly lost count. I don’t mind learning something new, or adapting to changes. It’s a requirement for a professional software engineer.

But so far, Swift 3.0 ain’t mature. Far from it in fact. Now, to be fair, I do like it – mostly. The syntax is a lot cleaner than Objective-C, and yes it does seem to be easy to pick up, especially knowing how iOS frameworks and components already work, and being able to mix .swift with .m/.mm is awesome, as is being able to mix .c and .cpp.

But, there’s a but.

This ‘cleaner’ syntax rapidly turns into a mess of optionals (?) and down-casting (!), and means a double-meaning to established ‘c’ like operators.

if(!weekDays[eventDay! -1])
{
   // do stuff
}
var dictionaryYearWeekDayEvents = Dictionary<Int, Dictionary<Int, Dictionary<Int, [Event]>>>

I mean, wtf? I smell C++ Templates… and this is the structure I want, but now with Swift Dictionaries I am forced to specify the entire object structure before I can use it. NSDictionaries in Objective-C allow me to do it ‘whenever’. Ok, a double-edged sword I agree. Swift is better in the regard that it has tighter constraints on typing objects which is definitely a win. This is a programming paradigm I have to adjust to in my own head.

I also don’t quite get the concept of ‘optionals’;

var someObject: ObjectType?

Ok, so this means ‘someObject’ may not actually exist, i.e. will be nil. So then why does Swift throw an exception if the optional is nil when I try to use it in my own code which allows it to be optional?

Now granted, I am no Swift expert, of course! I’m just starting, but the above are examples of what the language let’s you do. It’s no better than C giving you the rope to hang yourself and C++ tying the noose for you and providing the stool.

Swift’s language spec and syntax makes it incredibly easy to get yourself into a nasty place, very quickly indeed. Not quite what they had in mind with the name ‘Swift’ I’ll warrant. I foresee a lot of domain expert knowledge being consumed by engineers being needed to clean up a lot of messy code in the future, now that enterprise applications seem to finally be taking off on the iOS platform, and all the new gig’s are ‘Swift’ based.

They also changed the majority of the API stack for Swift 3.0, compared to previous versions. This is badand strongly hints at a major and fundamental underlying flaw in the original language spec. This may have been something I’d expect to happen say in Swift 2.0, but not afterwards. The language should have been firmly locked down beyond 2.0

This has led to a lot of confusion on the internet with many ‘How do I do X in Swift’ examples being made instantly worthless (ok, the price of change I guess) but also with now examples given in Swift 1.0, Swift 2.0 and Swift 3.0. Worse, often the examples in Swift 3.0 no longer work –not because the authors are idiots, but because the example has been made redundant by even more changes since it was written.

Try figuring out how to sort a Dictionary by it’s key values. I dare you. I’ve given up. I just pull the keys out into an array, sort that, and then pull the dictionary items out in the sorted array order. It’s just less painful.

And then there’s Apple’s own documentation. Woefully poor for Objective-C but liveable. However, for Swift 3.0 it’s dire and nearly inadequate, often with contradictory examples, or no examples at all (ne. Sorting a Dictionary by key).

If all the above applied to Swift 1.0, I’d forgive, and put-up-and-shut-up. But for all this to be said at Swift 3.0, that’s just plain rude Apple, and shame on you for making the developers lives harder. Let’s not forget just who it was that actually made your mobile platform the place to be all those years ago…

Visit the awesomeness ofDominium!