Typographical Beauty in Programming Languages

When programming language aficionados talk about the “beauty” of a language, they are referring to several properties of the language. Most typically, this is how smoothly and easily its syntax supports the lucid expression of ideas. In addition, there is usually some mention of how “dense” it looks. In short,

if foo then
     B
else
     C

is much easier for a human to scan than, say, &#&A==>#BC or some other such nonsense. In short, it ought not to look like line noise. These kinds of beauty are not the ones that I am interested in here. I was goofing off and reading on set theory, in its many variations. When taking my abstract mathematics course (it had a different title, which escapes me; ironically, I do remember its numerical designation), I had no idea there were so many variants on set theory. For a computer geek, it is actually a rather pleasant read. Then again, I use abstractness and theoretical beauty (in computer science, mathematics, poetry, and literature) to purge out some of the filthy code I read in the course of the day, so my view cannot, perhaps, be trusted. As I was going through, I noted something: that mathematical notation is much more pleasant to read than code, typographically speaking. So, for example, this:

A right B
not A right B

Looks prettier, to me, than the standard if..then..else format we have had going for many years now and infinitely better than the C-family’s tertiary operator (A ? B : C). In addition,

The reason for the formats we have is obvious: languages are designed with a United States English keyboard in mind (I’m sorry, internationalists, but let’s be honest: there is a reason most languages will freak out if you insert an umlauted o in a symbol; is that good? No, but it is reality). Naturally, fishing through a key map looking for the unicode symbol for <>” title=”<>“/> would be a royal pain while coding. So that isn’t the symbol used. We have !=, \= (in Haskell), and <>, but not <img src=Fortress, a language I am looking at again for the first time since skimming an early draft of the spec in college, is the only one I know of that is headed in this direction. Fortress accomplishes this by comprehending both the unicode characters and some other ASCII variety (be it a word or alternate symbol).

Another bridge lies with the editors we all know and love. Unless you are one of the three people who use nano, pico, or notepad for day to day coding, your editor allows (and probably comes bundled with) a mode of some variety for most common languages. Even Visual Studio lets you write plugins that could fill this void. So you could create a language that only understands x = 42 right superPenguins(x) and not

x = 42 --> superPenguins(x)

, but create an editor for your language (call it Foo), that changes

x = 42 --> superPenguins(x)

to x = 42 right superPenguins(x) on the fly in a manner not unlike Visual Studio’s autocomplete. The danger for a language like Fortress (allowing both), is that you will pretty much get the ASCII art version, rather than the mathematical one. How is this a danger? Well, it isn’t in the strictest sense of the word, but it half defeats the purpose of putting the comprehension for Unicode symbols in there in the first place.

So, why do I mention all of this? Well, I have been knocking a toy language around in my head, and have been considering taking the approach I outlined above to give it a nice extra boost. Naturally, if this is the only thing that a language has to offer, it need not ever be created. I definitely have some other ideas though, as I indicated before, the language is meant more for the fun (both implementation and use) than it is as “the next Python” or, even, “the next Haskell” (capturing the minds of academia nuts everywhere). I think I’ll work on a preliminary spec and post accordingly.

In conclusion, I believe that a more beautiful approach to programming language is long overdue. With Unicode and “smart” editors becoming almost ubiquitous, there is no reason not to. Fortress is, I think, the first step in this direction and I, for one, look forward to seeing a great deal more of it in the future.

WebFaction

Well, I have MCS all moved over to WebFaction for a couple of weeks now and I must say that I am one happy customer. I have seen precious little criticism of them on the web and so I can’t say I’m really surprised. Most of what I did see was related to their spartan admin interface. Well, it is spartan but after GoDaddy’s ad and graphics laden trash that took two minutes to load on a fast connection, spartan is wonderful.

