Just got around to watching Rich Hickey’s “Transducers” talk from StrangeLoop this year. It strikes me that the problem space he operates in is very different from the one I typically do working for Articulate..
Working on language design involves a lot of building a means of describing a problem or a domain. Most programming languages also need to be generic in their descriptive power so as to allow for a wide variety of use cases. This, I think, makes for a very challenging problem space to work within. Very beautiful and creative, but challenging space. However, during Hickey’s description of an incredibly powerful feature set more recently added to Clojure, he drops a line that shows a great similarity to his problem space and mine. Somewhat off-topic, Hickey says, to describe a graphic in his presentation:
Somebody who reviewed these slides for me said these [labels] should have been subscripts, but, like, computers are so hard to use, I couldn’t switch them in time.
This is a fascinating observation from a man who has spent the greater part of his life working on a very difficult part of computers: The means by which we turn human intent into computer-processable commands, or programming languages. If you listen to many of Hickey’s talks, he speaks so often of the need for good design, usually speaking in terms of languages and systems. If you think about it though, what we typically think of as user-interfaces in software — a button, a text input, a toggle switch, mirror the underlying language components used to build them. Graphical User Interfaces (GUIs) are also the means by which we turn human intent into computer-processable commands. It just happens to be at a very high level of abstraction.
As software professionals, we typically think of abstractions as ways of making programming easier for us: Higher level languages make simple work of more complex tasks in programming. This would be like going from C to Ruby. Ruby abstracts many of the concepts you have to worry about when working with C: Memory management, pointers, etc. GUIs are, in a way, higher-level interfaces to complex tasks, such as setting fields in a database, sending notifications to other systems, presenting information.
Programming languages are a user interface, one which most programmers can understand. A lot of thought by very smart people (like Hickey) goes into how these systems are structured and act. Many languages, like Clojure or Ruby, have very beautiful and expressive interfaces, making quick work of previously menial tasks.
Somehow, as Hickey “jokes”, these beautiful code interfaces fail to translate into similarly beautiful and efficient user interfaces for the higher-level users, for our stakeholders. Somewhere there is a disconnect that many people are starting to notice: We have far more computing power available to us and yet the changes in how we interact day-to-day with computers has not changed all that much. Where are the “leaps” in computing that we saw during the 70s and 80s? Why do the interfaces we have to all this computing power feel so old and so hard to use?
I don’t have an answer, but rather an encouragement in the form of Alan Kay on how to look for and work towards “leaps” again, vs. mere incremental change.
In the end, Hickey and I work within the same sphere of problems: How do we make computers easier for people to use? It’s simply a matter of the level of abstraction.
