[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