I’ve been fascinated for a little while by the programming language called Inform 7. (Note as of writing, the main website is under maintenance, so here is the Inform Wikipedia article as backup.) It is a language designed specifically for crafting works of interactive fiction (aka “text adventures”). Version 7’s syntax in particular is based on natural language, and as a result, source code for games written in Inform are often quite intelligible to those not well versed in programming or the Inform language specifically.

Here is an example of defining mutually exclusive properties…

1
2
3

A thing can be lit or unlit.
A person can be slumbering or wakeful.
A person is usually wakeful.

Here’s an interesting predicate “instead” which provides an override kind of like aspect oriented programming…

1
2

Instead of doing something to a slumbering wyvern,
say "Best let sleeping wyverns lie."

Here’s a simple rule that changes the lit/unlit based on light source…

1
2

Every turn: if the player is not affected by light,
now the player is unlit.

A before advice to guard saving the game when not in a safe place…

1
2
3
4
5
6

Check saving the game: if the location is not the
Sanctum Sanctorum and the location is not the
Temple of Peace, say "(The game can only be saved
when in an indisputably safe place. This is not
that place. You will know it when you find it.)"
instead.

Here’s an after advice to modify the display of a character based on their state of being in a web or not…

1
2

After printing the name of a person who is affected
by web when we are looking, say " (webbed)".

Sometimes the emphasis on natural language becomes a little contorted though when writing procedural code…

1
2
3
4
5
6
7
8

This is the exorcise undead removal rule:
    repeat with turned one running through
    the undead people in the location
    begin;
        remove the turned one from play;
        award the permanent strength
        of the turned one points;
    end repeat.

Anyways just found this kind of interesting/inspirational and wanted to share.

An evented programming model (as seen Ruby’s EventMachine and in Node.js) makes the management of asynchronous continuations and event chaining a visibile and central idea for the application developer. While these concepts are important to the understanding of the low-level implementation of an evented system, they are often not important in the context of the problem domain an application is addressing.

How might we get much or all of the performance and parallelism benefit of an evented system without letting callback-chain management and explicit deferment invade our application code?

Lets take a really simple example of a logical expression: x and y.

We know that this expression resolves to true only when both x and y evaluate to true. If the evaluation of x and the evaluation of y are mutually exclusive and could be executed in parallel, then we’ll pretend our language does that. (This assumes that the logical operators in our language are not short-circuiting in this form, meaning we don’t intend to use them to guard right operand expressions from being evaluated prior to evaluation of left operand expressions.)

What’s neat then about the parallel evaluation of x and y is that at any point when either evaluation results in a false we can resolve the entire expression to false since the value of the remaining operand expression is functionally irrelevant.

If we combine eager-parallelism with lazy-evaluation, we could say that z = (x and y) and not even need to wait for the result of the evaluation of (x and y) before continuing on to the next line. We know that z is promised to be the result of the evaluation and that is enough.

Lets look at the implications of this in a simple web-server request. The following code lets just assume is Ruby but with the features described above, where expressions and assignments are promises and logical operators like and are’t short-circuiting:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

def serve_page(request)

  session = DB.lookup_session(request.session_id)
  user    = DB.lookup_user(session.user_id)
  page    = DB.lookup_page(request.params['page_id'])

  return deny_access! if
    page.restricted? and
    not page.readable_by?(user) and
    not user.administrator?

  render page

end

In the above example, we can initiate the DB.lookup_session call right away and continue on to the next line. In order to get the user we’ll need to wait for the result of the DB.lookup_session call to return, because the argument of DB.lookup_user needs the user_id from session, however we can assign user to be a promise for that expression and move on to the next line as well.

We can actually fire off DB.lookup_page right away because we already have the request object and its params, so in our VM we can imagine that DB.lookup_session and DB.lookup_page are going on in parallel right now.

We get to the return deny_access! if ... expression and we will essentially have to yield while we wait for something to come back. If we get page back first and we find out it is not restricted, then we can skip the rest of the expression as the and chain is going to resolve to false. Parallelism win!

Now lets say session comes back and the user promise evaluation moves to getting DB.lookup_user going based on session.user_id. If we happen to find out that user.administrator? is true we can also short-circuit the and chain.

While the short-circuit of the and chain doesn’t save us having to wait for page to come back before the render page calls That short-circuit could be valuable if it turns out that figuring out page.readable_by? requires further database calls to an access-control-list for example.

This special handling is a form of parallelism in that we are able to kick off the operation of any promised database query result while continuing on to the next expression and the next expression until we have a demand that has to be satisfied before continuing.

Want.