In addition, it is the only shared service I have used where I could actually compile software on the machine. I just finished installing hugs (http://haskell.org/hugs/) to my home directory so that I would have something to play with while on the go and it worked beautifully.

WebFaction: hosting by geeks is a wonderful thing.

Expressive PHP

When I first began using PHP I found it, like many other languages, annoyingly inexpressive. Once you have used Lisp, Haskell, and friends, it is often hard to go back (as Paul Graham observes in the early chapters of On Lisp). Over time, I have begun to discover ways, many of which are documented in the PHP manual, but not in common online tutorials (which are, I would guess, the most common way people learn the language) to use PHP in ways that are at least a little more powerful than the standard procedural spaghetti-code that is traditional in PHPland. This post is about those methods.

Note: This is for versions of PHP < 5.3 which should, if I understand correctly, add support for closures and lambdas.

First, pseudo-function passing. Interestingly enough, PHP has, for a long time, included a way to dynamically use or call functions in a way that is a mere shadow of lambdas and closures. Despite its limited scope and power, it is still better than nothing. You can dynamically call functions using the following syntax:

function foo($a)
  1. {
  2.      return strtoupper($a);
  3. }
  4.  
  5. function baaz($a)
  6. {
  7.      return strtolower($a);
  8. }
  9.  
  10. $bar = 'foo';
  11. echo $bar('t'); // will echo 'T'
  12. $bar = 'baaz');
  13. echo $bar('T'); // will echo 't'

Basically, PHP expands the variable into the name of the function before making a call. Again, these aren’t first class functions. We are not dynamically creating them or even really passing them. It is more akin to C++ macros (though not quite, as these expand at runtime rather than compiletime) than lambda functions. Interestingly, PHP does not stop there. This expansion can go several layers.

$a = 'foobar!';
  1. $b = 'a';
  2. echo $$b; // will echo 'foobar!'

In this sense, the ‘$’ sigil can almost be seen as ‘dereferencing’ things, after a fashion. The closest thing PHP has to “real” lambdas is, at present, the create_function function. It works by passing an argument list (as a string) and the function body (again, as a string) and returns a ‘reference’ to the function. This is, of course, more like the compiler hooks that some languages, like Lisp, offer than true lambdas with all-important closures.

Use arrays like lists. This one does end up feeding off the one above, but is good to mention nonetheless. I can’t say I like the choice of term PHP chose for their built-in sequence types. It isn’t an array in the C sense. It is actually a hashtable–almost. It would really be a hashtable if anything (including things like objects and functions) could be keys, but instead we are limited to strings and numbers. In practice, this is close enough. Unlike languages like C++ and Java, PHP is not statically typed. This is why we can use arrays as though they were simple sequence types. When we combine this with the function calls as above, we get something nice.

class Quuz
  1. {
  2.    public $something;
  3.  
  4.    public function __construct($a)
  5.    {
  6.          $this-&gt;something = $a;
  7.    }
  8.  
  9.    public function toString()
  10.    {
  11.         return (string)floatval($this-&gt;something / 2);
  12.    }
  13. }
  14.  
  15. function stringize($foo)
  16. {
  17.     if (is_object($foo))
  18.          return $foo-&gt;toString();
  19.     else
  20.          return (string)$foo;
  21. }
  22.  
  23. $a = array(0 =&gt; 'aa', 1 =&gt; new Quuz(1));
  24.  
  25. $b = array_map('stringize', $a);
  26. // $b will equal array(0 =&gt; 'aa', 1 =&gt; '0.5')

There is one kind of interesting problem I came across with this kind of thing before. You cannot use static methods in some versions of PHP.

In conclusion, it is a shame that bad spaghetti code is so much the norm in the world of PHP. I suppose it is largely a result of the very thing that made it popular: letting novices get up and running quickly. This is, of course, a noble goal. The problem arises when novices suffer stunted growth, remaining forever the script kiddie that unleashed 30,000 line behemoths to run a simple little web site. I hope this article helps ease the pain of stiff PHP for someone out there. In time, I expect this article to be completely obsolete. PHP, like Python, Ruby, and C#, is showing itself a member of a general trend. Namely, that today’s languages are starting to import the things we all know and love from the Lisp ecosystem (yeah, that’s my term for Lisp, Haskell, OCaml, Standard ML, Scheme, etc. ad nauseum) and make them available to the working programmer. In the meantime, this is how I ease the pain.