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.  ↩

Sunday, March 9, 2014

Reading plan: March 1 checkin

At last month's checkin, I had the following goals:
  • complete my quick synthesis of the organ book
  • pick the next book to read and start in February
  • spend about 5 hours in total
I failed on all counts:
  • I did work on the synthesis but I did not complete it.
  • I didn't pick and start the next book.
  • I spent a total of  about 1 1/2 hour, 
So far this month I haven't done any progress at all, and 2/3 of the month are left. Let's plan to do only 3 quality hours of reading, with the same goals as last month otherwise. This time I am scheduling the reading time in advance.

Monday, February 3, 2014

Reading plan: February 1 checkin

This is my February 1 checkin following my Books I plan to read in 2014 post.

January was a short month as I posted my resolution on January 20 only.

The good news is that I have finished The Organ from its Invention in the Hellenistic Period to the end of the Thirteenth Century by Jean Perrot. This has kept me busy (or in the back of my head) for about 4 months! I have pretty complete reading notes.

While technically “reading the book” is done, I would like to write a synthesis of what I have learned.

So my goals for February are:

  • write that synthesis
  • pick the next book to read and start in February

I am shooting for 10 serious reading days this month, for a total of 5 hours.