Code as Literature?

January 30th, 2014

Peter Seibel’s blog post Code is not Literature has generated some discussion in our department. I certainly agree with a lot of what Peter writes — when I used to coordinate our final year design patterns course, students would present examples of patterns culled from the Interweb. (Google code search was great until it was switched off). Let’s just say even finding patterns clearly expressed in code was often a bit of a struggle. So I’m quite sympathetic to Peter’s point that “most real code” isn’t really worth reading.

On the other hand, I still like Richard Gabriel’s idea of the “Poetry of Programming”. Donald Knuth’s Tex and Metafont have been published as hardbacks; Kernighan & Plauger’s Software Tools & the John Lions’ Unix book as paperbacks. One of the things I like about Smalltalk and Self was the way the IDE made code easy to read, and that much of the system code had obviously been written to be read. Now Github & SourceForge mean there are millions of lines of code around that can be read anytime: but that still doesn’t make it literature.

I guess this is because literature doesn’t happen by accident. Most writing isn’t literature — this blog post, my university’s assessment handbook, company procedure handbooks or advertising brochures may be grammatically correct and be worth reading for the content they contain: but they aren’t worth reading just for the sake of it. So we shouldn’t be surprised that most of the code isn’t literature: it doesn’t need to be.

What’s this to do with Grace? Two things, I think. First, we hope that Grace is a good language not just for writing code day-to-day, but also for code that aspires to be literature. And second, we hope that at least some of the code we write in Grace, while it may not rise to literature’s exhaled state, will at least be worth reading.

Splash 2013 Grace Tutorial

October 31st, 2013

The link to the tutorial materials is here:

Grace in one page:

You should run Grace from here:

Grace is getting Smaller!

October 17th, 2013

In my last blog post, I told you that Grace was growing, and talked a little about GUnit. It’s also growing in other ways: a type checker is under development, and the Graphics libraries now run in the Javascript (Web -based) implementation, as well as in the C implementation.

But notice that all of these developments have been in the libraries. The core of the language has actually shrunk, in at least one way.

We took private fields out of objects.

Before you get too excited, and start calling us up and asking how we expect you to teach about encapsulation if objects can’t have private fields, let me tell you that Grace still does have confidential fields and methods. Confidential attributes are those that can be accessed by an object and by those objects that inherit from it, and confidential is the default for fields (as it is, for example, in Smalltalk).

As originally proposed, private was a bit odd, because it applied only to fields: there were no private methods. Private meant just that: accessible only to the object that contained it, and to no others. It added complexity: three levels of protection are certainly more to explain than two. Moreover, we realized, that because of Grace’s lexical scope, it didn’t really add any power. This is because the effect of a private field can be obtained by removing the field from the object entirely, and putting it in an enclosing scope.

The best way to illustrate this is with an example. Here is a simple one, inspired by a problem in Mark Miller’s dissertation. The problem is to create a counter, and two objects that access it: one object can be used only to increment the counter, and the other only to decrement it.

method counterPair {
    var counter:Number := 0
    def countUp = object {
        method inc { counter := counter + 1 }
        method value { counter }
    def countDown = object {
        method dec { counter := counter - 1 }
        method value { counter }
    object { method up { countUp }; method down { countDown } }

def c1 = counterPair
def c2 = counterPair
print "counter 1 has value {c1.up.value}"
print "counter 2 has value {c2.up.value}"
print "counter 1 has value {c1.up.value}"
print "counter 2 has value {c2.up.value}"

counterPair makes the two objects, one for incrementing and one for decrementing counter. Because we don’t have tuples built-in, counterPair returns an object with two attributes, up and down, which are the increment and decrement objects. The example code creates two counters, and the output shows that they are independent.

You can run this code yourself here.

The default protection for methods is public, because that is what one wants most of the time; a method can be made confidential by adding the “is confidential” annotation. The default protection for fields is confidential, but a field can be made readable, and, in the case of a variable field, writeable, with the is readable and is writable annotations. To the requestor, accessing a readable or writable field looks exactly like reading from or assigning to a variable, as it always has. So, the line of code above that constructs the result of counterPair could have been written

object { def up is readable = countUp; def down is readable = countDown }

in both cases the client object can request the up and down attributes of the newly-created object.

Grace at SPLASH last week of October

October 15th, 2013

The Grace team will be well represented at SPLASH in Indianapolis from October 27 to October 31.  The main Grace event will be a tutorial from 1:30 p.m. to 5 p.m. in the Discovery Room at the conference site, the Indianapolis Hyatt Regency.

Members of the Grace team will also be involved in other presentations.  Kim Bruce will be giving an invited talk on the history of the FOOL workshop at the FOOL workshop (of course) on Sunday at 1 p.m.  He will also be giving a CS colloquium talk on Grace at Indiana University the Friday after SPLASH.  James Noble will be taking the counterpoint position in a debate titled “Should Software Conferences Respect Software?” Tuesday at 1:30 p.m.  He will also be giving a tutorial on Agile Studies of Agile Methods Thursday morning from 10:30 to noon.  Andrew Black will be chairing the OOPSLA Thursday morning session on Distribution and Parallelism.    While Kim is giving his talk at Indiana U on Friday, Andrew will be giving a similar talk on Grace at Cornell.  Michael Homer and Tim Jones will also be attending the SPLASH meeting.

Feel free to track any of us down for a discussion of the current state of Grace.

Grace is growing!

September 23rd, 2013

You wouldn’t know it by reading this Blog, but this has been an active summer in Gracelang. In fact, we’ve been so busy coding and editing the specification — and having fun with Grace — that we haven’t posed anything here.

Amongst other things, I’ve been working on a usable, if simple, version of GUnit — the ubiquitous unit testing framework — for Grace. It basically does what xUnit does in any other language: it let’s you write a bunch of test methods that contain assertions, and then runs them all, notifying you only of errors and failures. Grace’s blocks and exception handling find their niche here. For example, here is a test for lists:

import "GUnit" as GU
import "collections" as coll
def aList = coll.aList

class aListTest.forMethod(m) {
    inherits GU.aTestCase.forMethod(m)

    def oneToFive = aList.with(1, 2, 3, 4, 5)
    def evens = aList.with(2, 4, 6, 8)
    def empty = aList.empty
    method testFirst {
        assert{empty.first} shouldRaise (coll.boundsError)
        assert(evens.first) shouldBe (2)
        assert(oneToFive.first) shouldBe (1)

def listTests = GU.aTestSuite.fromTestMethodsInClass(aListTest)

The boilerplate is pretty standard for any xUnit. The only thing that needs explanation is the inherits clause: as in most implementations of xUnit, tests must be methods of a class that inherits from a framework class, which in Grace is called aTestCase.

Anyway, the nice thing is the first assertion:

assert{empty.first} shouldRaise (coll.boundsError)

Notice that the first argument is a block: it is evaluated as part of the action of the assert method, which enables the assert method to trap any exception that is raised.
So we are able to test that asking for the first element of an empty list does indeed raise the right exception — and then go on to run more tests.

The above code, when run, outputs:

1 run, 0 failed, 0 errors

and nothing else: passing tests are quiet.

If you would like to see all of the code, just drop us an email, and we will give you access to our subversion repository.