Swift – two WTFs, a Fail and a Train Wreck

So Apple has a new programming language called Swift. You probably heard the news and read the Swift book so I wont bother repeating the good parts. I fell in love with nearly all of the new features (compared to C/Objective C) only from reading the Swift book BUT…

There are some foul spots in that sweet fruit. I gave this post the title „two WTFs, a Fail and a Train Wreck“ to sum up my gripes. Let’s start with the first WTF:

First WTF – Constant Arrays

In the Swift book it says:

if you assign an array or a dictionary to a constant, that array or dictionary is immutable

Ok, so far so good. Exactly what you would expect.

„…and its size cannot be changed.“

Wh..what’s that? I’m confused! Let’s read on.

For dictionaries, immutability also means that you cannot replace the value for an existing key in the dictionary. An immutable dictionary’s contents cannot be changed once they are set.

Ok, still as expected.

Immutability has a slightly different meaning for arrays, however. You are still not allowed to perform any action that has the potential to change the size of an immutable array, but you are allowed to set a new value for an existing index in the array.

WHAAAT??? Ok, nice optimization but aren’t that weird rules? I use a constant because I want it to be constant and not to have a faster variable. The implementation details should not shine through like that!

If you really want to have fun, try to wrap your head around the chapter „Assignment and Copy Behavior for Arrays“ in the Swift book. That mad endeavour is left as an exercise to the reader. Good luck!

The Fail – Method names

One of the greatly undervalued gems in Objective C is that there is no difference between the name of a method and the named parameters. It’s the same thing, and it can be rather poetic:

[url bookmarkDataWithOptions:NSURLBookmarkCreationMinimalBookmark
includingResourceValuesForKeys:nil relativeToURL:nil error:nil];

becomes this abomination:

url.bookmarkDataWithOptions(options: NSURLBookmarkCreationMinimalBookmark, includingResourceValuesForKeys: nil, relativeToURL: nil, error: nil)

urgh! „Options“ twice. Not good! There is no reason Swift could not have retained the elegant square bracket syntax of Objective C. None. Still they force us to cut the first part of our method name in half with a round bracket. Thank you so much.

Second WTF – Closure Syntax in a Method/Function Invocation

According to the Swift book you can call a function with a closure as a parameter like this:

reversed = sort(names, { (s1: String, s2: String) -> Bool in return s1 > s2 } )

or like this:

reversed = sort(names, { s1, s2 in return s1 > s2 } )

or like this:

reversed = sort(names, { s1, s2 in s1 > s2 } )

or like this:

reversed = sort(names, { $0 > $1 } )

or (in this case) like this:

reversed = sort(names, >)

or like this:

reversed = sort(names) { $0 > $1 }

Any questions?

The Trainwreck – Operator overloading

Whew that’s a big one! Obviously Chris Lattner and his team have not read Scott Meyers „Effective C++“ and „More Effective C++“ back then in the mid-nineties. Meyers makes some good cases against using operator overloading in C++, which is an especially hellish place anyway. But some cases are relevant beyond C++. Let me pick one, the boolean operator problem. Let’s assume we have two functions a() and b() that return a BOOL (or Bool). When we use a if-clause like this (in C)

if (a() && b())
{ /* do stuff */}

and a() returns false, b() will not be called. You can question this design decision by Kernighan and Ritchie from over 40 years ago but this behaviour has made it into many, many languages since then and Swift is no exception. Open a playground and copy and paste as we move along for maximum fun:

func a () -> Bool {
return false
}

func b () -> Bool {
println("b() was called")
return true
}

if a() && b() {
println("YES");
}
else
{
println("NO");
}

The console contains no surprise:

NO

Now let’s do some mean operator overloading with 3 components:

// a class
class Blah {
}

// an overloaded &&-operator
@infix func && (left: Blah, right: Bool) -> Bool {
return a() && right
}

// finally a func that returns a Blah object
func c () -> Blah {
return Blah()
}

Now let’s do the same if-clause but with c() instead of a():

if c() && b() {
println("YES");
}
else
{
println("NO");
}

