The beauty of ugliness

Since I and my colleagues are basically full-time programming language designer/implementers, we have a lot of discussion related to language design and aesthetics. I have always cared about the look and feel of a language and framework: does the code look pretty, is its syntax concise, clear and consistent, does it allow to nicely separate concerns. This is not the case for all of my colleagues, some are more interested in putting the functionality into the language than whether it’s pretty or “proper” or not.

Example. As part of WebDSL, we have a data-modeling language, i.e. a way to define your application’s entities and their relationships which are persisted to a database. We also have a query language (a subset of HQL), which works fine, but is sometimes a bit verbose. For instance, to retrieve a user with a certain e-mail address, you would have to write a query like select u from User as u where = ~email. A query like this always returns a list of results, of which you then have to check if the list has 1 element in it, and if so, pull that out as your User of choice. These things are so common that we wanted a quick way to to retrieve a single entity with a certain property. My colleague therefore extended the WebDSL compiler to automatically generate global (we don’t have namespaces) functions with the following naming scheme: findXbyY, where X is an entity and Y is a string (or compatible) property. So, in this case a findUserByEmail function would be generated, reducing the need for this code:

var results : List<User> := select u from User as where = ~email;
var u : User := null;
if(results.length == 1) {
u := results.get(0);


var u : User := findUserByEmail(email);

Clearly, this is an improvement in terms of reduction in code, however it also very much clutters our global namespace with functions that are “magically” created when you define new entities and properties. Although I have no alternative solution that’s much better, other than maybe using the User namespace to define the function on, e.g. User.findByEmail(email), my initial reaction was: yuck. It made an ugly, hacky impression on me.

But it works. People use and are happy with it. Ugly or not, it gets the job done. Maybe that’s really just enough. Maybe we (or rather: I) should not care about aesthetics so much.

Today I listened to a part of the keynote of a Dutch PHP conference (don’t worry, the keynote is in English) and I realized there are basically two choices here: attempt to design everything “correctly” without mistake, or try out new ideas and evolve them over time. I always assumed and hoped I could do the former, but of course, you can’t. In contrast, PHP is a rather extreme example of the latter. As a language it’s not pretty, but it’s practical. It works. And it’s being used. A lot. Don’t people care it’s ugly? It turns out they don’t. The people that work on PHP basically evolved with their language. They made some pretty simplistic assumptions in the beginning, which did not always turn out to be the best, but they worked and they got used. Up to a point, these old way of doing things, which most PHP available to users today (with some particularly horrible ideas removed), which makes PHP such an attractive language to beginning (web) programmers.

For instance, PHP was never an object-oriented language. OOP was added later. The result of this is that many features can be used in to different ways: either through an object interface, or through a function interface (example: mysqli_query). In practice, beginning programmers will likely first use the function call, and, once they start to appreciate object-oriented programming, can switch to object calls. Similarly, PHP never had exceptions, they were added only in PHP5. The result is that most built-in functions do not throw exceptions when things go wrong, they return -1, for instance. More modern functions allow you to choose the kind of error reporting that you like. PDO, for instance.

If you’re thinking: that’s awful, what a mess. You’re right. PHP is a mess. But a pretty powerful and accessible mess. There’s a lot of legacy there. A lot of bad decisions made, a lot of good. There’s something in it for everyone, from beginner to expert (PHP 5.3 has closures!).

It turns out what matters in the end is the ability to get things done in a language, not if you look pretty doing it. Programming language designers maybe should not be so afraid to design ugly, functional features.