Why is UI design so hard?
This is a random brainstorm post. It probably won't make sense to you. Don't fret.
- The reason we need a language whose code is data is so that domain-specific languages don't all have different syntaxes - so that we can have common tools for making running code out of ad hoc languages.
- UIs are not best expressed either iteratively or visually. UIs are code, but they are more like prolog than python. The fact that we need constraint programming semantics to do UIs does not mean that every line of code we ever write ought to be expressed based on constraints, but it does mean that when we write a UI, we ought not to have to write it using iterative semantics.
- Data persistence doesn't map nicely to an SQL database, nor does it map nicely to a filesystem.
- An interchange standard is a foreign data API - a way to turn something coming in from the wire into an internal object, or a way to turn an internal object into something on the wire. The wire form of the data is probably not a good way to store it.
- Making programming units into linear text files is unnatural.
- A better language will be written in itself.
- Writing an entire program by typing linear text is like carving a statue by typing numbers into a robot that knows how to carve - it can be done, but if you don't have a physical model you are trying to duplicate, it's much less natural than just chipping away at the stone.
- Programs aren't statues - their state varies - so the statue metaphor will only get you so far. In order to easily work on a piece of code, you need visualization tools that will show it to you in a variety of different ways, and that allow you to easily switch between views so that you can easily form a mental model of what you are working on, even though it's a 4D object, not a 3D object.
- This is why programming by example, while it's better for UIs than programming by linear text, still isn't very good.
- The reason C/C++ is the lingua franca of the serious programming community is that there is a free toolchain.
- The reason languages like Python, Lisp and Scheme haven't taken the world by storm is because no implementation exists that is of similar quality to GCC and that can form a GCC-like ecosystem.
- The reason that languages like Perl and PHP and Ruby haven't taken the world by storm is that they are too domain-specific, have unnecessarily complex syntax, and the implementations are not of very good quality in comparison to GCC (which is not to say that they're not good - it's just a matter of degree).
- The reason Java hasn't taken the world by storm is that (1) historically it's been not-quite-open, which has limited the sort of fauna that can exist in its ecosystem and excluded some who are really quite necessary. And (2) it suffers from the linear file problem I mentioned earlier even worse than languages like C++ and Python do. But now it's open, and with the right tools it could actually take the world by storm. Importantly, there is a GCC story for the Java toolchain - what was missing was the rest of the system.
- A replacement for these languages that transcends their capability will have to have a GCC-like ecosystem in order to take the world by storm. What has prevented VHLL tools from succeeding in the past is that they are proprietary and domain-specific - a successful VHLL will have to have at least one implementation that produces good code and is open source and non-domain-specific. Languages like Lisp and Scheme would be a good basis for a language like this, because their code is data, but since there is no GCC-like ecosystem for either language, they can't currently serve as a basis for the VHLL I'm talking about. Nobody is going to make serious money on a VHLL unless they can figure out a way to make money on it that doesn't involve keeping it proprietary.
- Libraries used by a VHLL like this will have to integrate not only on the API level but also, to the extent that they are involved in presentation to the user, at the embedding level - like a web browser plugin.