Monday, September 15, 2014

Reading plan: September checkin

 My goal for the month of July was:
  • continue on the synthesis and try to have a closure on it, spending about 2 more hours
I didn't have any goals for August.

I only managed to spend another hour in July, and I don't have a closure. So I have decided to park this work for a while.

The good news is that I have just started reading Daniel Dennett's Intuition Pumps and Other Tools for Thinking this month, one of the books on my reading plan for 2014.

I have decided to read this book not in digital format, but on good old paper. I have also decided to allow myself to trash this book with highlights and annotations as I see fit.

My goal for the rest of the month is simply to make progress reading this book.


Saturday, September 13, 2014

Rationalizing the iPhone 6 Plus

iPhone 6 and 6 Plus

Daniel Miessler asked himself which iPhone 6 to get and I did the same. Here are my thoughts.

First, whether considering the 6 or 6 Plus, there is definitely a decrease in pocketability. But I see the move to larger screens as necessary [1] as we use the devices we call phones more and more as computers-which-you-carry-in-your-pocket. [2]

After Apple’s keynote, I hesitated a little bit between the iPhone 6 and the 6 Plus. Initially I was pretty sure that I wanted the larger size. Then I printed the templates and realized that the Plus was larger than I had expected. I started having doubts about whether I would like the larger device, in particular:

  • Will it fit in a pocket relatively comfortably, or will it be a constant annoyance? [3]
  • Will I be able to use it with a single hand at least part of the time? [4]

In the end I decided to get the 6 Plus and to consider it an experiment: a device so different from the ones I have had so far (iPhone 3G, [5] iPhone 4, iPhone 5) might change my habits in some interesting ways.

I am also experimenting in another way: I have had AT&T contracts since the iPhone 3G in 2008. This time around I ordered an unlocked iPhone 6 Plus for use on the T-Mobile network. [6] I like the idea of having an unlocked device, as well as having more options for plans. I will probably try to get one of the T-Mobile prepaid plans (which they don’t advertise much). [7]

Here are the features specific to the 6 Plus I am looking forward to:

  • Improved camera with optical stabilization. I have kids and I consider the camera which I carry with me at all times important. [8]

  • Bigger screen. Many activities should be more comfortable with a larger screen. Will I use my phone for reading more? Will I still be interested in getting the next Kindle?

  • Improved battery life. Depending on which feature you are looking at, the battery life is supposed to be better across the board. For example, Wi-Fi browsing is 10 % longer and standby 60 % longer.

I am also looking forward to the following features shared by the 6 and 6 Plus:

  • Improved speed. The CPU improvement announced is “only” 25% over the iPhone 5S, but the 5S was about twice faster than the 5, so that will be a nice improvement.

  • The new hardware design. I like the rounded body, which looks more like the original iPhone and should make the device pleasant to hold. The iPhone 3G, while plasticky, was also great to hold due to the curve of its back, and from this perspective the iPhone 4 to iPhone 5S design was a step back.

  • Apple Pay. I don’t need to pay in stores all day long, and this won’t revolutionize payments, [9] but I am intrigued by this combination of Touch ID and NFC. Will it work as reliably and fast? Will it work in stores I am likely to visit? The US is finally implementing “Chip and PIN” cards to help prevent fraud. This means that it might become a little slower to pay with cards than it has been so far, as you will have to enter your PIN. [10] Could Apple Pay be slightly more interesting due to this move?

I am looking forward to retire my beat up iPhone 5!


  1. We can say it now that Apple is finally in the race!  ↩

  2. Not in all pockets in the case of the iPhone 6 Plus, Galaxy Note, or the 6" Nokia Lumia 1520. There is word that Google might come out with a large Nexus phone soon as well.  ↩

  3. If not, I can always consider 5.11 TacLite Pro Pant. I don’t think I can consider a European carryall.  ↩

  4. The iPhone 6 Plus has a feature called Reachability to help with this: a double-tap of the home button brings down the content to make it reachable by the thumb.  ↩

  5. Steve Jobs referred to the original iPhone’s screen as “giant”. Times have changed.  ↩

  6. I already knew the price of the device, but it was still a bit of a shock to see the final price in the shopping cart (almost $1,000 with sales tax!). It is a neat trick that the big US carriers have pulled to subsidize the price of devices over 18–24 months. I would bet that a large majority of smartphone users do not know the actual price of the device.  ↩

  7. I don’t have an absolute guarantee that this will work out. But the phone will be unlocked and T-Mobile has a “bring your own device” option so I am hoping things will be smooth.  ↩

  8. The camera of my iPhone 5 has gathered dust inside, and I find myself reaching for my wife’s iPhone 5S regularly. I also take my SLR on specific occasions.  ↩

  9. For two reasons: because the major credit card companies are still involved, and because the system is limited to the Apple ecosystem.  ↩

  10. This American Express FAQ says: “If you have a Chip and PIN enabled Card, you must use your PIN (Personal Identification Number) when prompted, to pay for goods and services”.  ↩

