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

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:

[pmath size=14]A right B[/pmath]
[pmath size=14]not A right B[/pmath]

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 [pmath size=14]<>[/pmath] would be a royal pain while coding. So that isn't the symbol used. We have !=, \= (in Haskell), and <>, but not [pmath size=14]<>[/pmath]. It is easier to type, but it sure isn't as pretty. One would almost expect a few more languages dipping into the vast resources of Unicode and smart editors, but this does not seem to be the case. The only language I have heard of to date to use non-standard symbols as a part of the language is 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 [pmath size=14]x = 42 right superPenguins(x)[/pmath] and not

x = 42 --> superPenguins(x)

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

x = 42 --> superPenguins(x)

to [pmath]x = 42 right superPenguins(x)[/pmath] 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.