I’ve been pretty enamored of the “purely evented” approach of the Node.js framework. I remember the week that Ryah first announced Node, that it was going to have a really major impact on the way typical application developers would think about building network applications.

Having done a fair bit of it now and having read a lot of code in Javascript’s explicit continuation-passing style, I have to say there are some aesthetics of the style which can make things suboptimal from a readability standpoint.

1
2
3
4
5
6
7

store.getData(function (data) {
  store.getMoreData(data.id, function (more) {
    service.updateSomeData(more.id, function (update) {
      response.send(200, 'done.  update: '+update.code);
    })
  })
});

What if Javascript had a @= operator that macro-expanded the code to continuation-passing style under-the-covers, but would transform the nested syntax into the following:

1
2
3
4

var data   @= store.getData(@);
var more   @= store.getMoreData(data.id,@);
var update @= service.updateSomeData(more.id,@);
response.send(200, 'done.  update: '+update.code);

For this specific macro-expansion to work, the @ in the expression to the right of the @= operator denotes the place where the continuation function will be injected after the source is rewritten.

So basically within a { ... } any line using @= would treat following lines as code to embed in the callback.

1
2
3

var x = 1;
var data @= store.getData(@);
// REST-OF-CODE

1
2
3
4

var x = 1;
store.getData(function (data) {
  // REST-OF-CODE
})

But what if something goes wrong? Sometimes the async methods support error callback functions. How can we provide for these? What if the async functions yield multiple arguments instead of just the one?

Okay well I didn’t get that far. Just wanted to note this idea as a starting point. I’ll do that a lot on this blog.

Homogenous prefix notation is a reliable behavior and constraint of Lisp’s syntax, but is probably also one of the things that trips up most people when they are trying to read and make sense of long programs. Infix notation is a very natural form for defining collaboration between terms, whether it’s 1 + 1 or Alice and Bob.

I admit, my opinion of infix may possibly cultural-linguisitically biased as grammar in other languages could have adopted prefix action words before subject and object). Mechanistically however, infix operators have the advantage of not requiring an expression delimiter-set like ( ... ) to indicate expression completeness too.

In Ruby, the infix operators like +, * and << are all modeled as methods sent to the left operand with the right operand as argument. In practise this tends to work out okay most of the time, but without something like refine, it is not possible to define operators for use with DSLs unless you also define special objects for those DSLs, which can make embedding the DSL more cumbersome.

Having worked a lot with Cucumber in the past 2 years to define acceptance tests/executable features, I’ve grown accustomed to and am enjoying the flexibility in begin able to define a library of functions (Step Definitions) with somewhat arbitrary “anyfix” composition properties.

There are technical reasons why this is not easily applicable to typical general imperative programming language design, but apart from the typical “you’ll shoot your eye out” caveat, there are no essential concept violations by providing an “anyfix” expression signature capability for general programming.

Imagine for example a function definition such as:

1
2
3
4
5

function shoot(shooter, target, weapon) {
  ...
}

shoot(cowboy, alien, pistol);

…could instead be mapped as…

1
2
3
4
5
6
7

function (shooter) shoot at (target) with (weapon) {
  ...
}

(cowboy) shoot at (alien) with (pistol);
// or possibly sans-parentheses as...
cowboy shoot at alien with pistol;

A language with a feature like that could lead to some pretty sweet embedded DSLs. Just sayin’.

I am a huge fan of the Lisp family of languages, but I do not frequently write in any of them with the exception of cobbling together elisp code for some simple buffer manipulations in emacs or embedding quick and dirty domain specific languages to provide portable glue code for different systems.

If I were to identify the major reason why I don’t generally like working in lisp, it would be the way it reads. It’s not that the language lacks the abstractions or features that make it possible to encode concepts or develop rich domain specific languages etc. To the contrary, Lisp may provide the greatest freedom of all programming languges to build abstractions for those things. So why do I not embrace it?

The problem for me is that it does all of these things without providing inherent means to escape the alien and somewhat inhumane aesthetic of prefix notation and endless nesting parentheses. This is unfortunate, because there is nothing inherently wrong with the underlying data structures or expressions conceptually. It comes down to readability.

Here is an example of the well-known quicksort algorithm. In my opinion, even with the indentation, Lisp’s homogenous and nesting list structures sort of blend together without visually offering any advice as to the weight or meaning of the code.

1
2
3
4
5
6
7
8
9

(defun quicksort (alist)
  (if (null alist)
      nil
    (let* ((x (car alist))
           (xs (cdr alist))
           (fn (lambda (a) (< a x))))
      (append (quicksort (remove-if-not fn xs))
              (list x)
              (quicksort (remove-if fn xs))))))

