I am not a civil engineer, I am an astrophysicist who incidentally has
been involved in, and ran, software development projects oriented to
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. 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 am a strong devotee of Oberon because its module and public interface
concept is one of the most ideal for designing and implementing add-on
frameworks; and Oberon/F is the first Oberon "system" heavily using upon
that concept.
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.
Along the way I have learned that, as many are saying indirectly, you cannot
avoid using the full power of the modules that incorporate the MVC model for
text if you want to have any significant interactivity with the various
views of text, graphics, or whatever. Whether there is an intermediate
level between what Oberon/F provides and the level people are familar
with in the old "serial action" paradigm, is unclear. We are experimenting
with some trial versions of this to see what we think might work.
In the meantime, we have done our own ASCII (and other format)
I/O modules for text, images, etc. We also do not yet like them enough
to put them into the public domain. I believe this is what most people
are doing. In the regular Oberon world, viewed from comp.lang.oberon,
there are people like Wojtek Skulski (who works in physics) arguing for,
and supplying himself, modules with simpler interfaces for non-CS people.
He also is heavily criticized for giving up the "power" of available
modules. When he put out his "B2" system, which is a good step in the
right direction, it was criticized as being too simple. In practice it
was designed for a different purpose and a different programming approach.
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.
Bob Hjellming
Robert M. Hjellming | Internet: rhjellmi@nrao.edu | __
National Radio Astronomy Observatory | http://www.nrao.edu/~rhjellmi| \/ o\
P.O. Box O (US Mail only) | | /\__/
1003 Lopezville Road (UPS,FedEx. only)| Telephone: 505-835-7273 |
Socorro, NM 87801-0387 USA | FAX: 505-835-7027 | AMDG