1. 8
  1.  

  2. 2

    Submitted primarily because of the parts about Inform 7’s approach to language design.

    1. 2

      Oh, this is brilliant. Amazing way to frame the explanation of Inform 7’s virtues. I am personally a huge fan of I7, and I think its success in the years since this was written makes a strong case that there’s something to all this.

      1. 2

        Oh, wait - the article was written this month. The game was written in 2008. Got it. :)

      2. 2

        This part:

        Another email correspondence with Andrew Plotkin, author of So Far and other Inform 6 hits, convinced Nelson that the primary unit of an IF language should really be its rules, not its objects. If a certain especially heavy object would cause the aforementioned sack to burst immediately, an Inform 6 author would have to decide whether to attach the exception code to the sack or the weighty object. In Inform 7, it would just become a few more declarations and rules, which could appear anywhere in the code

        Immediately made me think of this previous lobste.rs submission: Wizards and warriors, part five

        It’s almost exactly the same example given to illustrate the same design principle.

        1. 2

          It reminds me a bit of how in CLOS methods of generic functions do not hang off of an object but can be specialised on multiple of their arguments.

          I don’t always needs multimethods, but when I do and I am using a language without them, I really regret it, as the workarounds tend to be inelegant and unidiomatic.

          1. 2

            Interesting! Someone commented on the other submission about multiple dispatch too. Part 4 of that series is about multiple dispatch and why it doesn’t really solve the problem here.

            (Also interesting: I just re-read Part 5 and realized that the author ends by talking about Inform 7, I had forgotten that entirely.)