The content on this site is my own and does not necessarily represent my employer’s positions, strategies or opinions.
- I’ve been playing around with Swift, the new programming language from Apple, for a few days and I’ve been quite …
- The Supermoon over Cranberry Lake, New York, in the New York Adirondack Mountains on 11 July, 2014.
- Yesterday IBM and Apple made an important announcement about partnering to significantly growth the use of mobile via Apple devices …
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.
Yesterdayand made an important announcement about partnering to significantly growth the use of mobile via Apple devices in the enterprise. That is, the collaboration will significantly increase the functionality and value that mobile brings to people in their jobs.
Here are some of the most important links about this announcement.
- Press release
- Apple, IBM in massive enterprise hardware, software partnership (CNBC)
- Apple, IBM in Deal to Create Apps, Sell Phones (Wall Street Journal)
- Apple Joins With IBM on Business Software (New York Times)
- Apple Teams Up With IBM For Huge, Expansive Enterprise Push (techcrunch)
- Why the Apple-IBM deal matters (PCWorld)
- Apple and IBM Team Up to Push iOS in the Enterprise (re/code)
- Apple and IBM Kickstart Contextual Enterprise Mobility (Forbes opinion)
Having a collection of fewer high quality tools is better than having many cheap, inaccurate ones that won’t last long and may be dangerous.
When I was young, I couldn’t afford very good tools. I’m not talking about software here, I’m referring to things like power saws and kitchen pots. I bought them as I needed them, but they were never top end. Over time, I replaced them all.
The problem with cheap tools is that they often do not work very well and they don’t last very long. Other than that, they’re great! (grin) Inexpensive screwdrivers twist and lose the shape of their tips, for example.
Take the power saw. Cheaper models do not have the power and often the precision to do the job right. Yes, they may be better than a hand saw but your work may be sloppy and inaccurate. That hand saw? Cheaper models may not be made of high quality wood and the metal may be be too thin, so it will wobble when you make a cut. It will likely dull faster as well.
In the kitchen, inexpensive knives will also dull quickly and may end up being downright dangerous. With any tool, cheap or otherwise, you need to know how to use it safely so that it will at least not be ignorance that caused the nicked finger, knuckle, or worse.
So while it is nice to say “buy better, more expensive tools,” that doesn’t solve the problem of affordability. Borrowing tools may work, but better from a relative than a friend. Better yet is having a skilled relative with good tools to help you!
Plan your strategy of getting good tools over time, and spend more sooner on the really important things you need. Start by thinking about what you will be using frequently.
For household work, construction, and carpentry, spend extra as soon as you can on screwdrivers, pliers, and tape measures. You can do a lot with an accurate electric saber saw and a square. Get the best quality cordless drill and drill bits you can afford.
For cooking, begin with the knives. You don’t need many of them, just a few very good ones. Don’t splurge on measuring spoons and cups since inexpensive ones are often good enough. Get a good Dutch oven sooner rather than later. Favor fewer stick-free pots and pans with new, high quality coating rather than a set of cheap pots. Sets can be cheaper, but you can also build up your collection piece by great piece as you have the money.
As a final suggestion, tools often come in three price ranges: inexpensive, moderate, and very expensive. If you know nothing else, go for the moderately priced tools. That said, do your research.
Wearables are the hot new thing, though the market is still shaping up. Nike has already exited the hardware part of the business. Here are some public descriptions of APIs and SDKs for wearables that could be used for mobile apps or other applications. Some of the APIs may be for the phones/tablets, some might be for the wearables.
APIs and SDKs