Re: ASCII text file I/O module

Elan Paznesh (icimjs@loop.com)
Fri, 30 Aug 1996 12:52:17 -0700

Dear Vincinius,

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

Wrong. I did not deliberately change the sequence of your statements in
order to imply anything. The sequence is inconsequential. I was alerting
you to the fact that you assumed two incompatible persona in your argument:
The humble civil engineer who is significantly challenged by the seeming
complexity of doing ASCII file i/o and the programing frameworks expert,
who has the competence to identify a problem with the framework he is using
(in contrast to a computer layman who might assume that he is simply not
knowledgeable enough to get it right). Consider the possibility that I am
not going out of my way to construct an unnecessary insult. At the same
time, you might reflect on why you would assume that people in this
discussion group would want to deliberately misquote your statements in
order to question your qualification? Are we involved in a technical or a
political discussion?

These two persona are represented in Oberon/F by two types of programing
atoms: The PROCEDURE and the Command. The short form of a specialized case
of ASCII file i/o belongs under the category Commands. This command applies
an implementation of ASCII file i/o. The implementation of the command
belongs in the category PROCEDURE. You are arguing implementation versus
application when you complain about the level of complexity of the involved
procedures in contrast to the application of the resulting command. For all
practical purposes I think that this is a perfectly acceptable solution and
should end this debate.

>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. (...) I have no
doubt that this was a great contribution to the
>failure of Oberon2.

I disagree. Microsoft, Borland, Metroworks, Apple, Sun Microsystems, Next
Inc. and quite a few others are distributing C++ compilers for the same or
different platforms. Borland C++ comes with a framework called OWL.
Microsoft's C++ comes with a framework called MFC. These frameworks are
incompatible with each other ... for the one and the same MS Windows
platform. Metroworks distributes a compiler for Apple computers that
includes two sets of incompatible libraries: one set for Mac OS and the
second set of librairies containing MFC for MS Windows. Where's your
compatiblity argument here? Next Inc compilers are incompatible with Sun
Microsystems ... for the Sun Sparc Station. Of course the Sun Microsystems
compiler's framework is incompatible with OWL or MFC. Galaxy (and others)
distribute incompatible portability librairies that include i/o.

Take Borland's Delphi. Delphi is incompatible with anything but MS Windows.
And Delphi is incompatible with anything but Delphi under MS Windows. This
has not stopped Delphi from being a successful product.

If indeed portability between different platforms were as much an issue as
you make it to be, if indeed the survival of a programing language depended
on the portability of available framework implementations, C++ should be
dead and not a lucrative market for all (incompatible) parties involved.
And Delphi should by now be extinct. (Look around on the internet and check
out how many Delphi VCL's are being given away or marketed. I have a
catalogue here called "Delphi only Tools" that lists 84 third-party
products (mostly VCL's) for Delphi that are compatible with nothing but
Delphi, ranging in price from approx. $39 up to $400)

You will notice that I have taken the liberty to discuss frameworks where
you say standard i/o modules. This is because for any practical purpose a
standard i/o module in the world of GUIs and APIs is insufficient. Any
serious program has to make use of system resources that cannot be managed
by the concept of standard i/o modules. This concept is too weak. You have
to upgrade to the concept of a full-blown framework before you have a
programing environment that will actually be used!

>I am not concerned with the syntactic elements of the language, as
>you are deliberately trying to imply, (...)
I wasn't deliberately trying to imply that you are concerned with the
syntactic elements of the language. I mentioned operator overloading with
respect to _efficiency_of_implementation_, challenging your idea that the
exposure of modules involved in implementing ASCII file i/o (the seven
modules...) makes a statement about efficiency!

>I am not concerned with (...) 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.

This statement reflects a significant misunderstanding. ASCII I/O is not
simple or complex. The simplicity or complexity of I/O (whether ASCII or
not) depends on the underlying technology. This technology in the case of
Oberon/F is MS Windows (or MacOs) and the Windows API is far from being
simple. Concepts (even computer science concepts) are mental tools to
manage complexity. The less concepts you have, the less mental tools you
have to understand what you are doing and making educated decisions as to
how to go about it. The strength of Oberon/F is that it exposes these tools
in a simple way for the programer who wishes to implement a Command.
(Beyond that I refer to the beginning of this mail, where I pointed out the
difference between implementation versus application of commands.)

>Moreover, even a civil engineer can realize
>that this task could be done only with module Files and module
>Strings.
Congratulations! Now, what exactly do you want?

>I hate C++, I do
>not understand why you refer to it, since it seems that you do not
>like it too.
Excuse me!

>You may not know, but civil engineering has its own
>problems to solve.

Oh, really, who would have thought, thank you for pointing it out!

>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 are all civil engineers too? Beware of civil engineers!

>I am not talking about convenience of
>use, but mainly about complexity, which invariably is related with the
>quantity of concepts involved.

I beg to differ. Complexity is invariably related to the reality you are
conceptualizating. There is something called oversimplification, there is
something called simplification. The quantity of concepts does not reflect
whether the concepts were well-chosen. Well-chose concepts (in sufficent
quantity to reflect reality) are tools to manage complexity. They are not
the source of complexity, unless they are ill-chosen, which can be the case
with many or few concepts.

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

You misunderstand. I'm not talking about level of control over which
instructions the CPU executes. I am talking about level of control over the
problem to be solved.

>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

What do you think about using Marc Martin's proposed interface?

>I was predicting the future based on the history of Oberon2
However, I think that the example of C++, Delphi, PowerBuilder etc. shows
that your analysis of the past failure of Oberon2 to take establish a
considerable market share is incorrect. Oberon2 has not won a significant
market-share, but not for the reasons that you propose.

En passant, don't you think that this is misleading (and worthy of a
politician):
> It was Bruno Essmann <bessmann@iiic.ethz.ch> who wrote that this
>discussion keeps appearing again and again. Using his own words ...

Oh, it's Bruno Essmann's own words that what? ...

>...I deduced that there must be something wrong
Exactly, you "deduced" that there must be something wrong, not Bruno
Essman. Why point out that it was Bruno Essmann's own words, as though he
shared a responsibility for your "deduction"?

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

Dear Vincinius, if I consider your unusual hostility (accusing me of
deliberately misquoting you in order to imply this or that), rhetorical
maneuvers ("In Bruno Essmans own words...") that I am more accustomed to
hear from politicians than engineers, your funeral speeches about Oberon2's
future (do you realize how many programing languages continue to be used
and maintained that never made it to the mainstream?) I am tempted to ask
you outwrite: Are you trying to have a problem solved that you encountered,
or is your only interest in promoting whatever by bickering about Oberon/F?

Sincerely
Elan