Haskell is a language highly optimized for the expression of functions like quicksort, so its example reads more concisely and in so doing the behavior is somewhat more visibly apparent.

1
2
3
4

quicksort [] = []
quicksort (x:xs) = quicksort small ++ (x : quicksort large)
  where small = [y | y <- xs, y <= x]
        large = [y | y <- xs, y > x]

Compare with the same algorithm in Ruby, from which you can pick the imperatives of the code even more readily.

1
2
3
4
5
6

def quicksort(alist)
  return [] if alist.empty?
  x, *xs = alist
  less, more = xs.partition{|y| y < x}
  quicksort(less) + [x] + quicksort(more)
end

I bring this up about Lisp’s readability though, not to bash Lisp or compare it to other languages to show which is better but rather to simply demonstrate to what degree a language’s syntax and grammar can effect the speed of one’s ability to quickly understand the intent of code.

SQL is probably unparalleled in elegance in terms of being a domain specific language for performing arbitrary queries on relational databases. Implementing the same constructs in Ruby would seem a bit clunky. Consider this SQL that returns a list of users and the users who referrred them into the system:

1
2
3
4
5

SELECT u.id, u.name, r.id, r.name
FROM users as u
LEFT JOIN users as r
ON u.referred_by = r.id
WHERE u.email='john@smith.com';

In Ruby, if you wanted a simliar embedded DSL (excluding the fact you’d probably be using an ORM like ActiveRecord or Datamapper) you’d need to do something like this, just to get along with Ruby’s syntax options:

1
2
3
4

db.select("u.id", "u.name", "r.id", "r.name").
from("u" => "users", "r" => "users").
join(["u","r"] => {"u.referred_by" => "r.id"}).
where("u.email" => "john@smith.com")

And the above example’s syntax wouldn’t support a percentage point of the various constructs available in SQL. The point here is that Ruby is a very readable language for general purpose imperative programming, but that doesn’t mean it is the most readable language when applied to every single domain. This especially true when compared directly to a domain-specific language like SQL.

I titled this post “Dynamic Syntax” because I’ve been thinking about what it could mean for application development if it were trivial to define new application-specific languages and syntaxes as a regular part of the development process. If it were possible at runtime to manipulate and extend the parser to allow syntax forms applying to select sections of code modeling different aspects of the domain, would people embrace this kind of development?

In some ways it doesn’t seem that different from writing a bunch of class methods and declarative-style code except that the end result could be much more intention revealing if the language were mapped directly onto the problem space.

In terms of inspiration, I have really enjoyed reading the source code to Inform text adventures (like this one) for the natural-language feel to their structure. I think there’s a lot of potential lurking in programming languages that promote this level of readability.

On the train on the way to work lately I’ve been toying around with nodejs/coffee-script and pegjs to experiment with writing a language that allows its own parser and VM to be altered as it goes. I’ll post my findings soon.

I am curious if anyone out there has opinions on the idea of higher degree of flexibility in programming languages.

Sweet! It’s official. I nabbed a ticket (nay, won a ticket) to Rubyconf 2011 courtesy of a little contest on Twitter sponsored by CustomInk.

Here was my winning submission (though in their defense it was not chosen for being great design, but rather for simply being submitted…)

Thank you, CustomInk! I’m totally going to try and buy and wear some CustomInk gear at the conf.

Greetings, programs! Welcome to the new Usergenic website.

This is probably my 10th attempt at putting this site together, having tried various different blogging engines and services in the past and giving up on them at some point a few weeks later.

I’d probably used Wordpress about 3 of those times and basically gave up when the comment system completely filled up with spam. I’d also written a couple blog engines from scratch in Rails and Sinatra for Ruby and generally just didn’t find time to continue to build on or maintain them so I trashed them as I watched them age.

So I’m trying something a little different this time, using Octopress and just hosting my site with Github Pages. I think this will work for me this time because I generally prefer working my text editor with local files when I’m on my laptop. Also, I won’t have to worry about keeping services up on some box or dealing with databases etc, just to publish my site.

I’m compelled to start blogging again mostly because I want to participate more in the software community at large, whereas for the past few years I’ve been more or less cloistered with the development teams I’ve been working directly with at my day-jobs.

I am going to take the approach with the blog this time that its okay to post half-baked and incomplete ideas in the interest of getting conversations going, rather than just posting complete essays, reference articles and how-tos. I find that I’ve passed on putting out ideas when I didn’t have the time to fully flesh them out or dress them up and that means a lot of thoughts have gone unshared; no longer!

I don’t even have to finish this post.