Blurring the Line Between User and Programmer
Sometimes I wonder if the people of the 1960s (i.e the people who came up with lisp, multics, unix) had the right idea: to use a computer you should program it.There are many programs, each does a different thing, you program your final product by composing programs. Users of the final product are the programmers.<p>I found myself being frustrated recently at Lifx smart lights. I had wanted to put a slider widget on my home screen of my phone. There is no way to do that. The only way is for me to write my own program. I started work on it, then had to wade through ridiculous amounts of documentation on the lifx api site, android docs. I still haven&#x27;t finished it.<p>Consider on the other hand, if android were a massive lisp environment where every API is available in the global scope - think emacs - how easy would it be to program the things you want!<p>Now I use Lifx as an example and I appear to be bashing them. I am not. At least Lifx publishes their API for consumption. Another time I tried to pipe an app that generates white noise for sleep to another program (TL;DR I was too cheap to buy a Sonos), but alas no publicly accessible API. I had to hijack the BT stream to do something remotely useful to it.<p>You may think the solution is to get people to publish accessible APIs. I think that&#x27;s a band aid solution. The core issue is somehow programs have become less composable over time. Far from the original ideals. Programs become standalone products.<p>I think we as an industry made a wrong decision turning programs into products. We should have kept programs as programs - make them super composable, and then let the end user design their own products that fit them best.