[Grace-core] The next steps -- Gracefully

[Kim Bruce]

Now that the semester has been winding down, I've been thinking about what I'd like out priorities to be for Grace over the next 9 months.  The driving force behind my thoughts has been that I expect to be teaching Grace again next fall and want to run a careful study against our Java-based intro -- and of course I want us to come out ahead!  Here are my thoughts.  I expect everyone will have slightly different thoughts, so look forward to a good discussion over the next several weeks.

1.  Settle on a code base for a compiler/interpreter.  While Grace worked well this fall, the implementation and code development environment was shakier than we would normally like/expect.  (We of course knew this going into it.)  With lots of help, we made it through with no major disasters, but it always felt like we were on the edge (and we often were just hours before my lab).  Since Tim and Michael know the most about the current implementations, I'd like to suggest that they write a careful analysis of the possible platforms, weigh pros and cons, and make recommendations.  Because this will drive our development for the next year plus, I think it is very important that it be written and as complete as possible, with whatever details are necessary for the rest of us to understand and approve or choose the direction to go next.  

A key consideration should be how easy it is for others to contribute to the project.  This may involve a complete rewrite of the system from scratch or repurposing parts of exiting systems.  

While we don't need a high performance system, but obviously it needs to be fast enough to be able to compile a CS1-level program in under 15 seconds (faster is better), and the generated code should be fast enough to be able to support running simple animations of the sort I used in my class.  (Once the semester is over and I've finished all the grading, I'll organize all of my programs so they are easily available on the web.)  An important consideration is that it must be easy to install the software and run Grace programs.  That was a huge advantage of our current system.  I could see others being nearly as easy (e.g., an Eclipse plug-in generating JVML), but anything that involves a lot of tweaking at the systems level will not work at all.  Novice students need to be able to install it on their own computer with little or (ideally) no help.

2.  While the Grace editor on the web worked reasonably well, there are a number of improvements necessary to make it a good educational development environment.  These include better ways of organizing files from programs (e.g., folders), making it easier/more natural for students to save their work outside of the browser, better support for debugging (including inspecting objects when a program is stopped in mid-computation).  Of course we also need better error messages, but that is more of a compiler issue at this point.  There are lots of features we could emulate from environments like BlueJ, DrRacket, and even Eclipse.  A REPL feature, in particular, would be nice.  It's easy to add code to a file/module to test features, but it's even nicer if we could just type it into a window and have it run without modifying the main program.

3.  Get the static type system to work correctly.  This should support (constrained) type parameters as well as first-order types.  We don't need anything too exotic here, though I expect we will need a way of branding types in order to correctly support our built-in types like Number and String.  (The issue is if we define another class implementing Number, how do we get it to interact with our built-in implementations -- binary methods are the issue, of course.)  I prefer something as simple as possible for this, but we may need something more exotic.  Tim's forthcoming paper will address this.  There probably are simple, but clunky solutions (e.g., require the Number type to have a method returning one of our built-in numbers as the value), and it may be better to just use those, but I'm interested to see what Tim comes up with as this is likely to be a more general issue.

Obviously gradual typing is important in the long run, but I think less time-critical than getting these simpler systems nailed down.  Given the papers already out there on how to do this, I think getting the static typing completed will make the other parts relatively straight-forward (though a lot of work!).  


There are some other language-related things that need to be finalized as well (an official grammar!!!, definition of definitively static -- did we finish that?, etc.), and of course the language definition needs cleaning up and refinement.  I'd also love to see an implementation of threads available in the language.  However, the above list reflects my priorities in terms of teaching the material again in the fall.  If we are actually going to get people to use Grace, we need to make sure that we have an implementation that will make them want to experiment with the language.

There was a discussion this week on the SIGCSE mailing list on moving from C to Java (yes, some people still teach C first).  Where there was a lot of noise (and self-promotion of books), there were some interesting points made (see especially the post by Cay Horstmann).  You can find it at http://listserv.acm.org/SCRIPTS/WA-ACMLPX.CGI?A1=ind1412A&L=SIGCSE%2dmembers&X=9CC079A16D608C95C4#8
though you will have to register to get access (which is pretty straightforward).

Finally, I think we are getting far enough along in the language definition that each time we make a (tentative) decision, we need someone (the proponent?) to write down a complete description of the feature, why it was needed, and the pros and cons of this solution.  This should be understandable to someone who knows Grace, but has not been participating in e-mail exchanges.  (This is because often when we are discussing something the arguments are spread over multiple e-mails over multiple days, making it hard to keep track of where we are.)  We should then come back as a group to approve or revise it, and make sure that it gets incorporated into the language spec.

What do you think our priorities should be?  I'm sure I've skipped important pieces of the puzzle, but hopefully through everyone's contributions we can get a relatively clear set of priorities and a plan on moving forward.  We need to start thinking now about what is necessary in order to get other to use Grace.

Kim