My name is Brook Jones and Iâm one of your constituents. We havenât corresponded before, but Iâm writing now because Iâd like to hear your thoughts on a matter of some importance to me.
I was delighted to hear Prime Minister Trudeau promise in his Dec. 2015 throne speech that his government would âtake action to ensure that 2015 will be the last federal election conducted under the first-past-the-post voting system.â
As you, and Mr. Trudeau, of course know, in 6 of the past 9 federal elections a party capturing a minority of the popular vote has nonetheless been awarded a majority of the seats in parliament (and thus effectively 100% of the legislative power). Mr. Trudeauâs throne speech clearly acknowledged that this recurring undemocratic outcome does not serve the interests of Canadians, which is why I was so heartened to hear that he was committed to changing it.
As you might imagine, it was therefore incredibly disappointing to hear that Mr. Trudeau is abandoning that promise and choosing to leave Canadians stuck with an electoral model that he himself has acknowledged as unrepresentative and unfair.
As your constituent, Iâd like to know your thoughts on this matter, and if (and how) you intend to pressure the prime minister to honour his commitment to electoral reform.
I never used to cry at Remembrance Day ceremonies, but now I seem to every year. I suppose I am, with each passing year, more profoundly grateful to have lived a life largely untouched by war, and more profoundly appreciative of the sacrifices made by others in defense of the freedoms I enjoy. And with each passing year, I feel more profoundly heartbroken at the suffering of those around the world who have not been so privileged. Lest we forget. Ne les oubliez pas.
In my estimation, three pairs of things happened at Appleâs event last Monday. One pair was precedented and expected; another pair was less precedented though still expected; and the final pair was quite out of character and consequently very surprising.Â
The first pair was, of course, the announcement of a new 4-inch iPhone and a new 9.7-inch iPad: highly precedented (they are Appleâs fourth 4-inch iPhone and seventh 9.7-inch iPad, respectively) and widely expected (for my part, Iâve been beating the ânew-4-inch-phoneâ drum for more than a year). While the bulk of Appleâs focus for the last 18 months has been on promoting the new âlargeâ ends of their iPhone and iPad lines, it would be surprising (and likely foolish) for Apple to completely abandon the sizes which made those devices popular in the first place. Thus: the iPhone SE and the new iPad Pro (9.7âł).
Punching Above Their Weight
Somewhat less precedented, however, was the leap forward that both devices took from the specs of their predecessors. Appleâs previous 4-inch iPhone, the 5s, featured an A7 processor with 1GB of RAM, but of course, it launched in 2013. Two and a half years later, the iPhone SE is leap-frogging the A8 and jumping straight to the core specs of the current flagship iPhone 6s/6s Plus: a 1.85GHz A9 CPU with 2GB of LPDDR4 RAM. Moreover, Apple brought all their other âflagshipâ hardware features along to the SE, too: 3D Touch, the newest 12MP/4K camera, an internal barometer, MIMO wi-fi⌠this is a â6sâ iPhone in all but name. [Edit: the SE supports Live Photos, but not 3D Touch or barometer, alasâŚ]
Similarly, the iPad Pro (9.7âł) is, as the name suggests, much more a âsmaller iPad Proâ than it is a ânewer iPad Airâ: like the iPhone SE, it inherits its larger siblingâs full feature set (display improvements, Apple Pencil support, its own Smart Keyboard, four adaptive speakers), and even gets some new tricks of its own (12MP/4K camera, adaptive display white balance, 256GB storage option, LTE Advanced).
Overall, given Appleâs intense marketing focus on their newer, larger iPhones and iPads for the last two holiday seasons, the point of this event seemed to be to offer reassurance that the âclassicâ sizes are not only not forgotten, theyâre still first-class citizens in Appleâs eyes.
(It is worth noting, however, that the 9.7âł iPad Pro only has 2GB of RAM, not the 4GB of the 12.9âł model â perhaps 4GB didnât provide a sufficient cost/benefit ratio for a $599 device?)
By far the most surprising pair of announcements, however, were about price points.
The Apple Razor
First, the $50 price cut on the Apple Watch was unusual, in that Apple rarely drops their prices on a product without introducing a new product to occupy the higher price point (see the annual iPhone / iPad âstaircaseâ progression, for example). The thinking behind this is reasonable: you want to habituate your customers to a price point thatâs profitable for you, and establish that as âthe priceâ of a new device in that family. So why cut the price of the Apple Watch without introducing a successor? I believe there are two reasons.
First, I think the Apple Watch is going to have longer âupdate cyclesâ than the (annual) iPhone and iPad. Its status as a âsidekickâ device which mostly communicates with other devices makes its internal specs less critical, and frequent updates / upgrades less necessary. But it is still of course fundamentally a piece of technology, and itâs difficult to keep selling any technology hardware for the same price for much longer than a year. So the price cut may be reflective of the market reality for a product with a longer update cycle.
Secondly, and more importantly, the Apple Watch is a meaningfully more âGilletteâ product (sell the razor cheap and mark up the blades) than anything else in Appleâs lineup. Even with the iPhone and iPad, while high-margin accessories are increasingly part of Appleâs strategy, one might spend at most an additional 10-20% of the (unsubsidized) cost of an iPhone on accessories. With the Apple Watch, however, itâs entirely plausible that some customers will spend an additional 100% (or more) of the cost of the device on accessories, buying different bands for different occasions / moods / outfits. When the offerings include $49 sport and woven nylon bands, $149 mesh and leather bands, $249(!) buckle bands, and $449(!!) link-bracelet bands, itâs entirely rational for Apple to make the watch itself as cheap as possible, and leverage their burgeoning luxury cachet to sell authentic Apple bands at truly ridiculous margins.
The Legendary âCheap iPhoneâ
Turning to the iPhone SEâs price announcement: $399/$0 (subsidized via contract) is thoroughly unprecedented for a âflagship-specâ iPhone, even allowing that the A9 chipset is six months old at this point. The SEâs price-to-feature ratio is immediately the most compelling of the entire iPhone line, which is surprising from a company notoriously protective of its profit margins (and thus typically rigorous in keeping its high-end products clearly differentiated from its entry-level ones). 2013â˛s âcheapâ iPhone 5C turned out to be mostly a marketing tweak: repackaging the iPhone 5 in a more âcasualâ shell, but leaving the economics of the iPhone line untouched. The iPhone SE, however, does what the 5C didnât: offer not just a cheap iPhone, but a cheap, great iPhone.
Ben Thompson nicely summarizes why this is a big deal for Apple: â[T]he real long-term danger of occupying the high-end is falling in love with margin or average selling price at the expense of what makes sense strategically.â The iPhone SEâs aggressive pricing will at least slightly reduce Appleâs overall iPhone margins, but it will help them stay relevant and expand in developing markets, particularly (as Thompson notes) ones like India, where consumers are highly tech-savvy (likely to care about specs) and less status-conscious (less likely to care about a big screen).
(For all that, Apple is still clinging on to one last bulwark in defence of their margins: the iPhone SE continues the â16-64â storage capacity scheme, which highly incentivizes an up-sell from the base 16GB model to the 64GB model for $100 more. Itâs a savvy play, and itâs especially hard to call Apple parsimonious when theyâve packed so much else into a $399/$0 phone, but 16GB is increasingly an untenable size for a modern smartphone, and I dearly hope that 32GB finally takes over as the new normal for Apple this year.)
Iâve been woefully lax in producing homespun Apple punditry these last few months â nothing on the subject since August, in fact, which means that apart from a few tweets, I havenât weighed on in the iPhone 6s/6s+ or the iPad Pro. So before I predict what I think tomorrowâs event will bring, letâs tally up the scorecard on my 2015 predictions:
Ugh. Not pretty. The biggest news of the September event was the (widely-rumoured) iPad Pro, and in spite of hearing all the rumours, it just didnât seem likely to me that Apple would think âbiggerâ was the right direction to take the iPad (prediction IV). Well: it goes to show what I know.
Getting prediction IV wrong also made it easy to get prediction VI wrong â I just didnât have any kind of read on what Appleâs plans for the iPad line were.
There wasnât much to be surprised about with the 6s/6s+, and I mostly got that right (prediction II), though I was sure that Apple would finally abandon the 16GB size point (a capacity theyâve been shipping for more than eight years, itâs worth noting). They didnât, which means they now sell a phone that can shoot 4K video⌠but which completely runs out of space after recording 45 minutes of said footage. And thatâs assuming there are no apps, photos, or anything else on it. Sigh. Ditto with the iPad mini 4 â it canât shoot 4K video, but it still deserves (and I thought it would get â prediction V) more than 16GB of storage.
My predictions about the rest of the iPhone lineup also fared pretty poorly, though once prediction I didnât come true, itâs not surprising that prediction III didnât either. My only consolation here is that it sounds like the former will probably come true tomorrow. I donât have much hope for the latter immediately, although it will probably happen in the fall when the new phones launch â there wouldnât be much point in having a 7/7+, a 6s/6s+ and a 6/6+, as well as the new â6câ (or âiPhone SEâ, or â6 miniâ, or whatever it winds up being called). If, as rumoured, the â6c"Â does use an A9 chip, then it might mean Apple was willing to ditch the 6s/6s+ this fall too. I think just three phones (6c/7/7+) would make for a nice, clean, Apple-esque (or perhaps Jobsian?) lineup â but I felt that way last year too, and nothing came of it.
My technology-related predictions (VII, VIII, and IX) werenât great either â Force Touch did make an appearance in the 6s/6s+, of course, but I certainly didnât foresee "3D Touchâ or a stylus(!) arriving for iPad, and Appleâs nascent enthusiasm for USB-C didnât find any new expression. The new iDevices stuck with Lightning, the new iMacs stuck with USB3, and the new MacBook Pros⌠they didnât arrive at all. But 2016â˛s gotta be the year for USB-C, right? Right?
On the positive side, at least my safest, easiest, non-prediction (numeral X) was 100% true: there were no new Apple Watch models. Whew!
Back To The Future
So, with that unpleasant account concluded, letâs turn now to the present / immediate future: what will tomorrow morning bring? Iâll keep it short â here are the two easy predictions:
my 2015 âmodern 4-inch iPhoneâ prediction will finally be fulfilled. It might be called the iPhone SE, though I hope not â thatâs a terrible name.
my 2015 âA9X-based 10-inch iPadâ prediction will sort-of be fulfilled⌠but it will be more âa smaller iPad Proâ than âa faster iPad Air 2â, so I donât get much retroactive credit for that.
I donât want to be too conservative in my forecasts, though, so here are a couple that are a little further out there:
new MacBook Pros will launch, featuring Skylake chips, available in the four iPhone finishes, and featuring exclusively USB-C ports. This line is overdue for new models (MBPs were updated on average every 7.5 months from 2006 to 2014, but itâs now been over a year since the last change to the 13" model, and 10 months for the 15"), and I like to think Apple has been using the extra time to prepare for a full reboot, in the spirit of the 2015 MacBook, but with a focus on performance this time around.
Tim Cook will announce a change of heart on the whole FBI / phone-unlocking thing, and say that he now believes that the government has convincingly demonstrated that it can be fully trusted to behave responsibly concerning the privacy of its citizens, so Apple will now cooperate fully with the FBIâs investigations, and happily provide them with whatever custom software they need or want.
The Only Spreadsheet Custom Number Format Youâll Ever Need
As something of a spreadsheet afficionado, I occasionally find myself wishing there was an easy way...
Excel and Google Sheets both offer scientific notation, of course, but I prefer something a bit more âskimmableâ. So, I went googling, and found a StackExchange post on unit abbreviation which put me on the right path -- although the formula it gave only worked into the millions, not billions (and would occasionally produce quirky formatting).
So I did a little reading and a little tweaking, and am proud to present... The One True Spreadsheet Custom Number Format:
[<999950]0.0,"K";[<999950000]0.0,,"M";0.0,,,"B"
âTis a thing of beauty, is it not? It will do exactly what's shown in the screenshot above. Magic! And/or Science!
(For the curious -- using <999950 as the threshold instead of <1000000 prevents the confusing â1000.0Kâ from showing up instead of â1.0Mâ when a number is being rounded up to 1.0M)
You can use it in Google Sheets by selecting the cells youâre interested in, then clicking Format -> Number -> More Formats -> Custom Number Format, and then pasting in the above formula. Voila! If youâre using Excel, the steps for setting a custom number format are given in that StackExchange post.
(PS. The candy consumption numbers used in the example above are purely for illustrative purposes. I promise.)
One of my new yearâs resolutions for 2016 is to improve my Gmail ninja skills. Iâve read a couple of excellent blog posts on the subject (both highly recommended), and installed a great formatting helper (Markdown Here, also highly recommended â particularly if you ever need to send snippets of code in email), but in spite of all that Iâve found myself struggling to embrace Gmailâs keyboard shortcuts. I know theyâre handy, and I know Iâll probably love them once Iâve adopted them, but I never think to use them, and consequently can never remember them.
However, thereâs a lot of empty space just hanging out at the top of the page in Gmail â why not show some keyboard shortcuts there permanently, as a reminder? Well, thanks to the magic of custom themes, thatâs what Iâve (hackily) done:
Itâs not perfect, but it was easy to make, and it works, with a few caveats:
the auto-vignetting canât be turned off, nor the Gmail colour scheme overridden
the shortcuts may get covered up, depending on the width of your browser window
only a subset of the full shortcut list is shown; I picked the ones most useful to me
it shows Mac-specific keys (ie. cmd instead of ctrl)
Still, if youâd like to give it a try, itâs ridiculously easy to add to your Gmail account:
Then copy and paste this URL: https://dl.dropboxusercontent.com/u/35671944/2015/gmail-keyboard-shortcuts.png
âŚand voila!
If it doesnât quite work (for any of the reasons outlined above), itâs pretty easy to make your own custom version that will work better for your purposes â just save my PNG file and use it as a template for creating your own. And if you get tired of it (or donât need it anymore!), going back to your previous theme is as easy as clicking Settings -> Themes and switching to whichever one you had before (scroll down for the basic / default set).
Happy shortcutting!
Update: once youâve mastered Gmailâs shortcuts, this helpful list (care of the Buffer blog) summarizes a bunch of additional website keyboard shortcuts for Twitter, Facebook, YouTube, and more! And if you want to sharpen your native (Mac) app skills, CheatSheet is a good way to do it.
The scenario: after circling the block a few times in search of a parking space on a busy residential street, you finally spot one. Victory! But alas â as you approach, you discover that someone has already âreservedâ this otherwise perfectly legal, unrestricted parking space, using an old garbage bin and some tiny orange dollar-store road cones. You roll your eyes and continue on your way, quietly cursing... (or: you drag the garbage bin and cones out of the way and park there anyways, but worry slightly as you walk away that youâll come back to find your car keyed or tires deflated...)
Iâm not sure how common this scenario is outside of Vancouver, but itâs frustratingly common here. It happened to me again yesterday, and it irritated me enough that I took some time to research the legal foundation of âreservedâ on-street parking in Vancouver. Unsurprisingly, there isnât one:
âOn-street parking spaces cannot be reserved with cones or other objects.â (source:Â City of Vancouver)
Armed with this knowledge, Iâm of course tempted to just kick over any buckets I might find obstructing parking spaces in future and park on the street with impunity. But education is the first step to changing behaviour, so I drafted this letter, and have printed out a few copies to keep in my glove compartment:
If you live in Vancouver, are an uptight rule-follower like me, and would like to be similarly prepared, the above letter is available in PDF form here. Happy printing and happy parking! :D
(Note: having the law on your side still may not protect your car from getting keyed / deflated, if the neighbour in question is enough of a jerk â if you think that might be the case, you may want to drop multiple copies of this letter off over a period of a few days before actually moving their buckets, or perhaps leave a dashcam running in your car when you park there. Use your best judgement.)
I worry about: -followers of a middle-eastern religion... -...who reject the aspects of their religion which call for love and acceptance... -...and who develop/express, especially via the internet, increasingly fundamentalist views... -...declaring a belief that their society is incompatible with, and should be intolerant of, the adherents of another religion, which is seen as irredeemably evil. Those folks are scary.
Some of you have had to put up with a lot of political posts from me this year. Indulge me in one last one before the election on Monday. Many important issues have been debated in this campaign, but the one that rises above the rest, in my mind, is the central issue of democracy: the degree to which the will of the people is expressed in the government they elect. All other important policy questions rest on this one -- a government which is representative of, and accountable to, its citizens is more likely to act in their interest; a government that's not is more likely to act in its own interest. So if you're not sure what weight to place on what issues as you decide who to vote for this election, consider whether the candidate or party in question is one who will strengthen and improve Canada's democracy, or one who will weaken, bypass, or undermine it. I also strongly recommend researching, from multiple sources if possible, how things stand in your particular riding. Vote-splitting in Canada has allowed both Liberal (2000-2004) and Conservative (2011-2015) governments to, with a minority of the popular vote, win a majority of seats, and thus one hundred percent of the legislative power. Strategic voting is hardly ideal democracy, but the alternative is substantially worse. Your vote matters. Use it, and use it wisely.
As a vain man who enjoys being right in matters of no consequence, I was pleased to see last monthâs surprise Apple announcement bearing out my prediction from January: the iPod Touch is not dead.
...did fall short in a few regards, though: first, I assumed the new Touch would launch alongside the new iPhones in September, but Apple dropped this one a couple of months early. This was presumably to better align with (and cross-promote) the launch of Apple Music, a service whose existence certainly gives Apple extra motivation to keep a cheap, pocketable iOS device in their lineup, particularly one with the musical heritage of the iPod brand.
I also didnât anticipate a 128GB model (nor a $399 price point for same) -- itâs unexpected (by me, at least) for Apple to launch a âluxuryâ (price and capacity) model within their cheapest and most bare-bones iOS device family. Perhaps itâs an olive branch to the die-hard iPod originalists still lugging around their 2007-era 160GB iPod Classics?
Lastly, I also underestimated Appleâs processor generosity: rather than an iPhone 5S-class A7 chip, the new Touch boasts an iPhone 6-class A8 chip -- almost a year old at this point, but still technically state-of-the-art in Apple terms, at least for another month or two. Of course, I say âgenerosityâ, but itâs really about strategy: to me, the A8 chip signals that Apple intends to keep the Touch in the lineup, but not refresh it, for another two or three years -- in other words, to maintain the same role that the 5th-gen Touch held from 2012 until now (a capable, lightweight device that Apple can keep selling but not spend much time or money on). An A7 chip would perhaps have been harder to maintain iOS support for over that long a period, so they opted for an A8. I expect this means the Touchâs margins are uncharacteristically tight right now, but theyâll increase with time.
Crystal-Ball Retro-Gazing
This is as good an excuse as any to revisit my other January predictions ahead of the imminent official iPhone and iPad announcements and launches. It wonât take long -- none of my opinions have changed. I still hold the (very boring and predictable) belief that an A9-powered, 2GB of RAM-packing, 6S and 6S Plus will be the new flagship phones. My other prediction, however -- that we will also see a new 4âł phone for the first time since 2013 -- is getting some traction thanks to the arrival of the iPod Touch (although, to be fair, it's been rumoured for a while).
That said, I havenât read any analyses that join me in making the next logical jump: that the current 6 and 6 Plus will go away altogether, and be replaced by a $99 (subsidized) iPhone 6C (6 mini) as the sole third option in the iPhone line (followed by the 5S, as expected, in the $0-subsidized slot).
In other words, the iPhone lineup will look this (unchanged from January):
...and the iPad lineup will look like this (also unchanged from January):
iPad mini 2: A7 / 1GB RAM / 16GB @ $249 (+$130 for LTE)
iPad mini 3: A7 / 1GB RAM / 32-64GB @ $299-349 (+$130 for LTE)
iPad mini 4: A8 / 1GB RAM / 32-128GB @ $399-599 (+$130 for LTE)
iPad Air 2: A8X / 2GB RAM / 32-64GB @ $399-449 (+$130 for LTE)
iPad Air 3: A9X / 2GB RAM / 32-128GB @ $499-699 (+$130 for LTE)
(No: I still donât expect to see a 12-13âł âiPad Proâ this year, or the foreseeable future -- my January post makes the full argument, but the TL;DR highlights are âNobody else is making a killing with a 12" tablet right nowâ and âAppleâs success in the enterprise world (such as it is) has come from making products that people love to use, not from focusing on designs that businesses would like.â)
My original post listed some specific hardware improvements, which I still think will be included, but also offered this disclaimer:
Iâm sure there will be more bells and whistles that I havenât thought of (I am, of course, no Steve Jobs / Jony Ive / Tim Cook)...
...and while Iâm still no Steve / Jony / Tim, thatâs mostly where my prediction-revising is going to happen today. Specifically, two such bells and/or whistles have become more likely since January; in fact, I would argue that both are inevitable. The question is merely whether theyâll be incorporated into this yearâs iPhones and iPads or next yearâs.
Use The Force
The concept of a âforce touchâ (a hard press, as opposed to a tap) is pretty new in Apple-land; it was first introduced at the unveiling of the Apple Watch less than a year ago. Itâs a gesture that makes sense for the Watch, where limited screen real estate restricts the usefulness of multi-finger gestures. Interestingly, however, force touch actually made a surprise hardware debut in not one but two other products before the Watch: the latest 13âł MacBook Pro (which launched Mar. 9th) and the new MacBook (April 10th). The Apple Watch launched on April 24th, and the 15âł MacBook Pro was updated with a force touch trackpad in late May.
I think the trend is clear: force touch is in, and support for it in the iPhone and iPad is just a matter of time. Thereâs a chance that Apple could wait until 2016 and the iPhone 7 / iPad Air 4 (?) to roll it out, but an appearance this year, in the iPhone 6S / 6S Plus and iPad Air 3, seems more likely to me.
A Trip to The C-Side
The other hardware tweak coming soon to the iPhone and iPad is also arriving by way of the MacBook: a USB-C connector.
It feels strange to predict that Apple would give up a proprietary device connector (Lightning) for a standardized one; in the 14 years since they first entered the consumer electronics business with the original iPod, Apple has used a non-proprietary connector exactly once: on the 1st-gen iPod Shuffle in 2005. Never before, and never since.
Moreover, even on the Mac side, Apple has demonstrated a marked preference for connectors which they invent and/or control: FireWire, MagSafe, Mini DisplayPort, and most recently Thunderbolt -- an Apple-Intel joint venture intended to be âone cable to rule them allâ. So why would things be different now?
Well, putting aside the question of why for the moment, the fact is: they are different, and the new MacBook is proof. To the surprise of many, including me, the rumours of an Apple laptop with a single port, and a non-proprietary one at that, were proved true earlier this year, when the MacBook arrived with a single USB-C port, to handle charging, accessories, external monitors -- the whole shebang.
While none of Appleâs other machines have been updated to embrace USB-C yet, I think they will, and soon -- in fact, Iâll stray from iOS into Mac prediction-land and say that the next MacBook Pro and iMac, both likely arriving this year, will feature USB-C ports prominently. Perhaps not exclusively, but definitely as a core feature.
I say this partly because it seems unlikely that Apple would adopt USB-C for one model, without ever intending to introduce it on their other machines, but also because in the months since the MacBook was launched, Intel (Appleâs Thunderbolt partner) has announced that the forthcoming Thunderbolt 3 standard will in fact be based on the USB-C connector. This lets Apple have their cake and eat it, too -- they (and Intel) can continue forging their own path by directing the Thunderbolt standard as they see fit, but they can do so on top of a small, versatile, non-proprietary, reversible, and high-power-capable connector.
The writing is on the wall for Lightning; USB-C is the new hotness. As with force touch, Apple may wait until 2016 to bring it to iPhone and iPad, but I predict it will make its debut with this yearâs models. (Hopefully also signalling a long-overdue end to the Apple cable tax...)
Apple Watch Watch
Iâll close with a quick (and easy) non-prediction about the Apple Watch: while a spec-bump âv1.5âł release this fall might help goose Christmas sales, there wonât be any new Apple Watch models until next year. I do think that Apple will, as they did with the iPad, move from a spring release cycle to a later one for the Watch, but that wonât be until next year at the earliest. When they do, it may take the form of a double-release (like the 3rd- and 4th-gen iPads, which both launched in 2012), or the âannualâ cycle may just gradually slip later and later into the year. It may not move all the way to September or October -- I can see Apple not wanting to have all of their products launching at once, for logistic and fiscal reasons, but the Watch is a prime Christmas gift, and I think Apple will move its release point into at least the summer going forward.
If you agree with my predictions and want to tell me how smart I am, or if you think Iâm an idiot and like arguing with strangers on the internet, come let me know on Twitter: @brookinc.
As I so bravely predicted in my post a few weeks ago, Apple did indeed launch a new version of their Swift programming language at WWDC -- in fact, they made the leap from version 1.3 all the way to 2.0. I've finally had a chance to read up on all the new features Swift 2.0 introduces, and if you want to know what I think about them, you're in luck...
En garde
The new guard statement seemed at first to me like a somewhat unnecessary variation of a normal if statement, just using assert-like condition phrasing (ie. you describe the "success case", not the "failure case") to facilitate early exit from a function. I say "unnecessary" because something like:
guard x > 0 else { return; }
...is exactly equivalent to:
if x <= 0 { return; }
However, as Eric Cerney helpfully explains, guard offers one neat syntactic trick that if does not: bindings which occur within the guard statement remain in scope even after the else case:
guard let myItem = getItem() else { return; }
myItem.doSomeStuff(); Â // works!
The benefit of this approach becomes even clearer when your code requires multiple optional bindings -- you can now turn this:
if let myItem1 = getItem1() {
  if let myItem2 = getItem2() {
    if let myItem3 = getItem3() {
      // do some stuff with myItems...
    }
  }
}
...into the much more readable:
guard let myItem1 = someFunc1() else { return; }
guard let myItem2 = someFunc2() else { return; }
guard let myItem3 = someFunc3() else { return; }
// do some stuff with myItems
...or even:
guard let myItem1 = someFunc1(),
let myItem2 = someFunc2(),
let myItem3 = someFunc3() else { return; }
// do some stuff with myItems
Of course, you don't always want to just silently return out of your function when something goes wrong...
I Am Error
The WWDC Swift 2.0 overview talk lays out (at the 30m15s mark) three distinct kinds of error a program might encounter:
trivial recoverable errors (ie. an optional-returning function returns nil)
detailed recoverable errors (ie. a file doesn't exist, a server call failed, etc.)
Swift v1.x offered ways to handle the first and third cases (simple if checks and run-time errors/asserts), but not the second case, at least not easily. Apple's solution? Swift 2.0's new error-handling model.
The game-development world I work in doesn't make much use of C++ exceptions, so I'm no expert on them, but this Swift 2.0 code nonetheless looks reasonably familiar to me:
do {
  try enterStarship("HeartOfGold")
  try activateShipboardComputer("Hi, Eddie.")
} catch StarshipError.AccessDenied {
  print("Couldn't enter starship.");
} catch StarshipError.SurlyComputer(let mood) {
 print("Sorry, the shipboard computer is feeling \(mood).");
}
One obvious difference here from C++ exception syntax is that the try comes immediately before each error-throwing function call, rather than just once wrapping the entire block (instead, a do wraps the entire block; more on that below). Similarly, each potential error requires its own catch block -- C++ also allows multiple catch blocks, but they're less common, since they're used to distinguish between exception types, not values. This increased specificity of both try and catch is a rare example of Swift requiring more "boilerplate" syntax than C++ does for corresponding functionality, but as in other cases, it's done deliberately, in the interest of increased clarity and expressiveness. As the WWDC talk linked above suggests (at the 28m25s mark), when error handling behaviour is too implicit, it can be difficult to clearly and expressively reason about the flow of errors in your code. To that end, in Swift, any function which may throw an error must explicitly declare that fact in its prototype with throws:
func enterStarship(name:String) throws { ... }
...and any code which calls such a function must specify try when doing so, to make it clear which specific calls might throw an error. If the calling code is prepared to deal with the errors that might arise, it can use a do - catch sequence like the one we saw above; if not, it must itself be declared with throws so that the potential propagation upwards is clear and explicit.
Defining types of errors that can be thrown by your code is done easily with the ErrorType protocol -- a struct or class can implement it, but it's best suited for enums:
enum StarshipError : ErrorType {
  case AccessDenied
  case SurlyComputer(String)
}
Note that enum ErrorType implementations also offer an easy, lightweight way to add a related data payload to an error -- in the SurlyComputer case, it's a string which denotes the specific mood of the surly computer at the time the error is thrown. Adding this payload at throw-time is just as easy:
func activateShipboardComputer(phrase:String) throws { let successfulActivation = Int(arc4random_uniform(3))
  if (successfulActivation == 0) {
    throw StarshipError.SurlyComputer("petulant")
  } else if (successfulActivation == 1) {
    throw StarshipError.SurlyComputer("abrasive")
  } else {
    print("Computer activated.")
  }
}
...and we already saw how we access that data payload at catch-time:
catch StarshipError.SurlyComputer(let mood) {
 print("Sorry, the shipboard computer is feeling \(mood).");
}
One additional feature that Swift 2.0 error-handling supports is defer -- a concept that doesn't exist for C++ exceptions (apart from the general concept of destructors), but which corresponds to Java / C#'s finally: code that's guaranteed to execute even if a throw causes an early exit. However, rather than appending a third block of code (like Java / C#'s try {} catch {} finally {}), Swift's defer statements are instead added to the main do block itself:
do {
  defer { exitStarship() }
  try enterStarship("HeartOfGold")   defer { deactivateShipboardComputer() }
  try activateShipboardComputer("Hi, Eddie.")
}
The advantage of this approach is that defer statements automatically accumulate according to execution: in the example above, if enterStarship() throws an error, exitStarship() will be called, but neither activateShipboardComputer() nor deactivateShipboardComputer() will be. In other words, this allows conditional cleanup logic to live alongside the code it's cleaning up, and keeps the conditionality of that cleanup logic implicit in the flow of code itself, without requiring any boilerplate to track execution state / success.
There is, however, one disadvantage to Swift's defer approach. By necessity (and common sense), the defer statements behave like a stack, and are therefore executed in reverse order of their declaration; in the example above, assuming no errors are thrown by enterStarship(), the execution sequence is:
This makes sense, and is as it should be -- but that order is not immediately evident from looking at the code. There are two issues: first, a defer statement always has to be declared before the error-throwing code it relates to, even though it will, by definition, execute afterwards; and second, deferred and non-deferred statements are declared together in sequence, but it's up to the programmer to remember that the deferred statements will execute in the reverse order of declaration while the non-deferred ones will execute normally.
As I mentioned in my previous post, Swift strives for both clarity / expressiveness and syntactic minimalism, but in this case it chooses minimalism over clarity. It's not necessarily a bad choice (this approach has the advantages noted previously, and every coder has had to deal with much weirder "gotchas" than this), but the fact that Swift has done (in my opinion) such a good job of maintaining clarity almost everywhere else in the language makes this sort of minor exception (no pun intended) stand out more than it would otherwise.
A final footnote on error-handling syntax: the use of do to delineate a potentially-error-throwing block of code (or in fact, to scope any abitrary code -- Swift 2.0â˛s do {} can also be used like bare curly braces are in C++) is an interesting choice; in Swift 1.x, do was (in keeping with convention) reserved for do - while loops. To accommodate this new usage, those loops have been renamed to repeat - while:
repeat {
  print("All work and no play makes Jack a dull boy")
} while (overlookHotel.hasPower())
That seems reasonable enough to me -- "repeat"Â perhaps makes it slightly less clear that the code is guaranteed to be executed at least once, but it also makes it more clear that it's a loop, which is the generally expected usage, so I'm fine with the change. At a higher level, I like that this decision illustrates continued willingness on the part of the Swift team to make a breaking change to the language syntax if they feel it's the right course of action. This makes developers' lives more difficult in the short term (although not much more -- Apple provides an automatic Swift 2.0 migration tool in Xcode), but gives the language crucial freedom to develop logically and avoid eccentricities resulting from backwards-compatibility restrictions. That's a better plan for the long term.
For further reading on the subject of Swift 2.0 error-handling, Erica Sadun has a helpful rundown of all the ways to fail in Swift, and Brad Larson has written an excellent comparison of Swift 2.0 error-handling with Swift 1.x's Result<T,U> approach.
Respecting Protocol
I'm 1300 words into this post, but still haven't mentioned what is arguably Swift 2.0â˛s biggest feature. It's one of the few that Craig Federighi specifically mentioned in the main WWDC keynote (around the 1h12m20s mark), calling it "The feature Tim [Cook] has been begging for all year": protocol extensions.
Craig was joking, of course (unless Tim's a much bigger programming language nerd than I thought), and it's a pretty straightforward-sounding change, but it does actually have big implications.
The feature is exactly what it sounds like: in just the same way that Swift 1.x let you extend structs, enums, and classes by defining new methods and computed parameters, Swift 2.0 now lets you extend protocols by defining new methods and computed parameters. Don't miss the buried lead in that sentence; the "extend" part is great, but "by defining" is the real bombshell. You can now use the extension keyword to both define implementations on a protocol, and to extend it:
// define the protocol
protocol HumanCyborgRelator {
  func interpret(text:String)
}
// implement / extend it
extension HumanCyborgRelator {
  func interpret(text:String) { print(text.uppercaseString)  // implement }
  func interpretMoistureVaporator(number:UInt) { print("\(number)")  // extend AND implement }
}
// adopt it in a class
class Droid : HumanCyborgRelator {
  init(_ name:String) { self.name = name }
  let name:String
}
// ...and get the implementations for free!
let c3p0 = Droid("C-3P0")
c3p0.interpret("Do you speak Bocce?")
c3p0.interpretMoistureVaporator(0b00101010)
Why is this such a big deal? One of the key decisions in the design of Swift was to, like Java, avoid the problems of multiple inheritance by simply avoiding multiple inheritance altogether: Swift (and Java) classes can inherit from at most one other class. As a result, Swift relies heavily on protocols to define and control shared functionality across potentially-unrelated classes. Also like Java (at least, prior to last year's Java 8 and its default keyword), Swift 1.x protocols defined solely an interface. So even if the logic for a given protocol method was identical among all implementing types, those types still needed to each define their own implementation.
Contrast this with abstract classes in C++, which (like Swift protocols) can't themselves be instantiated, but which can still provide method implementations, as long as those implementations use data and methods specified as part of the abstract class itself. Well, with protocol extensions, Swift can now also do exactly that, and for good measure, can extend protocols after the fact (something that's much more cumbersome in C++, involving subclassing the base abstract class with your own abstract class, and then deriving your own subclasses from your abstract class instead of the base -- which of course means your functionality doesn't apply universally or retroactively). With Swift 2.0, instead of just defining functionality for a type, you can, in a few keystrokes, define functionality for an entire category of types.
All of this sets the stage for what Apple hopes will become a whole new programming paradigm: "protocol-oriented programming". That was, in fact, the subject of its own WWDC talk this year, and it's a talk worth watching. The basic principle is that protocols give you the benefits of pure object-oriented-programming, but mitigate some of the drawbacks: they support both value (struct/enum) and reference (class) types, they have no inherent memory / initialization footprint (implementors can choose stored or computed members as they like), they're non-monolithic and easily composed, they clearly delineate what adopting types are responsible for implementing, they can be statically validated, and, thanks to extensions, they now also allow retroactive modeling (adding new behaviour to an entire existing category of types).
One benefit the talk focuses on specifically is flexible abstraction, via protocols, which enables loose coupling and its attendant benefits. Dave Abrahams walks us through the example of a Renderer protocol which can be implemented by a CGRenderer class for actual rendering, or a print()-based TestRenderer class for debugging. Protocols make this sort of swapping not only possible, but easy.
One additional protocol improvement in Swift 2.0 worth mentioning is that protocols can reflexively, but generically, now reference the specific conforming type (rather than the protocol type itself), if desired, with a "Self requirement":
protocol HumanCyborgRelator {
  func connectTo(other:Self)  // interface
}
class Droid : HumanCyborgRelator {
  func connectTo(other:Droid) { print("Connecting...") }  // implementation
}
Here, connectTo() is a function that allows any HumanCyborgRelator to connect to another HumanCyborgRelator -- of the same type. So the Droid implementation connects to another Droid, but not to a different class, even if that class also implements HumanCyborgRelator. This means the implementation of connectTo(other:Droid) can use all the methods and properties of Droid without resorting to force-downcasting (other as! Droid) -- type-safety can now be statically enforced (and better optimized) by the compiler. Circumstances will dictate which route you take in a given situation, but now you have the choice between allowing heterogeneous object interactions (by using your protocol type) or homogeneous ones (by using a Self requirement).
Opening the Kimono
I would be remiss if I didn't mention the Swift 2.0 announcement that had nothing to do with features, but which nonetheless resulted in a spontaneous 25-second ovation from the WWDC keynote audience: Swift is going open-source. The compiler and standard library will be released under a "permissive, OSI-approved" license (details to be announced later this year), and Apple will kick off the porting efforts by contributing a Linux port as well as their existing iOS and OS X implementations.
This is of course not Apple's first foray into open-source -- OS X is famously based on FreeBSD, and Apple has actively led (and benefited from) open-source projects like WebKit. Moreover, Chris Lattner, the creator of Swift, first made his name with LLVM and Clang (while employed full-time by Apple), which were open-source from the outset, and which became the backbone of Apple's developer toolchain. Nonetheless, it's impressive that Apple is willing to voluntarily "open the kimono" on their most promising and innovative developer technology in decades. Not that they're doing it entirely for humanitarian reasons, of course -- even as an open-source project, it will still very much be Apple's baby, so open-source Swift coders on Windows and Linux will still be expanding Apple's reach and influence. Apple will also likely benefit from the enhanced credibility and good karma this move will net them from developers, helping to keep Apple a "cool" place to work (as the kids say).
But I think it it really comes down to legacy: Tim, Craig, and Chris believe it when they say that Swift is "the next big programming language; the one we will all all be doing application and systems programming on for twenty years to come", and they want that "we" to be as large as possible. In truth, they don't have much to fear in giving Swift away; Microsoft and Google are unlikely to embrace it, having their own technology stacks to push, and open-sourcing it gives Apple an organic and populist path into their backyards, and (Apple hopes) eventually to world dominance.
Bones to Pick (2.0)
As noted in my last post, a language that is used is a language that is complained about, and Swift 2.0 is no exception. For example, the Swift team evidently agreed with my previous complaint that it felt strange that methods and functions had different default named-parameter calling conventions:
func reciteVogonPoetry(first:String, second:String, third:String) { ... }
class Vogon {
  class func recitePoetry(first:String, second:String, third:String) { ... }
}
// Swift 1.x calling conventions:
// function: 3 anonymous params reciteVogonPoetry("gruntbuggly", "micturation", "lurgid") // method: 1 anonymous and 2 named params
Vogon.recitePoetry("gruntbuggly", second:"micturation", third:"lurgid")
However, rather than my preferred solution -- having methods use the same behaviour as functions, ie. require no named parameters by default -- they instead doubled down on the awkward Objective-C method convention and made Swift functions adopt it as well:
// Swift 2.0 calling conventions: // function: 1 anonymous and 2 named params
reciteVogonPoetry("gruntbuggly", second:"micturation", third:"lurgid") // method: 1 anonymous and 2 named params
Vogon.recitePoetry("gruntbuggly", second:"micturation", third:"lurgid")
Alas, this is the approach that leads to awkwardly-named Apple library functions like this:
let myColor = colorWithRed(1.0, blue:1.0, green:1.0, alpha:1.0)
I understand that this is the Objective-C convention, and adopting this for Swift likely makes interoperability with the vast existing libraries simpler, but effectively requiring the first parameter name to be baked into the function name by default / en masse feels like a hack. I maintain a faint hope that some future version of Swift will coordinate with a mass-renaming effort of library functions to produce something more like this:
let myColor = colorWith(red:1.0, blue:1.0, green:1.0, alpha:1.0)
...but it's a pretty faint hope.
I also feel like there's room for further improvement in option sets (Swiftâs friendly wrapper for bitflags / bitfields) -- it's great that their usage syntax has been unified with regular sets, but the definition syntax still requires too much boilerplate:
struct HitchhikerAttributes : OptionSetType {
  var rawValue:UInt
  static let hoopy = HitchhikerAttributes(rawValue: 1 << 0)
  static let froody = HitchhikerAttributes(rawValue: 1 << 1)
  static let ravenous = HitchhikerAttributes(rawValue: 1 << 2)
  static let allAroundGreat: HitchhikerAttributes = [hoopy, froody, ravenous]
}
Option sets are, semantically, more like enums than they are structs, so defining them should be more enum-like, along these lines:
optionSet HitchhikerAttributes : UInt {
  case hoopy = 1, froody, ravenous  // froody == 2, ravenous == 4
  case allAroundGreat = [hoopy, froody, ravenous]  // == 7
}
...or, if you want to define non-sequential values:
optionSet HitchhikerAttributes : UInt {
  case hoopy = 1 << 0  // == 1
  case froody = 1 << 4  // == 16
  case ravenous = 1 << 8  // == 256
  case allAroundGreat = [hoopy, froody, ravenous]  // == 273
}
I don't know if bitfields (option sets) are a significant enough feature to merit their own high-level keyword and definition syntax (like enum), but I do think there's room for further improvement over their current state.
Miscellany
Amazingly, after all this typing, I've still only covered, at a high level, a handful of the many changes in Swift 2.0 -- in fact, even the 50-minute "What's New In Swift 2.0" talk at WWDC glosses over over more than half a dozen new features on a single "So Much More" slide (at 15m05s) in the interests of time. I'm going to do likewise, but will at least prioritize my list in approximate descending order of coolness / usefulness:
the new #available macro lets you branch your code in-place to simultaneously support different platforms and OS versions
the new @testable attribute lets you easily give your unit tests access to otherwise-private methods and members, without having to hack your code to do so
Xcode 7 offers numerous improvements (better error/warning messages, UI unit test macro-style "recording")
pattern matching everywhere: Swift 1.x's case ... where syntax for matching and filtering can now be used not only in switch statements but also in if, guard, for ... in, and while statements
option sets, Swift's friendly way of wrapping bitfields and bitflags, have had their usage syntax unified with Swift 1.2â˛s first-class Set type, for greater consistency and readability
rich, semantic comments (with Markdown syntax) are now supported
finally, Swift 1.x's print() and println() functions have merged into just print(), which now appends a newline by default (the common case), but allows you to pass in a bool to disable the newline print when desired. Two characters less! And a "cleaner", shared name! Silly as it may sound, I love these kind of changes. No refinement too small!
That still doesn't cover everything -- the WWDC talk linked above is recommended viewing; the Revision History section of the Swift Programming Language doc outlines a few more things I've omitted; and Erica Sadun has a helpful list of resources, too.
defer { print(conclusion) }
Itâs clear at this point that Apple is taking Swift development very seriously; Objective-C will be around for a while, but Swift is the future (and, increasingly, the present). Error-handling and protocol extensions are big additions to the language and certainly justify the 2.0 version jump, and I suspect it wonât be long before large-scale porting efforts begin within Apple (if theyâre not happening already) to rewrite more of their main apps in Swift. The move to open source will also be fascinating to watch -- if Swiftâs meteoric rise to date is anything to go by, there will be plenty of interest in getting it ported onto Windows, and who knows where it will wind up after that, or what jobs it will be used for? Swiftâs syntax remains a delight to use, and the toolbelt it offers coders is hefty, and growing. The future looks bright for Swift.
For further reading, as always, the Swift Programming Language and Swift Standard Library docs are your best friend (see the Revision History for quick access to the new 2.0 stuff). Erica Sadun writes lots of great stuff about Swift, you should read it. And best of all, SwiftStub now has a beta flag for writing Swift 2.0 code in your browser window, so hop on over and get coding!
I recently had some free time and decided to finally dig into The Swift Programming Language ebook thatâs been sitting on my phone since last year. I watched the WWDC keynote last June where Swift was introduced, and thought it sounded interesting, but I filed it away as âsomething to check out sometimeâ. Fast-forward a year, and Iâve finally gotten around to it (ironically, Iâm writing this mere hours before the 2015 WWDC keynote, where a new version of Swift will most likely be introduced and an updated version of the book rolled out, but such is life...) [EDIT: my Swift 2.0 overview is here]
Some background information might be helpful at this point: Iâve been a full-time triple-A game developer for nine years (specializing in User Interface code), and consequently the vast bulk of my professional coding experience has been in C++. Iâve worked occasionally with Java, JavaScript, and ActionScript, and have dabbled in PHP and C# (and SQL, for what itâs worth), but C++ is far and away where I spend most of my time.
That said, from my perspective I found the official Swift reference a thoroughly compelling read, and Swift a thoroughly compelling language. I read it cover to cover, and it makes me excited to try a project using Swift at some point.
It bears mentioning that the book itself is very well-written -- clear, concise, and generally making very few assumptions about the readerâs prior knowledge (a detailed explanation of twoâs-complement binary integer representation is provided, for example). And while the tone remains steadfastly professional, the code samples provide some sly references for the well-read nerds out there:
...and of course, it makes my towel-toting heart glad to see all of these:
Iâd also like to congratulate the authors on resisting the âfoo/bar/bazâ urge -- every sample variable and function shown throughout the book has either a descriptive name (func addOne(x:Int) {...}) or a descriptively generic one (let someInt = ...), keeping the clarity and readability consistently high.
So Whatâs So Great About Swift?
At a high level, Swift, like Java or C#, aims to provide an elegant, modern, full-featured language, with an emphasis on safety via automatic memory management. Unlike Java and C#, which use garbage collection to achieve that aim, Swift uses automatic reference counting, so that resources are automatically freed as soon as they are no longer in use. Safety always comes at a (performance) cost, but Apple is clearly betting that the performance cost of Swiftâs ARC will be low enough to make it a compelling language for a broad range of (Apple-centric) uses. For my part, Iâm a big fan of Jonathan Blowâs observation that optimizing for faster development time is often more important than optimizing for CPU or memory usage, and I think Swift is a clear step in that direction (though Apple aims to have their cake and eat it, too: âThe compiler is optimized for performance, and the language is optimized for development, without compromising on eitherâ).
Indeed, the biggest criticism of Swift Iâve encountered in my Googling is its performance, although it seems to be already quite good in many scenarios, and steadily improving with each release.
Syntax
The first pleasant surprise with Swift compared to Appleâs âotherâ language, Objective-C, is its familiar and friendly C++/Java-style syntax: no more wacky bracketed message-passing (no, Iâve never used Smalltalk), just the classic dot-syntax for members and parentheses for function calls that K&R so elegantly laid out almost forty years ago. Amusingly, the book specifically points out that Swift, in contrast to Objective-C, breaks free of âthe constraints of C compatibilityâ under the hood -- while at the same time moving (back) closer to C syntax.
Syntax was clearly a big focus of Chris Lattner and the Apple Developer team for Swift: not only making it familiar for C++/Java coders, but also making it better than those languages by removing as much boilerplate as humanly possible. Swiftâs type inference is the most obvious manifestation of this, and itâs delightful -- a strongly-typed (ie. performant) language that will figure out the types Iâm using without me having to tell it every time, everywhere? Sign me up.
Other syntactic touches like being able to (optionally) delineate numeric literals with underscores for readability (10_000_000 vs. 10000000), being able to specify binary literals (0b11110000), not requiring semicolons at the end of every statement (a habit that will die hard for me, but a gesture I nonetheless appreciate), nested range comments (/*a /*nested*/ comment -- epic!*/), a modulus operator that works for floats as well as ints (5.3 % 2 == 1.3), closed and half-open range operators (1...3 includes 1, 2, and 3, while 1..<3 includes only 1 and 2)... the list goes on.
Perhaps my favourite illustration of Swiftâs fetish for syntactic minimalism is this example from the Closures chapter, which gleefully details six increasingly concise ways to write the exact same code:
The example is of course carefully chosen to specifically demonstrate this sort of reduction -- I donât imagine very many real-world applications will be looking for closures simple enough to be expressed in a single character. But I still like that theyâre thinking this way. Any time I can do something in fewer lines (and characters) of code, ideally without sacrificing readability or performance, Iâm a happy coder.
Safety
Occasionally Swift does choose to require slightly more boilerplate than its C++ equivalent, though it generally does so to improve clarity and reduce the chance of mistakes, and itâs hard to find fault with that. Granted, in C++ I do sometimes like to skip the braces around a single-line if statement, or omit the (empty) default case in a switch, but I can see the rationale for always requiring them, and itâs not a big deal to make those adjustments.
Further to that point, safety has clearly been a watchword in the development of Swift. The ARC-based automatic memory management is the most prominent example, of course, but the braced-if and exhaustive-switch requirements mentioned above are just two of the many other language decisions motivated by safety. An explicit (not coerced) Bool is required for if statements, preventing the classic âif (a = b) {...}â error. All integer operators are overflow-safe by default (var myNum: UInt8 = 255; myNum++; will trigger a runtime error, for example), although alternate overflow-friendly operators are available if needed. Combining safety and brevity, case statements in a switch break by default -- if you wish to fall through to the next case, you must do so explicitly with the fallthrough keyword, preventing the hard-to-spot accidental fallthrough that has bitten me more than once in C++. Loops and switch statements can optionally be given a label, and that label can then be referred to by any break or continue statements nested therein, so that you can make the intention and scope of your break / continue explicit.
The argument could be made (and Iâm sure has been) that handing off all this safety logic to the compiler and runtime just makes programmers lazier and less careful, while making the resulting machine code slower and more bloated. While thatâs probably true, at least to a degree, the same basic argument could be made against every programming innovation of the last (n) decades. Why program in Swift when C++ is faster? Why program in C++ when C is faster? Why program in C when assembly is faster? Obviously, performance is a factor, but if history is any guide (and if Mooreâs Law keeps on truckinâ), the eventual success of increasingly higher-level languages like Swift is a good bet.
Batmanâs Utility Belt
Interestingly, while Swift embraces syntactic minimalism, it arguably offers language-feature maximalism, with an impressive laundry list of natively-supported bells and whistles:
Arrays
Dictionaries
Sets
Optionals
Tuples
First-class Functions
Closures (and Nested Functions)
Full-featured Enums
Structs
Classes
Computed Properties
Property Observers
Protocols
Extensions
Generics
These features all seem to play pretty well with each other, at least in the confines of the language reference -- the answer to the question âI wonder how (x) works?â seems to generally be âThe way youâd expect it to.â And should you get bored with all that stuff, why not start defining your own custom operators, complete with custom precedence and associativity?
Bones To Pick
Of course, per the Stroustrup quote above, Swift is apparently a language that people use, so it is therefore a language people will complain about. Iâm happy to prove the rule:
using Int/UInt8/16/32/64 for explicitly-sized integer values, and just Int and UInt for ânatively-sizedâ values, makes perfect sense. So why stick with âFloatâ for an explicitly sized 32-bit floating point number and âDoubleâ for 64? Wouldnât it have been more consistent to use Float32 and Float64, plus just Float for the current natively-sized version? âDoubleâ is a bad name -- itâs non-descriptive, has no apparent semantic connection to âFloatâ, and basically only makes sense if youâre already used to it. An obvious missed opportunity for improved clarity.
similarly, it feels like an admission of defeat to read: âUse UInt only when you specifically need an unsigned integer type with the same size as the platformâs native word size. If this is not the case, Int is preferred, even when the values to be stored are known to be non-negative.â Given Swiftâs emphasis on expressiveness and safety, why would it be recommended to allow negative values for a quantity I know should never be negative? (I understand the technical reasoning, but it feels like a concession, in a language that fights hard not to have to make that kind of concession)
overall, Swift does a very good job (in my opinion) of cutting its syntactic ties to Objective-C, while still (impressively) maintaining interoperability with Objective-C libraries and code. One odd exception, however, is that the external name behaviour of methods (but not functions) matches Objective-C by default: the first parameter is anonymous, while any subsequent parameters require their external name. Supporting such behaviour is perhaps a requirement of interoperability, but why make it the default? It feels strange to have a method like, for example: func moveTo(x:Int, y:Int) { } which then requires a calling syntax of obj.moveTo(5, y:10). Yes, I can explicitly force y to be anonymous (func moveTo(x:Int, _ y:Int) { }), but why should I have to?
it seems like a strange limitation that subclasses can only call designated initializers of their superclass, not convenience initializers -- since convenience initializers by definition immediately delegate to designated initializers, why the restriction? Perhaps thereâs an under-the-hood reason (or a more obvious one that I missed), but it seems like an unnecessary prohibition to me.
The Wrap-Up
Unsurprisingly, I have many other thoughts on Swift that havenât made it into this post yet, but itâs late and I need my beauty sleep. I havenât discussed (nor does the book, for that matter) Playgrounds, or Swiftâs unusual take on access control (public vs private members, methods, and types), or curried functions, or failable initializers, or...
But for what itâs worth, Iâm sure I will have reason to revisit this subject in a future post. Stay tuned.
For now, suffice it to say that Swift seems like a promising language with a ton of neat tools and a sparkling-clean syntax that I kind of love. If this post has piqued your interest, I highly recommend reading the official guide, and/or installing Xcode, and/or just loading up swiftstub.com and playing around with it.
If you appreciate the style of minimalist âcard-onlyâ wallets like Slab, Poquito, and their many cousins, but donât want to shell out big cash for one (or pay $32 for shipping), you can out-hipster the hipsters and make your own from the lid of an Altoids tin -- available at your local corner store for $3.
As you can see above, Altoids tins happen to be exactly the right width and height for this purpose, and the hinge mechanism can be easily pried open with a dinner knife for quick lid removal.
For the band, pretty much any wide ~3âł elastic will work reasonably well. If you have a LiveStrong-style rubber bracelet lying around looking for redemption, that works perfectly. In my case, I had a length of 0.5âł braided elastic handy (available at your local sewing supply store), so for maximum hipster cred I stitched it into a loop myself.
The wallet holds five or six cards comfortably (pictured above with six), which works fine for my purposes. The metal isn't terribly strong, so it may bend or warp slightly with use, and the paint will chip off the corners, but of course, all that just makes it even more hipster...
I recently switched to a standing desk at work, and have been enjoying it (it helps minimize the lower-back pain I get from sitting for a long time), so I wanted to set one up at home as well. My interest was piqued by Ikeaâs new Bekant electric sit/stand desk, which has received mostly (though not entirely) positive reviews, but for a few reasons I decided to put my own setup together instead:
the electric sit/stand Bekant isnât currently in stock anywhere in Canada, as far as I can tell
I like the idea of the electric motor for easy adjustment, but itâs not really necessary for a sit/stand setup â Iâm fine using a (tall) drafting chair instead of a typical office chair when I want to sit
although the Bekantâs list price of CAD$599 is pretty reasonable for an electric sit/stand desk, a static standing desk can be put together even more cheaply
Iâve read about Ikea hacks like the famous $22 standing desk, although I was looking for something a little more substantial. I wanted a full-size desktop surface, raised to a height of 47-48âł (Iâm 6â˛2), with a monitor riser another 6-7âł above the desktop. I didnât consider drawers a necessity, although I did want some form of under-desk storage or shelving.
With all that in mind, you can see in the photo at the top of this post what I came up with. Here are a couple of additional views:
(Note that the wall shelves seen here predate my standing desk and arenât part of this post, per se â although I built them myself from pine 1x8s and am happy to share the designs if anyoneâs interested.)
My shopping list for the main desk components was as follows: (all prices in Canadian dollars, since I live in Canada :D)
-Hilver bamboo table top (CAD$59)
-Gerton adjustable legs x 4 (CAD$140)
-Lack wall shelf (CAD$20) (ie. monitor riser)
-Capita 4.5âł legs (CAD$15) (ie. monitor riser legs)
-Rast nightstand x 2 (CAD$40) (for under-desk storage)
Total: CAD$274 (+ tax)
I also added these extras:
-Bosnas footrest / storage (CAD$18) (highly recommended)
-Tertial desk lamp (CAD$10)
-Dragan bamboo boxes (CAD$13) (they match the pattern of the desktop)
-Tjena shoeboxes x 3 (CAD$8) (the large size is a perfect fit for the Rast units)
-Iggsjon floormat (CAD$6)
Total: CAD$55Â (+ tax)
Last but not least, I picked up a basic Staples ergonomic drafting chair for CAD$140Â (+ tax). The seat height ranges from 23-33âł, and at its maximum itâs just about right for my 48âł desktop height.
Iâve been using this setup for a month or so now, and Iâm pretty happy with it â itâs a big improvement on my previous desk situation, and for not that much money.
One way this little Ikea hack could be improved is that the Rast units are a bit too long to fit between the desk legs â their standard size makes the unit about 20.5âł long, whereas the Hilver / Gerton leg combo only leaves about 17âł of space between the legs on either side. Thatâs why I have both of my Rast units tucked directly under the desk, inside of the legs. The amount of space left between them for my feet (~22âł) is fine for me, so Iâve just gone with it, but if a person needed more, and was willing to sacrifice 3.5âł of Rast shelf space to get it, it could certainly be achieved by trimming the Rast shelves down accordingly before assembling them. You could also look at getting a deeper desktop than the Hilver â itâs 25.5âł, but some of the table tops go as deep as 30âł, and might (?) thus have enough between-leg room for a standard Rast unit.
PS. A note on height: the Gerton legs are advertised as extending to 42.5âł, although if youâre willing to ignore Ikeaâs recommendations, you can actually extend them to about 44.5âł. This does result in some increased wobbliness, but it can be mitigated by keeping your desk flush against a wall for added stability. Nonetheless, 44.5âł of leg height plus the 1âł thick Hilver top still only made 45.5âł, which was slightly below my comfortable standing height. Ikea used to sell âFanbyâ bed risers which could be used under each desk leg to add several inches, but they appear to have been discontinued. The Bay sells a nearly identical product for CAD$15, but I ended up springing for a set of nicer-looking wooden ones from Bed Bath & Beyond (CAD$33). They added 2.5âł of height, which was just enough to get me to an overall desktop height of 48âł.
Update: ProductHunt has a nice round-up of some other cheap-and-cheerful standing desk options. (I still like mine best, though.)
Hello Ms. Fry,
As one of your constituents (V6B6M3), I'd like to know why you support the pending Bill C-51.
It's fair to argue that Canada faces threats to its national security and must be vigilant about preventing terror attacks, but any measures taken must also respect the privacy and rights of Canadian citizens -- we must be protected not only from terror but from the real threat of surveillance, harassment, and persecution by our own government.
Bill C-51 is ill-considered, overly broad, and critically lacking in effective, independent oversight, which is why it's been denounced by more than a hundred academics ( http://www.cbc.ca/news/politics/anti-terrorism-bill-c-51-dangerous-legislation-100-academics-say-1.2975233 ), four ex-PMs (three of them Liberal), five former Supreme Court justices, three past members of the intelligence review committee, two former privacy commissioners, and a retired RCMP watchdog ( http://www.cbc.ca/news/politics/csis-oversight-urged-by-ex-pms-as-conservatives-rush-bill-c-51-debate-1.2963179 ). It of course is also opposed by the government's own privacy commissioner, who as you no doubt know is being prevented from testifying before the Public Safety Committee on this matter ( http://www.cbc.ca/news/politics/bill-c-51-privacy-watchdog-daniel-therrien-blocked-from-committee-witness-list-1.2991265 ).
I understand that the Liberal Party has some objections to the bill, but the plain fact is that you are nonetheless voting in favour of it. If you truly agree that the bill is flawed, and expect to be credited for taking that position in the upcoming election, then take a stand that matters and vote against this deeply flawed legislation. Canadians deserve better than Bill C-51, and we deserve representation from people who acknowledge that truth in a meaningful way.
If you'd like to further understand my objections to Bill C-51, this analysis summarizes my position very well: http://www.thestar.com/opinion/commentary/2015/02/17/bill-c-51-moves-us-one-step-closer-to-the-end-of-privacy.html
Lastly, it goes without saying that the saga of Maher Arar should cast a long shadow over any efforts to increase "information sharing" between government agencies without a corresponding increase in oversight, transparency, and accountability. For such a thing to have happened once is horrible, but for us to subsequently pass a law that makes such an episode more likely would be shameful.
Thanks for your time,
Brook Jones
(follow-up - sent 2015.05.04)
Hello again Dr. Fry,
In the absence of a reply to my earlier letter, and in view of the imminent final vote, Iâd like to reiterate my thoughts on Bill C-51, and again encourage you to consider voting in the interests of your constituents rather than along party lines.
The parliamentary review process has not succeeded in producing any meaningful amendments to the bill -- I concur with the BC Civil Liberties Association, who concluded their point-by-point analysis of the committeeâs changes changes thusly: âThis Bill is fundamentally flawed, and cannot be salvaged by any amendment, let alone these fourâ.
Nor have any of the Liberal Partyâs proposed amendments been adopted -- and even those were deemed inadequate by the Canadian Civil Liberties Association: âWhile we appreciate the Oppositionâs attempt to claw back some of Bill C-51âs most significant excesses, Bill C-51âs constitutional overreaches cannot be remedied through piecemeal amendmentâ.
It is difficult to understand why you would then vote to enact a bill whose support has plunged steadily as Canadians have learned about exactly how sweeping and unregulated the powers it grants to police and government agencies are. The numerous serious issues identified by Forcese and Roach barely two weeks after the bill was introduced all remain, and if this bill becomes law, it will make Canadians less safe: as the case of Maher Arar has amply demonstrated, we must be protected not only from terrorists, but also from the very real threat of surveillance, harassment, and persecution by our own government.
Please consider your constituents, of whom I am one (V6B6M3), and vote âNoâ on Bill C-51 tomorrow.
yousharknotpass
pixelskylines
gummygunk
tangentwithtanner
romaincrisis
ellievsbear