[squeak-dev] Re: Proposal: Project Pink Book

Casey Ransberger casey.obrien.r at gmail.com
Sun May 2 20:36:35 UTC 2010


There are commit messages. I expect most people to commit to Inbox (I am not
a Trunk developer, for example.) Just like with code, we have to hope that
core developers will read the diffs before they push something from the
Inbox to the Trunk.

And one can introduce code that breaks things without introducing an obvious
build breakage. It's a shame that natural language is so hard to write tests
for:)

I'm not saying I don't think a spell checker is a good idea. I'm saying that
I wouldn't block contributions of documentation because we don't have a
spell checker. In fact, I'd even go as far as saying that a spelling error
in an otherwise good comment where there previously had been none is still
an improvement.

Let me cut to the chase and then kill the thread:

If you feel so strongly that we should have an integrated spell checker, why
don't you implement or integrate one, and then push it to the Inbox? I would
*love* to be able to spell check things in Squeak.

I'm not going to implement one, because my spelling is generally pretty
good, and I'd rather spend my time on other things; e.g., writing class
comments.

On Sun, May 2, 2010 at 1:23 PM, Ian Trudel <ian.trudel at gmail.com> wrote:

> 2010/5/2 Casey Ransberger <casey.obrien.r at gmail.com>:
> > Quality in general is *always* better served by a proofreader than by
> > automatic spelling / grammar tools. This is part of why I want to do
> > documentation in the trunk: because the trunk model gives us
> > gatekeeping and peer review.
> >
> > If someone finds something in one of my commits which reduces the
> > quality of the docs, I'd treat that as build breakage, hamburger-hat
> > and all.
>
> Yes. Where are those proofreaders? The trunk breaks when someone screw
> up in the code. Will it break when documentation is screwed up? There
> is no safeguard as far as documentation is concerned. A spell checker
> is a safeguard.
>
> We have a great case study in term of documentation: our wiki. Anybody
> can edit pages and it's easy. It just won't happen. The result is
> underwhelming.
>
> >
> > If you want integrated spell checking, you're probably going to have
> > to do the development work yourself, as it doesn't seem to be a
> > priority to anyone else.
> >
> > One thing I keep learning with software is YAGNI.
> > http://c2.com/xp/YouArentGonnaNeedIt.html
>
> Can we have this on the main page of the Squeak website, please?!
> Beside the download links. "You Aren't Gonna Need It" [but] "Download
> Now!". :)
>
> Quote from the website:
>
> “Even if you're totally, totally, totally sure that you'll need a
> feature later on, don't implement it now. Usually, it'll turn out
> either a) you don't need it after all, or b) what you actually need is
> quite different from what you foresaw needing earlier. “
>
> Writing formal texts requires spell checking, whether it is automated
> or manually performed, which excludes a). You make it sounds like
> nobody ever use a hardcover dictionary or something. It's not going to
> be different later than now, as b) implies, because spell checking is
> not a new kind of feature; it is a widespread feature and every
> software that has it use it in a similar fashion. We already know the
> implications of a spell checker and it is not experimental in any way.
>
> Besides, we even have a spell checker with a list of suggestions when
> a method is not written properly. Don't you ever use it?!
>
> YAGNI makes sense in many instances but I believe this is one that it
> does NOT make sense. It seems to be used as a cognitive bias. It'd be
> much simpler if you'd just write “We're not going to have a spell
> checker, Ian. Give it up.” :)
>
> Ian.
> --
> http://mecenia.blogspot.com/
>
>
>
>


-- 
Casey Ransberger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100502/4577d8fb/attachment.htm


More information about the Squeak-dev mailing list