I agree that Oberon needs a standard module library. I take exception to
your use of the word "failure". If you mean that Oberon has "failed" to
become as popular as C++, or that Oberon/F has "failed" to become as
popular as Visual Basic, then yes, I suppose it has failed...
But you are really arguing two things here...
1) Oberon-2 (the language) doesn't have a standard module library.
2) Oberon/F (a particular implementation) doesn't have the particular
module you need.
I happen to like how easy it is to create a form in Oberon/F and link
my procedures to it. the layout tool isn't yet as good as Visual Basic,
but I like the way "code" and interface are linked better than how it is
done in Visual Basic.
Just try writing a form based application in "Standard C", and you might
better appreciate how Oberon/F has made things easier.
As for your particular problem, until we understand why ObxAscii doesn't
meet your needs... and what you *want* in its place, then I don't think
we can help you. Programmers can't work in a vacuum... they have to
understand the requirements of what is to be done.
> problems to solve. However, I did write my own ASCII text file I/O
> module, but when I tell this to my colleagues, they simply laugh at
> it -- that is what makes me worry.
They laugh at what? That you had to code your own module? You can't
use Oberon without coding modules... What forms tool are they using
instead?
> simple ASCII I/O module. Moreover, even a civil engineer can realize
> that this task could be done only with module Files and module
> Strings. Does "razor of Occan" mean anything for you? I hate C++, I do
> not understand why you refer to it, since it seems that you do not
> like it too.
Files is intended to be "low-level"... in fact, I believe in the orignial
Oberon system you could only read and write bytes. If you wanted to read
and write "strings" you needed to use Texts.
> You are missing the point. I am not talking about convenience of
> use, but mainly about complexity, which invariably is related with the
> quantity of concepts involved. Also, I am concerned with the future of
> Oberon/F because other Oberons have already failed in becoming as
> popular as, lets say, Basic or Fortran or Pascal or Modula2 or C or
> C++ or Ada or <choose one computer language and insert its name here>.
> The way I see, Oberon/F is probably the last chance to change the
> status of Oberon2 from toy to tool.
Adding an Ascii module is *not* going to do much in making Oberon/F any
more popular. Now, adding Juice/OMI, Java, or some other internet
related functionality... then you might have something :)
>
> >Personally, I will gladly give up a degree of apparanet simplicity in
> >exchange for a higher level of control. Have you ever invested a
> >significant amount of time in learning a "simple" scripting language
> >only to find that its simplicity makes it useless for the fifth or
> >sixth program you have to write, because it simply doesn't give you
> >enough control?
>
> If you really mean what you wrote, why do not you switch to
> assembler?
By the same token, I could say why don't you switch to Tcl or some
other scripting language? He didn't say he wanted to control things
at a "bits and bytes" level, but the control to use Ascii, Oberon/F
documents, OpenDoc components, HTML, or whatever in a consistent
manner.
> You will exchange all the apparent simplicity for the
> highest possible level of control. For my part, I always considered
> Oberon2 a general purpose high level language, that is, close to the
> problem to be solved and not close to the machine to be used. However
> a definition of ARRAY n1 .. n2 of T instead of ARRAY (n2 - n1 + 1)
> of T makes more sense for a general purpose language.
You keep repeating this "argument"... which is "higher-level"?
ARRAY <lower bound> to <upper bound> OF T; or
ARRAY <number of elements> OF T;
Having a lower bound *consitently* at 0 is advantageous in many
ways. Most of which have nothing to do with the way arrays are
implemented.
> I was predicting the future based on the history of Oberon2. There
> is nothing wrong if Oberon/F is intended to be used only by computer
> science experts. However, the addition of such a module would increase
> the amount of potential users. Anyway, time will tell.
Yes, it will.
> It will make me look with special attention to Ada95.
If you think Oberon is for "computer science experts"... :)
Eric