Re: SmartEiffel shortcomings?

On Wed, Jul 13, 2005 at 04:42:23PM +0200, Wolfgang Jansen wrote:
> [email protected] wrote:
> 
> >>(OK, it's a user's point of view and not so important.)
> >>   
> >>
> >
> >Wolfgang, please keep cool.
> >
> >Philippe tried to explain our point of view. You may disagree but please 
> > 
> >
> >don't be so sarcastic, your mails start to look like one L.S.'s and I 
> >would have no choice but stop reading them too... (big, big grin!)
> >
> > 
> >
> Philip does consequently not answer to questions or arguments.
> It is hard to send mails forth and back without becoming sarcastic.
> 
> Yes, I disagree: a published software (or book, ...) is devoted
> to the users, not to the developers, it has to be written from
> the potential user's point of view. Well, it may happen that parts
> are not yet clear and have been published just for discussion.
> But those parts have to be indicated leaving no doubts, otherwise
> their purpose will be misunderstood. I remember that the
> last Beta explicitly offered class STORABLE (the current
> "What's new" page is less explicit but still misleading).
> By what means can a reader of the announcement detect
> that the class (and related things like the tutorial) is for
> discussion only? It is a cheap argument to declare weeks or
> months later that a specific feature was there for discussion
> but not for use (and people arguing this way cannot
> be considered for serious).

I see the nature of the conflict, and how it could perhaps have been
avoided.

Yes.  Published software has to be devoted to the users.  And when
software is designed, written, and tested by a closed group that is
a very valid requirement.

Why does this differ?  Because free software has a different
development model.  Every stage in the development is (or should
be) open to the public to comment on and provide early feedback
to the developers.  Publishing the so-called "tutorials"
is part of this process, and public response to them is an
essential part of development.

What is unfortunate is that they were published in such a way
as to mislead Wolfgang into thinking that they were tutorials
that would teach him how to use a currently working system.
They were not.

Perhaps they should be clearly labelled as unimplemented plans
intended to elicit public comment.
> 
> >Don't worry: tutorial examples will work eventually. Should we put a big 
> >warning in each not-yet-implemented class? I'd rather put a big warning in 
> >each beta release: "not for the faint of the heart" ;-)
> >
> Not a warning that Betas may not work here or there.
> But an indication that new features are not for use but
> for discussion (if this is the intention). See above.

And specify which things are still for discussion, which things are
intended to work (but may still need debugging), and which thing
are already known to work.

And, just as a point of terminology, I thing the original
concept of alpha and beta testing was that beta testing was
supposed to be of a system the developers thought worked.
Before that was the alpha-test stage, which was supposed
to provide proof of concept, with specifications still
subject to change.  Possible major change.

Perhaps the classes shoule be labelled as being in alpha-test stage,
beta-test stage, or production, depending on where they are.

-- hendrik

> 
> >STORABLE is a big thing. You know that. That's why we wanted to test the 
> >interface before developping it. So, our question is and remains, do you 
> >have any comments about our interface? Of course the classes don't 
> >compile, but do you feel at ease with how the source looks and feels? 

Call it an alpha-test stage.

> > 
> >
> Of course, I except that classes compile after publishing.

And maybe that expectation won't exist.

--hendrik

> Once more, see above.
> For the first time, I get an idea what you expect that I should do.
> Can you be more explicit?
> 
> >Note that you now have all the tools to help us.
> > 
> >
> And I do not understand one of them.
> 
> WJ
>