Constructive art on software languages

If you (feel like you) need to explain a piece of art, then something sucks. But I am not saying that Haskell's Tower of Babel is true art. Perhaps it could be called constructive art (or nerdy art). Anyway, I am going to explain you how I constructed this picture. See here for the original twitpic with the tower, but it's included right below for your convenience.


















This is how you can reproduce the tower:
  • Use something like Mac OS's Keynote to actually assemble the picture.
  • Go through a nifty Haskell project and gather all Haskell 98 extensions.
  • Use one line per pragma and format everything with a proportional font as shown.
  • Sort the extensions (the lines) by the visual length. Results depend on the font chosen.
  • Starting at the bottom, adjust font size per line to get a smooth slide from top to bottom.
In my instance, there was some fuzzy effect due to the used proportional font and the tension between the upper case LANGUAGE and the camel-cased name of the extension in each line. Say, while I was generally trying to decrease font size as I was going from bottom to top, I had to actually increase it every now and then--if I wanted that smooth slide from top to bottom.

Background for non-Haskell nerds: In contemporary Haskell, programmers tend to express their dependence on non-standardized features by using detailed pragmas in their modules. For instance, if someone places the pragma for "FunctionalDependencies" in a module, then this means that class declarations are allowed to restrict multi-parameter type classes to model functions on types as opposed to general relations.

At some point, it just occurred to me how organized we Haskell programmers are and how much expressivity we have at avail. From a more historical point of view, we may just run into the kind of problem that is symbolized by the Tower of Babel, but honestly I don't feel like I am suffering from too much expressivity and too sexy types.

As a data point, the project from which I extracted the above language pragmas is a tutorial on type-level programming (joint work with Oleg Kiselyov). The first two lectures of this tutorial have been recorded and posted. I have presented that material for folks with pretty much no Haskell background. Several of the lectures (not those currently available online) require advanced background in typing and programming languages (also measured by the number of language pragmas shown), but the plan is ultimately to get this tutorial to the point that everyone with modest interest in language design and type systems can fully appreciate all that expressivity and sexy typing.

PF

Comments

  1. Anthony de Almeida LopesJanuary 20, 2010 at 10:20 AM

    It might be interesting if you made another one that was sorted based by the use count of each pragma in Hackage.

    ReplyDelete

Post a Comment

Popular posts from this blog

SWI-Prolog's Java Interface JPL

I would like to mix Java and Prolog code on a number of occasions. Together with a student of mine (Joachim Pehl), we just convinced ourselves that the JPL library of SWI-Prolog is really cool. Basically JPL allows you to call Prolog from Java and Java from Prolog. But the question is, of course, how easy is it and can you easily go back and forth . For instance, can we call Prolog from Java and call back Java from Prolog and share Java state throughout? Sure it works! PROLOG PORTION FOLLOWS % This library is all we need to call Java from Prolog :- ensure_loaded(library(jpl)). main :- % Create an object jpl_new(class([],['Test']), [], X), % Printing objects is like printing object ids write(X),nl, % Access a field of the object; happens to be static jpl_get(X, state, Y), % Prints whatever the state's value is write(Y),nl. JAVA PORTION FOLLOWS // This jar is all we need to call Prolog from Java import jpl.*; public class Test { public static int state = 0; ...
Read more

Lecture series on advanced (functional) programming concepts

[ Added 10 Aug 2010: Here is the link to the first lecture's video: " The Expression Problem ". ] If you are a programming nerd or something of a similar species, you may know of C9 Lectures at http://channel9.msdn.com/tags/C9+Lectures . Several of the lectures are given by Erik Meijer who has turned many chapters of Graham Hutton 's book " Programming in Haskell " into videos. In my recent, recorded lecture on " Programming Paradigms and Formal Semantics ", I also incorporated Graham's text, but you should really watch Erik's lectures, if you haven't---they are more fun. I am inspired by his ability to present relatively simple content in such a crisp, insightful, and enjoyable manner. In the aforementioned lecture, I covered all kinds of "crazy stuff" though, and in the end, I had to deliver body bags to my Bachelor students---in the form of a radically simple examination. Thanks a lot btw to @grammarware for helping with t...
Read more

Should I declare defeat on the research topic of API migration?

Of course, I won't, but perhaps I should! Then, I could turn to lower-hanging fruits in research, which I first need to spot, which I can't though because I am a bit obsessed with API migration (and admittedly some other stuff such as megamodeling ). Sigh! It was around 2004 that I became interested in API migration and I have talked about it here and there ever since. Perhaps I am thinking that talking about a difficult problem of interest helps in discovering the solution of the problem, or at least a sensible path to go. Wishful thinking so far! In theory , the objective of API migration made a lot of sense while I was on the XML team at Microsoft because there are obviously way too many XML APIs. In practice , nothing happened on this front because I didn't understand automated API migration well enough back then. Add to this that API migration is something that is potentially risky for the API provider and the API migrator . So you need to mash up a rocket scientist ...
Read more