Wednesday, July 16, 2014

Reading plan: July checkin

My goals for the month of June were:
  • spend 3 quality hours
  • complete synthesis of the organ book
I spent 5 hours in  June, which is good as that means I did more than planned! However that was not enough to complete that synthesis.

It's already mid-July and I have spent another hour on the synthesis. For the rest of the month, I will continue on the synthesis and try to have a closure on it, spending about 2 more hours.

For next month, I want to separate the tasks:
  • planned reading
  • writing about what I read
I do not plan to write about all the books I read, certainly not in depth. Still, if I want to read at least one other book this year, I better start doing the reading part regularly, and if writing is needed consider that a separately planned task.

Tuesday, June 3, 2014

Thoughts on the Swift language

What it is

I am not a language designer but I love programming languages, so I can’t resist putting down a few rough thought on Swift, the new programming language announced on Monday by Apple. It is designed to make Objective-C, the main language used to build apps on iOS and OS X, a thing of the past. I think it’s fair to say that this was, for developers, the highlight of Monday’s WWDC keynote.

Objective-C is a dinosaur language, invented in the early 1980s. If you know any relatively more modern higher-level language (pick one, including C#, Scala, even Hack), it is clear that it has too much historical baggage and not enough of the features programmers expect.

John Siracusa captured the general idea in his 2005 Avoiding Copland 2010 article and its revision, Copland 2010 revisited: Apple’s language and API future, and has kept building a really good case since, in various podcasts, that Apple had to get their act together. Something, anything, had to be done. [1]

There was a possibility that Apple would keep patching Objective-C, moving toward a superset of a safe subset of it. But I don’t think that anybody not working at Apple saw Swift coming that, well, swiftly. [2]

Why this is good for programmers

Reactions to Swift so far seem mostly positive. (I don’t tend to take the negative reactions I have seen seriously as they are not argumented.) As Jeff Atwood tweeted: “TIL nobody actually liked Objective-C.”. I share the positive feeling for three reasons:

First, I believe that programming languages matter:

  • they can make developers more or less productive,
  • they can encourage or instead discourage entire classes of errors,
  • they can help or hinder reuse of code,
  • they can make developers more or less happy.

With brute force and billions of dollars, you can overcome many programming languages deficiencies. But it remains a waste of valuable resources to write code in an inferior language. Apple has now shown that it understands that and has acted on it, and they should be commended for it.

Second, concepts which many Objective-C developers might not have been familiar with, like closures, immutable variables, functional programming, generics, pattern matching, and probably more, will now be absorbed and understood. This will lead to better, more maintainable programs. This will also make these developers interested in other languages, like Scala, which push some of these concepts further. The bar will be generally raised.

Finally, arguments over the heavy, ugly syntax of Objective-C, and its lack of modern features can be put to rest: Apple has decided the future path for iOS and OS X developers. That ship has sailed.

Where it fits

What kind of language is Swift? I noticed on Twitter that many had a bit of trouble positioning the language. Did Apple reinvent JavaScript? Or Go? Is Swift functional first? Is it even like Scala? What about C#? Or Clojure or XQuery?

I haven’t seen anything in Swift that is not in other programming languages. In fact, Swift features can be found in dozens of other languages (in Lattner’s own words, “drawing ideas from Objective-C, Rust, Haskell, Ruby, Python, C#, CLU, and far too many others to list”), and that’s why many have found similarities with their language of choice. So Swift is not “innovative”. Instead it is a reasonable mix and match of features which make sense for the Apple ecosystem.

Here are a few essential aspects of Swift which are not language features but which put it in context. These all appear to be essential to Apple:

  1. Owned by Apple: Swift is fully owned by Apple. It does not depend on Oracle (Java/JVM), Microsoft (.NET), or Google.

  2. Objective-C integration: Swift is designed to integrate really well with Objective-C. In fact, this is likely the second most important reason Apple felt they had to create their own language (in addition to ownership). There are precedents: Groovy, Scala, Clojure, Kotlin, Ceylon and others are designed to interoperate well with Java; CoffeeScript with JavaScript; Hack with PHP; Microsoft’s CLR was designed from the get go as a multi-language VM. This is important for initial adoption so that existing code can be reused and the new language progressively introduced. It would have been possible, but much harder, for Apple to pick an existing language.

  3. Static typing: Swift is a statically-typed language. There is type inference, which means you don’t have to actually write down the types everywhere, in particular within functions. But types are there nonetheless. So it looks more like dynamic languages, but is not one. [3]

  4. A dynamic feel: This is part of the “modern” aspect of Swift: a move toward concision which appeals to programmers used to dynamic languages, but with the presence of static typing under the hood. This combination of terseness and static typing is something Swift shares with Scala.

    Swift has a REPL and Playgrounds (the interactive demo by Chris Lattner looked impressive), which includes what some other environments call “worksheets” and a bit more. Clearly that’s the direction development tools are taking. All of this is becoming mainstream, which again raises the bar.

  5. Native compilation: Swift is compiled down to native code, like C, C++, Objective-C, Go, and Rust. There is no interpreter or VM, as in Java, JavaScript, C#, Ruby, PHP, or all dynamic languages, besides the small Objective-C runtime. Also, it doesn’t have a real garbage collector: it uses automatic reference counting (ARC).

    Swift is a bit odd in that native compilation and lack of full garbage collection make it closer to systems language, yet it is clearly designed to build applications. I wish the balance had moved more toward the higher level rather than the lower level, but it’s an interesting middle ground.

What’s disappointing

Here are a few aspects of Swift which, at first glance, disappoint me a bit. Keeping in mind that this is a first version of Swift which has room to grow:

  1. Openness: So far Apple has not announced that the Swift compiler would be open source, like the Objective-C compiler. This is a big question mark. It would be the right thing for them to do to open the compiler, and I am hopeful that they will.

  2. Garbage collection: It’s likely that Apple considered that ARC was good enough in most situations, and it makes interoperability with Objective-C (compatibility in terms of memory management) much easier to handle. Still, this would give me trouble. Lack of proper garbage collection means more memory bugs to hunt down.

  3. Concurrency support: Swift doesn’t have async/await, like C#, Scala, and soon JavaScript, or futures and promises. Async support is important in client apps as much as in server apps.

  4. Type system: The type system appears very simple. This might be seen as good or bad. The reference book doesn’t even mention the word “variance”. (I suppose Swift picks a default, but doesn’t allow programmers to control that.)

  5. Persistent data structures: There doesn’t seem to be persistent data structures (which are truly immutable yet can be updated efficiently thanks to structural sharing), as in Clojure and Scala. These are incredible tools which many programmers have now found to be essential. Immutability, in general, gives you much increased confidence about the correctness of your code. I would miss them in Swift.

  6. Well, innovation: Dart, Go, Hack, and Swift show that it is very hard for big companies to come up with something really unique in their programming languages. Academia remains the place where new ideas are born and grow. Still, it would have been nice if there was one or two new things in Swift that would make it special, like for example Scala’s implicits which have turned out to have far-reaching consequences (several of which I really like).

Browser and server

I am curious to see if Swift will see adoption on the server, for services. It might make sense for Apple to use Swift internally for their services, although having a language is not enough: you need proper infrastructure for concurrent and distributed computing. Swift is not there yet. But it could be in the future. This is a bit less important to Apple than the client at this time.

What about the browser? Could one conceivably create a Swift-to-JavaScript compiler? I don’t see why not. JVM languages, from Java to Clojure to Scala, now compile to JavaScript. Swift currently uses ARC, but in a browser environment it could probably work with the JavaScript VM’s garbage collector.

So there might be room, in years to come, for Swift to conquer more environments.

Google!

Where does Google stand with regards to this? It’s curious, but I think now that it’s Google which might have a programming language problem! Android uses Java but, as famous programming languages guy Erik Meijer tweeted, “Swift makes Java look tired.” (To be fair, most languages make Java look tired.)

Google also has Dart, which so far hasn’t been positioned as a language to develop Android or server apps. But maybe that will come. Go is liked by some for certain types of server applications, but is even more of a “systems language” than Swift, and again Google hasn’t committed to bringing it as a language to write Android apps.

Will Google come up with yet another programming language, targeted at Android? The future will tell. If it was me, which of course it isn’t, Scala or a successor would be my choice as a great, forward-looking language for Android. And Google could point their Android developers to Scala and say “Look, it looks very much like Swift which you already know!” ;)

Did I miss anything? Let me know in the comments or on Twitter.


  1. Back in 2009 I even tweeted:  ↩

    MS has Anders Hejlsberg (C#). The JVM world has Martin Odersky (Scala). Apple should work with Odersky on the next language for OS X.

    Obviously it wasn’t Odersky, but Chris Lattner, who got to be the mastermind of Swift.

  2. Good job by Apple, by the way, to have managed to keep it under covers so well since July 2010!  ↩

  3. There is a difference with with languages that have optional types, like Dart and Hack. Dynamic, optionally typed, and statically typed languages can, from a syntax perspective, look very similar. But under the hood some pretty different things take place.  ↩

Monday, June 2, 2014

Reading plan: June 1 checkin

My goals for the month of May were:
  • 3 quality hours of reading
  • complete synthesis of the organ book
  • pick the next book to read and start
I did manage to do a bit more than 3 hours of planned reading, so that's a success! Now "reading" is a bit of a misnomer because all of this time was spent working on the synthesis. But that was not enough to complete it, so the success is only partial.

Surely, 3 more hours in June should allow me to complete the synthesis this time? Ok, that's the plan.

Wednesday, April 30, 2014

Reading plan: May 1 checkin

My goals for the end of March were:
  • 3 quality hours of reading
  • complete synthesis of the organ book
  • pick the next book to read and start in March
In March, I did spend 2 hours out of the 3 planned, but that wasn't quite enough to complete the synthesis, and I haven't picked the next book yet.

In April, I completely dropped the ball: I missed the April 1 checkin and didn't do anything related to my reading plan during the month.

I had scheduled 1/2 hour on the reading plan each Wednesday and Thursday afternoon. But I found myself "too busy" or too guilty to take that time off work. Yet it's too difficult to find quality time late in the evening.

So for May, let's try to get back on the wagon and to do 3 hours spread over the whole month. Otherwise, same goals: complete the synthesis, and pick the next book.

Tuesday, March 11, 2014

Why I am returning my Seiki 39" 4K "monitor"

Notice the tiny 27" iMac behind the Seiki

After reading some recent blog posts (such as 4K is for programmers) about using the Seiki SE39UY04 39-Inch 4K TV as a computer monitor, I figured it might be an interesting experiment and I ordered last week a slightly used one. The price including taxes and free shipping was just under $500.

First, I do want more pixels [1] but it’s a bit unclear to me whether a 39“ monitor is workable or even desirable on a desk. I currently use an old 30” Dell monitor, so I am used to big screens, but 39" is gigantic! [2]

Second, that particular monitor is sold as a TV and not designed to be used as computer monitor in the first place. This means that it has important limitations, such as the absence of a direct input mode, and an abysmal 30 Hz input refresh rate at the native resolution. (This doesn’t mean that you see flickering, as on old CRT monitors. It just means that you only get at most 30 different frames every second.)

So I got the monitor on Friday and immediately set it up. It was easy:

  • connect the HDMI cable to the MacBook Pro’s built-in HDMI output
  • turn on the TV and wait for it to “boot”
  • turn down “sharpness” to 0 (important, otherwise you see artifacts)
  • play a bit with brightness (possibly too bright even at the minimum) and contrast

With the image adjustments, picture quality is pretty good. I don’t think it’s possible to get this monitor to have colors that are acceptable for photography or video, but for programming it seems decent.

However the issue that was an immediate turn off is the mouse lag. In practice, this translates to mouse or trackpad input which is very imprecise. Keyboard input is also visibly lagging.

It just take a while, it seems, for the output of the computer to actually make it to the screen. I suspect that part of the issue might not be so much the 30 Hz refresh rate (although you do notice that when moving stuff around and scrolling) as image processing done by the TV.

It is a known issue [3] that monitors and TVs do crazy (and unneeded) image processing which increases the time between receiving data from the computer and actually showing it on the screen. Some TVs have a “direct” or “game” mode which alleviates the problem, but the Seiki doesn’t.

I tried a couple of things to improve the lag:

In the end I don’t think I can get used to the lag, so the Seiki is going back. I will revisit getting a new monitor once the dust around 4K settles a little bit. There is upcoming 60 Hz output support in OS X for the MacBook Pro, and there should be many new 4K monitors of various sizes coming out this year. I am not sure yet if I would choose something as big as 39", but we’ll see!


  1. The built-in 15“ Retina MacBook Pro display is 2880x1800, my external 30” Dell is 2560x1600 and the Seiki is 3840x2160. Having more pixels is good, whether to get closer to a “retina” resolution, or just to get more content on screen (like a debugger next to the app being debugged).  ↩

  2. Ideally, I would like the whole virtual space around me to be something like a monitor, where I could put virtual items, and use the brain’s spatial abilities to make the best use of it. But hardware and software are not there yet.  ↩

  3. See John Siracusa on various podcasts and John Carmack’s post on display latency.  ↩