This post is a day late because I was exhausted last night and just conked out before writing anything. At least, that's the proximate cause. Digging deeper, though, the root cause is that I've been enjoying writing less recently. I've been attempting to take less time per post which, although useful for other reasons, has also made it easy to focus too much on the act of writing itself rather than the reason I'm doing it.
I had a long talk with a friend today who helped me remember why: it's because I like ideas and I want to share them. I've imposed arbitrary restrictions on top of that goal to make it more focused, achievable and manageable, but those should never become the goal itself. So I think the way to prevent this failure for next time is to stay focused on the true goal, and keep an eye on my enjoyment when writing, which seems to be a good proxy.
Plus I'm happier that way, which is nice.
In my recent dalliances with Brain Things I've finally had a chance to play around with array programming, a kind of programming where instead of just adding numbers, you can add vectors, arrays and even matrices. I was mostly using NumPy with a bit of GLSL at the end, and I have to say it's pretty nice.
I actually had to train myself out of my old ways of thinking; I kept wanting to take my big nested arrays and iterate over them, which led to a lot of ugly nested looping code. Later on when I figured out how to array properly, all of that code just disappeared and left me with disturbingly simple one-line mathematical expressions. Crazier still, that shorter and prettier code was also much, much faster.
Which got me thinking of a feature dear to my heart: streams. Streams are sequences much like arrays or vectors, with the difference that you can't necessarily access the whole sequence at once. They particularly suit communication-heavy applications like databases, web servers and, y'know, just about everything we make these days. That's not a coincidence; modern applications tend to be distributed and communicative by nature because they need to scale up and individual CPU cores aren't getting any faster. Streams are so useful that they're baked into Node in a more fundamental way than most other languages.
But I think maybe not fundamental enough. I'd like to see an implementation of streams baked into the language itself, so that operations for manipulating streams of numbers are as primitive as operations on numbers themselves. Imagine if you could add streams, multiply streams, filter streams, connect streams together – all with a simple syntax. And it could be more than a syntactical improvement: being able to describe the stream operations in a semantic way might yield some really cool performance improvements, such as doing stream operations in highly-optimised runtime code or even the kernel.
Being in JS-land for so long has made me forget how cool it is to have custom syntax for things that deserve it. Array programming is definitely a worthy addition to any language, and I think stream programming could be too.
Discomfort is an interesting thing. Unlike pain, which usually indicates something is wrong and needs immediate attention, discomfort is a much milder aversion. It says something like "hey, maybe this isn't such a great idea". I like to think I've gotten good mileage out of discomfort; if I'm doing something and it feels uncomfortable, usually that means I'm doing it the wrong way. Maybe I'm sitting wrong and it's making my back uncomfortable, or I've gotten the wrong idea and it makes my thinking uncomfortable, or I've made some bad design decision and it makes my work uncomfortable. I can use that signal to change or stop what I'm doing.
However, lately I've been reconsidering the value of discomfort as a signal, particularly in the cases where it informs your work and your thought. Discomfort could be a signal that you've made life too hard for yourself and you need to go back, or maybe it's just that the thing you're doing is essentially difficult. It would be easy to slip into a situation where you get used to easy problems and averse to hard, complex ones because you value comfort too highly. The Stoics actually speak about voluntary discomfort: the idea that you should deliberately experience discomfort to avoid getting too complacent. I'm starting to see the benefit in that approach.
It might even be that there is some optimum level of discomfort, where things are exactly as hard as they should be – but no harder. I don't know how exactly you'd find that level, but I'm sure it's not zero.
Someone was asking me today why it seems like software is easier to use than it was 10 years ago. There are obvious answers to do with the general improvement of the industry, software becoming more mainstream, and the design leadership of Apple, but I think there's an under-appreciated factor at play too: advertising.
In the traditional packaged-software market, you normally pay for the product once, and then pay some additional amount for upgrades. The problem with that is that it makes user satisfaction a fairly weak incentive. Bad design decisions only have a direct impact on sales in the next release cycle, which could be years away. Meanwhile you have to rely on indirect signals like user feedback, which isn't always useful. Loud voices are vastly overrepresented, and the noise makes it easy to miss feedback on more subtle problems.
However, many companies now are moving towards "cloud" offerings, where access to the software is paid by subscription. Although this still means the incentive is indirect, the feedback loops are much smaller. If you make some bad decision, sales will suffer almost instantly, making it easier to track down the cause. It still has the issue, though, that it's not always easy to figure out why. People will rarely say something like "I'm canceling my subscription because your text boxes are too small", you only find out that that's a problem when it's rolled up with 20 other problems as a more general "I don't feel like your product is easy to use."
Advertising-supported software products, however, are in a whole separate category. Because advertising is usually paid on a per-impression basis, you're incentivised by every single customer interaction with the product. If your text boxes are too small, you will be able to see an impact every time a user interacts with a text box. And because ad services often report on an hourly-or-sooner basis, you'll see it in real time. It makes sense in that context to micro-optimise every tiny interaction and each little detail.
You can see that attention to detail as being essential for good design. Steve Jobs was famously obsessed with small details at Apple, to the point of blatant micromanagement. However the results in terms of usability were spectacular, and far ahead of anyone else at the time. But it seems that micro-optimisation can be driven as much by systematic incentives as it can by megalomaniacal leaders driven by attention to detail.
Of course, there's no guarantee that the incentives in advertising will necessarily line up with the desires of the user. They often do, inasmuch as a user who isn't happy will stop using the product and therefore seeing the ads. But you can easily spot counter-examples where products with very little competition will run user-hostile ads or make bad design decisions despite the incentives. If you look at the long-term consequences of ignoring users, though, it seems to work out fairly badly for most software companies.
So perhaps ads are, at least in some ways, a force for good in software development. One thing's for certain: if you want the worst offenders in bad design, unresponsiveness to feedback, or just plain user-hostile decisions, you won't find it in ad-supported software despite its sometimes questionable reputation.
No, the worst of the worst is enterprise software, with the most distantly aligned incentives of all.
One area that I think is tragically underexplored is new kinds of performance that are made possible by the internet. The amazing power of broadcast-era technology all but killed theatre and live shows as entertainment for the masses, but these days we have enough technological power for new kinds of non-broadcast performance.
I'm most excited about the future of the current set of popular livestreaming services (Twitch, Ustream, YouTube, Livestreamer). Right now streaming is still fairly fringe, but it's made a popular niche for itself in video games and political protests. But as we get to a point where people think of streaming as non-chalantly as they do taking photos or videos on a modern smartphone, I think we'll start to see some truly novel forms of performance spring out of that.
I have a moderately interesting idea along those lines, which is to make a theatre show entirely set in Google Hangouts. Hangouts works much like a traditional stage: people enter, speak for some amount of time, and then exit. I think you could create a really compelling experience using the up-close intimacy of videoconferencing. Imagine Hamlet online: the angst, the confrontations, the intrigue - all conducted via video calls!
And the coolest thing is that you could do it all live. You would actually be watching the actors connect and disconnect from the call as it happens. And although it's a fairly timid step into the possibilities of online performance, it would really be something special to create a bit of that live theatre excitement online.