Re: ASCII text file I/O module (fwd)

Eric W. Nikitin (enikitin@apk.net)
Fri, 30 Aug 1996 13:42:42 -0400 (EDT)

Hi :)

First of all, let me thank Vinicius. This is the most activity we've
ever had on this mailing list :)

> use by scientists and engineers. I think the essential point in
> the recent debate between Vinicius and others is that software is
> more useable if it give the user what they want. ASCII I/O modules
> are a case in point. A simple module interface,
> that perhaps gives upon on power for the sake of simplicity, is what some
> people want.

I think the mailinglist/newsgroup forums are extremely easily prone to
misunderstandings occuring during discussions. I would hope that
everyone here would agree that software designers should "give the
user what they want". If I implied otherwise somewhere, then I'm
sorry.

The problem is figuring out how to satisfy the most users... when
Vinicius says things about "Oberon/F doing it wrong" or how Oberon
has "failed", it tends to raise ire. I assume that is not his intention,
but that is what seems to be occuring.

> Including me if I am preparing a package for general use by
> scientists or engineers. However, for those for whom the power
> of the lower level modules is important, as it is for anyone making full use
> of the MVC paradigm on which the interactive aspects of Oberon/F is based,
> simple interface modules are not enough.

I agree. Part of the attraction of Oberon/F is being able to extend the
existing system. That seems to have been a primary focus. It still has
very weak "user level" interfaces... and beginner's documentation. It is
improving, and yes *suggestions* should be offered.

But there is nothing more frustrating to developers than to hear "ObxAscii
is *bad*". That is *not* a suggestion.

Users don't need to code modules. But they need to say what exactly they
want. Why is ObxAscii bad? What is wrong with it? What else does it need?

> IMHO all sides in this discussion are right, but they are addressing
> different needs. Vinicius is completely correct: Oberon/F is still lacking
> a number of things that should be added: a wider variety of ASCII (and other
> format) I/O modules, graphics, etc., at the level that engineers and
> scientists can use without learning more about the innards than they
> are interested in. I and a collegue have been working on this, but are
> not yet at the point where we want to put any of it into the public domain.

No one ever said Oberon/F was perfect. Or that Oberon-2 was perfect. There
*needs* to be discussions about what needs to be done. But as I said, in
this forum, we need to be very careful that discussions don't devolve into
arguments.

> In the end though, it is certainly true that words are not sufficient to
> converge to useful agreement on what is good for different purposes. It
> would be wise to make design suggestions. In the Oberon world to show
> portions of the public interface of a module that accomplishs what one
> wants is most ideal. This is what Vinicius and other should do, so we
> can have a concrete and constructive discussion. For those into OO design,
> various design diagram are very useful, but we are still lacking a good
> notation for describing framework design as a superstructure of "class"
> design. What I believe Vinicius is really talking about is an added framework
> (set of modules) that has exactly the public interface that he would like.
> In this forum it means expressing the public interface that is design for
> a set of modules used for a specfic purpose. I hope we can have more
> and more concrete discussion like this. If I can get a few things out
> of the way in the next couple of weeks, I will start putting some of my/our
> ideas in this form for this forum.
>

The above is exactly why this mailing list was established :)

Eric