Here are a few things that have kept my interest lately:
if (button(id, x, y)) buttonWasPressed();, and that’s the entirety of rendering a button widget to the screen and handling click events on it. (In most cases, the widget functions return a boolean of whether the button was pressed, text field was changed, etc.) There are no callbacks or separate bindings. You maintain a tiny bit of global state that helps coordinate all the action. The upside is you have total control over your UI’s appearance and behavior. The downside is, you have to implement all of your UI’s appearance and behavior yourself. My feeling so far is that it is not something you would do if you were just implementing a typical UI in a web browswer, because you have all the browser’s widgets already at your disposal (not to mention HTML and CSS layout). You’d be reinventing the wheel. But it seems an ideal approach for a game UI (which is where I believe the idea originated, in the game development world), on platforms where you don’t already have a core UI or widget library available, in a native mobile application where performance is paramount, or any kind of custom application, even on the web, where you want or need complete over the UI, because, for instance, the supplied browser form elements don’t suffice. For example, immediate-mode GUI would fit something like Soundslice’s custom interface perfectly. (via)
(x) => x + 1instead of
GopherCon talks It says something about the Go community how uniformly excellent and entertaining these talks are. Interesting and dense with practical knowledge.
I also recently tried to teach myself Acme. You can certainly glimpse the power of a system like that. But ultimately I decided editing speed is more important to me, and I’m pretty fast in Vim, so I abandoned the effort.
CoreOS seems like it could become pretty important.
Programming a computer, still a fun thing to do.