I’ve been playing around with Swift, the new programming language from many languages and development environments since I started coding when I was 15, so I was anxious to see what Swift offered., for a few days and I’ve been quite happy with it. I’ve used
I’ve by no means used all the features yet, though I’ve read about most of them in Apple’s online language guide and reference. I’m using XCode 6 Beta 6, so I expect that some of the gotchas and incomplete implementations will be addressed in the next beta or the final version. Even after that I would expect the language to evolve further since most do.
Some of the things I like:
- Clean syntax
- Fast compilation, when it works (see below)
- Garbage collection
- A nice attempt at bringing the power of older languages like C++ into a more modern form that includes some features resembling those in
- A simple way to override syntactic operators like addition, negation, and multiplication.
My plan of attack here has been to take some C++ code I wrote 5 years ago and translate a subset of it to Swift. That way I can see how I would translate the ideas and structure into the new language. It’s been a good way to learn the language.
- Passing by reference and passing by copy are clearly distinguished with less syntax than C++.
- Because of the way it treats Unicode in a first class way, working with strings is more awkward than in many other languages. The need for Swift to coexist with Objective-C is also part of the reason, I believe.
- The automatic garbage collection reduces code size over my previous manual methods.
- I’m being more meticulous about when I can destructively change an object. (Almost never, and only close to where I create the object using specific init functions.)
- I’m looking forward to a larger collection of standardized collection types. Here I would expect a huge improvement over the Standard C++ Library.
- Once my core translated subset is complete and working well, I’ll look at using more of the idiomatic features of Swift and optimizing the code.
While working in the XCode editing environment, I hit a point where the computer CPU usage shot up to close to 100% for SourceKit, the underlying code base that handles all the editing, syntax checking, and code issue finding. Editing slowed to a crawl and sometimes I would get a message that SourceKit had crashed. Compilation took many minutes but the execution was correct.
I looked around the web, especially on StackOverflow, and found other mentions of the behavior but no great solutions and no problem situation that matched mine exactly. Eventually I went old school: I commented out most of my code and selectively added it back in until I could isolate the offending lines. Note that this was not a runtime error but an environmental problem while editing. That is: not my real problem.
If I had done something syntactically wrong, the editor or the compiler should have told me and not sucked up all the resources on my computer. If I was not doing something wrong, I should have seen no slow down.
Eventually I found that the offending code was
var s : Int = (u.bigits[j] * b + u.bigits[j-1] - q * v.bigits[n-1]) * b + u.bigits[j-2]
There is nothing wrong with the code except perhaps its complexity. I broke the statement into several simpler ones. By the way, I know I could have used “+=" but I wanted to be explicit and mirror the original statement.
var s : Int = -q * v.bigits[n-1]
s = s + u.bigits[j-1]
s = s + u.bigits[j] * b
s = s * b
s = s + u.bigits[j-2]
The problem went away. Editing and compilation speed returned to normal.
So the moral of this is that when working with betas of new languages, expect a few glitches and work around them. In the next release of XCode I’ll try my original statement and see if it has been fixed.
I’m looking forward to trying the new generics and constraints features. Though they look new to Swift, the ideas go back to at least the early 1990s.
Two other tidbits:
- If you know the type of an object, it does not hurt to be explicit in stating it. While it could be inferred, stating it makes the code more self-documenting.
- This release does not like spaces between unary prefix operators and their operands. That is, “- x” is flagged while “-x” is not. We’ll eventually see if this is a bug or a feature.