If Doorknobs Were Software

If we designed doorknobs the way we design software, each one would come with a user manual.

They wouldn’t be guaranteed to work. You could spend hundreds of dollars on a new doorknob, only to find the handle doesn’t turn, and the manufacturer doesn’t offer a warranty.

Your doorknob would have options for direction of turn, speed of opening, and click sound, but not shape or color.

Most doorknobs would be sold without locks. You could get a knob with a lock, but it would be $10,000.

Each door in your house would need a different doorknob, depending on what year it was built. Doors from 1994 would need completely different knobs than 1993 doors. Sometimes you’d be able to put a 1995 knob in a 1993 door, but not always.

Modern doorknobs — made only for modern doors — would understand some voice commands, like “What time is it?” and “When did you last close?” But only from one person in the house, and the commands for opening and shutting would be different depending on which knob you bought and which door you installed it in. Most of these voice doorknobs wouldn’t have handles, at all.

Some people would lay awake at night, wondering if our doorknobs were getting too smart, and would one day rise up and kill everyone.

Tubes by Andrew Blum

A nice, quick intro to the physical infrastructure of the internet. Doesn’t really go into how all those pieces work — there’s no discourse on the technology behind a router — but does build a mental image of the boxes, buildings, and people that keep the world connected.

Three things I learned:

  • ARPAnet’s first Internet Message Processing machine was installed at UCLA in 1969. The machines were manufactured on the East Coast, but only West Coast universities were open to the idea of the network at the time.
  • In 1998, The Netherlands passed two laws to pave the way for fiber everywhere. One law required landowners to give up right of way for holes to be dug, second law required any company digging a hole to lay fiber to also let other companies lay their own cable in the same hole and share the costs. The one-two punch made it cheaper and easier to lay fiber, and also blocked anyone getting a monopoly.
  • The busiest route in the world is between London and New York, with more internet traffic than any other line.

Seven More Languages in Seven Weeks: Elm

Between the move and the election and the holidays, took me a long time to finish this chapter.

But I’m glad I did, because Elm is — dare I say — fun?

The error messages are fantastic. The syntax feels like Haskell without being as obtuse.  Even the package management system just feels nice.

A sign of how much I liked working in Elm: the examples for Day Two and Three of the book were written for Elm 0.14, using a concept called signals. Unfortunately, signals were completely removed in Elm 0.17 (!). So to get the book examples working in Elm 0.18, I had to basically rebuild them. Which meant spending a lot of time with the (admittedly great) Elm tutorial and trial-and-erroring things until they worked again.

None of which I minded because, well, Elm is a great language to work in.

Here’s the results of my efforts:

And here’s what I learned:

Day One

  • haskell-inspired
  • elm-installer: damn, that was easy
  • it’s got a repl!
  • emacs mode also
  • types come back with all the values (expression results)
  • holy sh*t: “Maybe you forgot some parentheses? Or a comma?”
  • omg: “Hint: All elements should be the same type of value so that we can iterate through the list without running into unexpected values.”
  • type inferred: don’t have to explicitly declare the type of every variable
  • polymorphism via type classes
  • single-assignment, but the repl is a little looser
  • pipe syntax for if statement in book is gone in elm 0.17
  • case statement allows pattern matching
  • case statement needs the newlines, even in the repl (use `\`)
  • can build own complex data types (but not type classes)
  • case also needs indentation to work (especially if using result for assignment in the repl)
  • records: abstract types for people without beards
  • changing records: use `=` instead of `<-`: { blackQueen | color = White }
  • records look like they’re immutable now, when they weren’t before? code altering them in day one doesn’t work
  • parens around function calls are optional
  • infers types of function parameters
  • both left and right (!) function composition <| and |>
  • got map and filter based off the List type (?)
  • no special syntax for defining a function versus a regular variable, just set a name equal to the function body (with the function args before the equal sign)
  • head::tail pattern matching in function definition no longer works; elm is now stricter about requiring you to define all the possible inputs, including the empty list
  • elm is a curried language (!)
  • no reduce: foldr or foldl
  • have to paren the infix functions to use in foldr: List.foldr (*) 1 list
  • hard exercise seems to depend on elm being looser than it is; afaict, it won’t let you pass in a list of records with differing fields (type volation), nor will it let you try to access a field that isn’t there (another type violation)

Day Two

  • section is built around signals, which were removed in Elm 0.17 (!)
  • elm has actually deliberately moved away from FRP as a paradigm
  • looks like will need to completely rewrite the sample code for each one as we go…thankfully, there’s good examples in the elm docs (whew!)
  • [check gists for rewritten code]
  • module elm-lang/keyboard isn’t imported in the elm online editor by default anymore

Day Three

  • can fix the errors from loading Collage and Element into main by using toHtml method of the Collage object
  • elm-reactor will give you a hot-updated project listening on port 8000 (so, refresh web page of localhost:8000 and get updated view of what your project looks like)
  • error messages are very descriptive, can work through upgrading a project just by following along (and refreshing alot)
  • critical to getting game working: https://ohanhi.github.io/base-for-game-elm-017.html (multiple subscriptions)

The Shock of the Old by David Edgerton

An excellent antidote to the normal narratives of invention and progress.

But Edgerton isn’t a Luddite, or a cynic that doesn’t believe in progress. Instead, he sets out to fill in the stories that normally get glossed over in normal histories: the importance of horsepower to the modern armies of World War II, the communities in West Africa that have grown up specifically to maintain the cars and trucks they inherit from the developed world using local materials, the resurgence in whaling in the 1920s and 1930s driven by demand for whale oil to be used in margarine. It’s fascinating, incredibly readable, and it changed the way I read stories of technical progress and achievement.

Three facts in particular stood out to me:

  • India and Taiwan produce more bicycles each year than the entire world did in 1950.
  • In 2003, the largest R&D spenders weren’t in biotech or the internet; they were car companies: Ford, Daimler Chrysler, Toyota, etc.
  • The rickshaw, which I always assumed was an old tech lingering in the modern world, was in fact only invented in 1870, in Japan.