Guess what happens?

b() was called
NO

Ouch! This behaviour is totally expected but just as surprising at the same time. It is not easy to tell what really happens from looking at the code
if c() && b()
That’s bad. It basically means you can’t trust the evaluation rules for operators anymore. That’s a train wreck! Especially for a language that tries so hard to avoid those kinds of problems.

Probably as you read this some kid out there thinks it’s a good idea to create and use a %%%-operator in his library. He might just have pushed it to Github. Who knows? Or imagine someone thinks how cool it was to port std::stream of the C++-STL to Swift, does so and your boss likes it? Nothing wrong with the STL back then when your boss still wrote code, right? RIGHT?

But joking aside: There are so few problems you can only solve with operator overloading but so many problem to have with it. It really makes you wonder: How could this get past the reasonable people in the team of Chris?

I’m at a loss here. I have no idea.

Warum Honig jetzt ganz anders schmeckt

Wir haben da so ein Ferienhaus in der Toskana. Da ist die meiste Zeit im Jahr niemand, weil die Toskana ist ja nicht um die Ecke. Im Spätsommer macht der letzte das Haus gründlich zu und dazu gehören auch die Klappläden an den Fenstern. Da hat sich letztes Jahr ein Bienenvolk zwischen einem Fenster und dem Klappladen eingenistet.

20140606-122227-44547289.jpg

20140606-122251-44571746.jpg

20140606-122314-44594860.jpg

Ein super Schauspiel, man konnte Drohnen ausmachen und Arbeiterinnen beim Schwänzeltanz beobachten. Trotzdem wurde sich drauf geeinigt, dass die Bienen einem Imker übergeben werden sollen. Besagter Imker kam und sah sich mit einer schwierigen Aufgabe betraut. Allein das Fenster zu öffnen war nicht so recht einfach.

20140606-122652-44812570.jpg

20140606-122652-44812754.jpg

Aber er bekam es auf und damit nahm das Unglück seinen Lauf. Die Wabenlamellen, die die Bienen gebaut hatten blieben teils am Fenster und teils am Laden kleben. Als der Imker dann den Fensterladen öffnete war das das Ende für die strukturelle Integrität des Stocks. Große Teile der Waben brachen ab und fielen zu Boden. In dem Chaos das dann losbrach war die Königin nicht auszumachen.

20140606-180315-64995884.jpg

Das Ende des ersten Tages sah entsprechend trostlos aus.

20140606-224017-81617866.jpg

Allerdings hatte der Imker ein paar honigführende Waben aussortiert.
.

20140606-225731-82651069.jpg

Ich hatte dann recht viel Mühe das Haus bienenfrei zu bekommen, damit die Familie wieder einziehen konnte. Am Fenster hing eine kleine Traube Bienen und unter den Bienenstocktrümmern verkroch sich der Rest.

20140606-231330-83610196.jpg
Der Staat war nicht weggeschwärmt. Am zweiten Tag waren wir ausgeflogen und als wir abends kamen, hatte der Imker einen grünen Kasten hinterlassen und die Lage schien sehr ruhig. Wir hatten die Hoffnung, die Bienen hätten sich in den Kasten begeben. Ich habe mich dann daran gemacht den Honig zu ernten/abzufüllen (Wie sagt man?)

20140606-230608-83168826.jpg

Am Morgen des dritten Tages waren die Bienen wieder am Fenster und zwischen den Trümmern hervorgekrochen. Der Imker kam nochmal und hat Gift gesprüht und das nicht zu knapp. Uns allen tat das in der Seele weh, aber es schien nicht anders zu gehen. Ich habe noch nie so viele tote Bienen gesehen, oder überhaupt so viele tote Tiere auf einen Haufen.

P.S.: Um den Artikel nicht so deprimierend abzuschließen habe ich hier noch eine faszinierende Nahaufnahme von einer Hornisse. Da gibt’s hier auch einige. Bis jetzt waren die Hornissen von allen Stechinsekten am friedlichsten.

20140606-231639-83799595.jpg