[ANSI-Smalltalk] Writing the standard in Smalltalk [long]

Martin McClure martin.mcclure at gemstone.com
Mon Nov 26 04:15:37 GMT 2007


Bruce Badger wrote:
> Martin,
> 
> This is all exciting stuff.  It's great that you have taken the time
> to put all this together.  I think your system is a very interesting
> option.
> 
> You mentioned a few properties of your system.  Something that I think
> is very important, and which should be on your list, is the ability to
> see who changed what and when.  The current wiki does this by
> requiring every editor to have an account and then providing a diff
> tool for looking at deltas.  In your system are you leaving this to
> Monticello?  If so I think we would need to understand how that could
> allow a non-coder to see the source and the deltas through a browser.

In this respect, Monticello is quite similar to the wiki. You have to 
have an account to save to it, everyone can see who changed it and when, 
and there is a diff tool that shows exactly what was changed. Actually 
browsing code and diffs is usually done from within Squeak, rather than 
in a web browser, but I wouldn't think that would slow this group down 
much. I know there are also web interfaces that allow browsing code; 
I'll try to find out whether there are ones for browsing diffs.

> 
> I see that one of your goals is to make the output from your system as
> much like the current standard document as possible.  In the sort term
> I think this is indeed what we need (because we know that the current
> standard text, for all it's faults, is acceptable to ANSI), but is the
> current form really what we need or want  for the medium and long
> term?

Exactly. Looking like the existing standard was the *initial* 
proof-of-concept goal. One of the beauties of specifying the standard in 
objects, not text, is that you can take the same objects and transform 
them to other forms in many ways.

> 
> I had imagined that for the very first iteration of the standard we
> would keep things as simple as possible and go for as many of the
> "easy wins" as we could.  If we adopt of your system right now, surely
> we have just placed something very significant and very new right on
> the critical path - nothing can pass until your system is able to
> produce something acceptable to ANSI and no work can proceed until
> your system can support that work.

As you pointed out above, ANSI-Framework currently produces the format 
of the current ANSI standard, which is demonstrably acceptable to ANSI. 
So it already meets this requirement after only a few days' work. Since 
our first public review is scheduled for 15 months from now, I think 
we'll have adequate time to make any necessary or desired tweaks to the 
output format. If we were to enter the detailed text into the wiki, it 
would be much more difficult to change the output to a different format 
if we wanted or needed to.

> 
> I have no questions about the functionality of the system you have
> described in your message.  It all looks really good to me. 

Thanks!

> I do
> question your urging people to use this right now.
> 
> Would it not be better to work on your system and work on getting
> agreement from ANSI on a better format for the document in parallel
> with getting a first iteration of the standard (with those easy wins)
> out?

I should have made clear that I think the mailing list and the wiki are 
valuable, and I think they should be used for the rough overall form of 
proposals, such as the ones currently on the wiki (like "Filesystem: VA 
Smalltalk"). Even for the next level of detail (like "here's the link to 
the VA documentation, and these are roughly the classes I'm talking 
about") the wiki is the best place. It's when we get down to the 
detailed level of exactly which methods should go in the standard and 
how their behavior should be described that a wiki really starts to be 
inadequate.

Even for detailed specifications, the wiki does have some advantages 
over the framework. The principal one seems to be familiarity -- we're 
all used to wikis by now, whereas this framework is new. However, a wiki 
(and text itself) is not that well suited to specifying or reasoning 
about something with complex internal relationships, like Smalltalk.

The framework is intended to save us time and energy. We all have other 
responsibilities besides being on this committee, and we want to get as 
much done here as possible. I think now is the perfect time to start 
using this framework. At this point, we have *no* detailed proposals for 
changing the standard. We will, I hope, start generating these soon, but 
I doubt they'll initially come in a big flood. Using ANSI-framework to 
specify the first detailed proposals will give us feedback on its good 
and bad points, and will give us a chance to address the bad points. If 
the early experiences are too bad, we can always abandon it and go to 
the wiki, or some other system. It should be quite easy to make the 
framework generate wiki markup, whereas going the other direction, 
though not overly difficult, would most likely be repetitive manual labor.

I don't think this framework is anything to be afraid of. It's quite 
simple and straightforward. I encourage all interested parties to load 
it up, look at the code, play with it, and see what you think after 
getting over the "well, that's different" reaction. I look forward to 
your suggestions for improvements (or, of course, the improved code itself).

Regards,

-Martin



More information about the ANSI-Smalltalk mailing list