Archive for April 2, 2015

Thursday, April 2, 2015

Unintended Consequences of Usability Improvements

Matt Henderson:

I’m never quite sure myself whether I actually turned the lights off or not. And so, inevitably, I end up delaying my departure from the vehicle for the 30 seconds or so it takes to confirm that the lights are actually off. (And you can imagine that bystanders find that—a guy staring at his car, with its lights on—equally odd.)


The Toyota has a key-less entry system such that if I’m simply in proximity of the car, and in possession of the key, the doors will automatically unlock if I attempt to open them. While nice, it makes confirming that the doors are locked a bit difficult.

WiFi Signal 3.3.1

WiFi Signal (App Store, via Bradley Chambers):

WiFi Signal is a system menu bar application that provides easy access to your Wi-Fi connection details, monitors the signal quality of your wireless network, and can find and recommend alternative channels for your network thus avoiding signal overlapping and channel conflicts that can result in connectivity issues and performance degradation.

It shows that my 5 GHz network has poor signal quality, with 3/5 bars vs. 5/5 in Apple’s menu bar icon. However, it has a better data rate than the regular network, which has good signal quality. It could not find a better channel to recommend.

Custom Swift Switch Matchers

Joshua Emmons:

Wouldn’t it be great if we could teach switch new matchers that knew how to deal with our custom objects? Believe it or not, there’s an operator for that.

It’s called the pattern match operator, sometimes known by its (less googleable) syntax: ~=. And switch statements use it behind the scenes to compare values to their cases’ matching patterns.


This is yet another example of Swift employing polymorphism in an unexpected way to make the type system do work for us. Work that results in very clean, concise, and — dare I say it — declarative code.

Semaphores are Surprisingly Versatile

Jeff Preshing (via Jean-Francois Roy):

I used to think semaphores were strange and old-fashioned. They were invented by Edsger Dijkstra back in the early 1960s, before anyone had done much multithreaded programming, or much programming at all, for that matter. I knew that a semaphore could keep track of available units of a resource, or function as a clunky kind of mutex, but that seemed to be about it.

My opinion changed once I realized that, using only semaphores and atomic operations, it’s possible to implement all of the following primitives[…]

Not only that, but these implementations share some desirable properties. They’re lightweight, in the sense that some operations happen entirely in userspace, and they can (optionally) spin for a short period before sleeping in the kernel.


With all of these applications, semaphores are more general-purpose than I originally thought – and this wasn’t even a complete list. So why are semaphores absent from the standard C++11 library? For the same reason they’re absent from Boost: a preference for mutexes and condition variables. From the library maintainers’ point of view, conventional semaphore techniques are just too error prone.

The Death of Optimizing Compilers

Daniel J. Bernstein (tweet):

Have compilers become so smart that they automatically turn clean high-level code for these hot spots into optimized code, removing the need for humans to be optimization experts? The reality, unfortunately, is very much the opposite: general-purpose “optimizing” compilers are falling farther and farther behind the actual capabilities of modern processors.

This tutorial is an introduction to (1) what current and near-future processors are capable of; (2) how modern high-speed software libraries actually work; and (3) the increasing dominance of domain-specific tools to engineer high-speed software.

Hopefully the full talk will be available after ETAPS 2015.