Don Norman once wrote an incredible book called The Design of Everyday Things. The book was originally going to be called "The Psychology of Everyday Things" but the title wasn't buzzy enough to market the book. The book isn't about slick visual design as you might initially think; it's actually a very thoughtful look at the way the objects around us make sense in our minds, how objects hint at how they are meant to be used, and how they convey (or encapsulate) information. This book is a must-read for anyone building tools, and is full of lessons for those of us who build software.

Anyway.

One particularly important part (page 183) speaks of the notion of "Explorable Systems". It's how we learn about appliances, televisions, a new stereo, or video games. We often push buttons and develop a mental model of the object's behavior by looking at it and the changes in state: lights turn on, certain things can be opened, or your character (in a game) moves a certain way. This is done really well nowadays when it comes to a lot of consumer software, but is done abysmally for what we use to make the darn stuff: code.

I ask you: think, for a moment, about how poorly programming languages facilitate Norman's three requirements lists for a system to be "explorable":

In each state of the system, the user must readily see and be able to do the allowable actions.
The effect of each action must be both visible and easy to interpret.
Actions should be without cost [...] readily reversible.

If you're a programmer and reading these, you probably just chuckled. The stuff you work with typically does none of these things, or very poorly.

Ever sit in front of a freshly opened IDE and wonder, what the fuck can I do with this? That's how I felt when I first ran the promising new Light Table. Before me was a blank canvas and I knew it was somehow powerful but I no idea what to do with it; I didn't see brushes, I didn't see paint, I hadn't the foggiest idea how to build a useful program with it. The system was invisible. I had to have all of it in my head. The object here (a language and compiler, hidden somewhere) conveyed zero information itself in the world.

What if we made code slightly more ... un-code? (And no, I don't mean some super heavy abstraction that totally nerfs your tool. Just a very light layer that lets you make the same old stuff but through a different interface than a raw text editor, where everything must be carried in your head. It would map very directly to real code, and still you'd have to think in terms of the real code, but it would guide you to write good code. Some working environment that is fully import/exportable with regular old code, but puts it into a form that is less tiring to manipulate) And still maintain the awesome underlying power of code? What if options can be laid out? What if the space were more explorable?

Why do I, a professional, need to look up, on a daily basis, trivial things in Google like the fact that LIs can have "list-style" of either "disc", "square", or "circle"?

Why do I have to read a fucking manual? Why can't the manual be baked into the product?