Language is as language does: the first UI

What is the first UI that you encounter when you first approach your computer? If you’ve said your desktop, your screen saver, or your log-in screen, you’re wrong. As strange as this may sound, the first UI you encounter on a computer is the kernel API.

API’s, strange as it may sound, are the UI’s for power users. They are the things that the people who built your machine use to interface with the lowest levels to get what we think of as the UI (our pretty little desktops) to do anything. More important than a given process or program’s API, however, is the structure of a language itself.

Last month I posted a quote on language design and the more I dwell on it, the more I agree. Good language design, like good UI design, makes easiest that which is expected to be the most common and that which is supposed to be the best practice.

Java makes it really easy to make objects. It is almost trivial to create your own data object class (which is why there is an acronym, POJO). It is also very clear, through the different library implementations, that there is supposed to be a lot of interface dependent design. That is as expected: Gosling himself has more or less said that that was one of his goals. It becomes a good deal more annoying, for example, to do things like manipulate strings in the same way you find in ECMAScript and PHP.

PHP, on the other hand, makes it insanely easy to edit strings. With dynamic variables and simple string concatenation and parsing, it can almost be said that PHP encourages the creation of fast and dirty scripts. And, to be honest, I can’t say that I haven’t used it that way. Yes, I enjoy working in a well-built PHP framework — Symfony is one of the best frameworks out there, period (though Doctrine can be credited for a good portion of that) — but its true strength is and always has been the pure mutability of its Strings.

I could go on (and maybe one day I will outline all of my favorite features from my favorite languages, but not today), but I think that the idea is clear enough. The design of the language effects what is done with the language. What is done effects the API. The API effects the end user’s UI.

This entry was posted in Code theory, Languages, UI. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>