[Grace-core] The next steps -- Gracefully

[Andrew P Black]

Thanks Kim, for opening this discussion.  Here are some more thoughts for the fire, in rough order of priority.

A new implementation.  Yes, I agree that we need one.   Priorities for me are:
a student-friendly IDE — one that helps the student write programs, and test them.  This means an object viewer, a debugger, reasonably fast turn-aroud times (a few seconds, not minutes) and trivial to install.
a researcher-friendly IDE, which captures incorrect programs and their errors, so that we have a corpus for language improvement.
implements the language spec
getting other groups apart from us involved.
A story for module and dialect composition.  We don't have one, other than re-exporting each item by hand.
A story for object composition.  We don't have one, other than re-exporting each item by hand.
the above must give us a way of extending "built-in" objects like numbers and strings. 
Deciding what type parameters mean.  
Langue simplifications.  In particular, based on the six months that I've spent coding in Grace,  I would like to consider eliminating pattern matching and re-working inheritance, neither of which do I think I can explain to students as they currently exist.
A new implementation.  Yes, I agree that we need one.   Priorities for me are:
a student-friendly IDE — one that helps the student write programs, and test them.  This means an object viewer, a debugger, reasonably fast turn-aroud times (a few seconds, not minutes) and trivial to install.
a researcher-friendly IDE, which captures incorrect programs and their errors, so that we have a corpus for language improvement.
implements the language spec
getting other groups apart from us involved.
a clean and specified foreign-function interface, so that we can take advantage of existing libraries.  We clearly don't have the person-power to build everything from scratch. 
Designing the type system.  We should not kid ourselves that we have finished this!   Even the dynamic semantics of types are unclear; the strategy for moving from dynamic semantics to an efficient static checker is not at all worked out.  I agree with Kim that we should start by looking at the static subset, but I don't think that we can neglect the interactions with gradual typing, since that may affect some of our decisions.   I'm opposed to branding, until we have a convincing example of why we need it.  (And I don't see that Numbers are an example — yes, there are multiple implementations that need to co-exist, but since the type of the result of an arithmetic operation is not a static property of an expression, how can making the different implementations have different types help?   What we need to fix the Number problem is a better encapsulation system, where the multiple implementations of number all expose a common interchange interface that is not visible to clients.)
Finally, I think that our meeting have become quite unproductive of late.  We used to get quite a lot done, and be able to have open and frank discussions.  Lately that has been happening less and less often.   Perhaps this is because it gets harder to change things as the language spec is filled in, and decisions are more constrained, but I don't think that's all of it.  We may need to find other ways of making progress if we can't fix the meetings.

		Andrew

On 7 Dec 2014, at 14:29 , Kim Bruce <kim at cs.pomona.edu> wrote:

> 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
> 
> 
> 
> 
> _______________________________________________
> Grace-core mailing list
> Grace-core at cecs.pdx.edu
> https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20141207/e06aff29/attachment.html>