Re: ASCII text file I/O module

Vinicius Fernando Arcaro (vfa@turing.unicamp.br)
Fri, 30 Aug 1996 12:37:23 -0200

Dear Elan,

>You write:
>>I am a civil engineer ...

>Furthermore you write
>> If, as you say this discussion keeps appearing again and again, it
>>is because there is something wrong with the way Oberon/F handles
>>ASCII text file I/O.

> May I point to you out that exactly that argument you use to
>emphatically proclaim your disdain over being forced to deal with
>what you consider to be an undue complexity of ASCII I/O in Oberon/F
>("I am a civil engineer") makes one wonder, why you would choose to
>assume a tone of authority in explaining that "there is something
>wrong with the way Oberon/F

It seems that you deliberately changed the sequence of my statements
to imply the following: being a civil engineer I am not qualified to
notice what is wrong with the Oberon/F.

It was Bruno Essmann <bessmann@iiic.ethz.ch> who wrote that this
discussion keeps appearing again and again. Using his own words I
deduced that there must be something wrong with Oberon/F, otherwise
this discussion would appear only once. I started this discussion on
c.l.o. about a year ago; take a look at Guy's WWW page on "The reason
I renounced to Oberon/F". In response to this discussion OMI
introduced the ObxAscii on its next release of Oberon/F -- an
insufficient response in my opinion.

Recently, I started another discussion on c.l.o., related to the
lack of simple standard I/O modules in Oberon2. As I pointed, you can
not code a simple "hello world" program that would compile and execute
on two different compilers from distinct manufacturers. During this
discussion I became conscious that this situation already lasted ten
years; I have no doubt that this was a great contribution to the
failure of Oberon2. What would one expect about the future of
Oberon/F, without standard I/O modules? Standard here has a very
restrictive meaning, that is, true only for Oberon/F. Is not it clear
that Oberon/F is going to have the same future of its predecessors?

I say that I am a civil engineer not to imply a tone of authority,
but simply to make it clear that a civil engineer will not spend, or
maybe waste, time with a computer science problem -- an ASCII text
file I/O module. You may not know, but civil engineering has its own
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.

>In response to Bruno Essmann you write:
>>You should have written that the
>>idea was to use the following seven modules: TextModels,
>>TextMappers, TextViews, Files, Converters, Stores, DevLog. Is this
>>simple? Is this as efficient as it could be without all these
>>modules? Are you sure about what these modules are really doing?

>Do you know what is happening behind the scenes of Basic or C++?
>If by the word efficient you really mean efficient, how do you know
>that "print ..." or "<<" really is efficient? Just because all that
>is exposed to you as a script writer - or "programer" if you wish
>- is one simple command that does not at all mean that you know
>anything about how efficient it us implemented. Or do you as a civil
>engineer understood the (in)efficiency of operator overloading
>in C++?

I am not concerned with the syntactic elements of the language, as
you are deliberately trying to imply, but with the quantity of
computer science concepts (records, pointers, lists, dynamic
allocation, information hiding and object orientation) to code a
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.

>Which leads us to an important issue, one of those criteria that I
>propose are more significant in determining whether or not there is
>something "wrong" with Oberon/F than - what at first sight appears to
>be - "convenience of use" taken absolutely and indiscriminantly. This
>criteria is _level_of_control_.

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.

>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? 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.

I never invest a significant amount of time in learning a computer
language that I foresee without future. Oberon2 may be the only
exception, since I am not convinced about its future, but I really
would like to use it.

>Every special case has its own instruction with a unique parameter
>sequence. Looking at the special case of ASCII i/o it all looks nice
>and simple.

In my opinion an ASCII text file is the most portable way of
exchanging computer information and therefore deserves a special
attention. Several languages include ASCII text file I/O in the
definition, but since this approach became politically incorrect, one
would reasonably expect at least a standard library. This should be
done not only to please civil engineers, but mainly to promote the
language use.

>So, what about your little teaser to our friends from OMI,
>threatening them with bankruptcy if they ignore your demand for a
>simplified "special case" ASCII file i/o?

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.

>Putting all this down on paper certainly helped me air some feelings
>about your ongoing complaint. Did it did do anything useful for you?
>Please let me know.

Yes, it increased my worry about the future of Oberon/F. Moreover,
It will make me look with special attention to Ada95.

Regards,
Vinicius