you write:
>2) The same contributor also implied that at least one of the people
> involved in the discussion was unqualified to make an educated
> submission to the argument, due to his(?) lack of systems-programming
> experience
seeing as you bring the qualification issue up again: I stated previously
that my intention was not to denounce any participant in this discussion as
unqualified. I pointed out a discrepency between the original authors claim
that he was significantly challenged by trying to implement ascii file i/o
under Oberon/F and the role he assumed in making remarks as to the whether
Oberon/2 - Oberon/F have a future and Oberon2 - Oberon/F are conceptually
"wrong" or not. Let me apologize publicly to anyone who might have felt
that I was trying to depict him or her as unqualified. That was not my
intention.
And let me explain. I am allergic to people taking on assumed role of
innocence "I am a humble non-programer who has a problem" in order to
promote an ideology "Oberon/F has a conceptual weakness ... (that perhaps
has been solved by ADA95)". As we learned later, the author of the ASCII
i/o problem had - with the help of others - implemented a solution that was
sufficient for his use, before he re-started the debate about ASCII i/o.
Why not mail a message saying, I believe there is an insufficiency with the
way Oberon/F is distributed. It is lacking an ASCII file i/o that I think
is basic. Here is a solution that I find to be useful. If anyone else can
use it, go ahead and use it (or send my a check, or whatever). If you think
it can be improved let me know how and why and even better send me an
implementation. If it's widely used, let's call it a standard and - based
on its wide usage - let's promote it as a standard ASCII i/o library that
every implementor of Oberon development systems should integrate into their
distribution. Why not like that?
The reason I am allergic to these make-belief scenarios (my problem has
already been solved, but I will pretend as though it wasn't in order to set
off a debate) is that these kinds of contributions are manipulative. Ernest
Hemingway, having been asked what it takes to become a successful novelist,
is reported to have responded, a crash-proof, built-in crap detector. I
pride myself of having a rather sensitive one, even though it is not my
intention to become a novelist. I don't appreciate people trying to play
mind-games with me. I consider it an insult, when they do, because they
appear to assume that I am too much of a fool to notice what they are up
to. State your cause and present your arguments, that's all. Approach me as
a being with no less intelligence than you have. Tell me up front this is
what I want to convince you of and then present your proof: These are the
arguments that I believe will persuade you. Everything else is politics and
politics tends to be conservative and slow down technological progress.
Unfortunately, when ideologists raise a problem, they are not looking for a
solution. People will hand in proposed solutions (see Marc Martin's
proposed interface) and be ignored, because they are taking the make-belief
situation for real. I call that making a fool of someone. Now, that's an
insult. You should value other people's time enough not to bother them with
fictitious problems ... (or lengthy apologees, I apologize) that you have
already solved. Don't scream for help if you're not drowning.
Software development is in dire need of technological progress. Software
development technology (besides advertising and marketing budgets) is the
one predominant factor slowing the deployment of advanced hardware
platforms. The Wintel dominance of the computer market is very much a
result of (besides tremendous ad/marketing budgets) the fact that
consumer-oriented software has a difficult time adapting to new hardware
platforms and therefore dictates the dominance of the Wintel architecture.
After all, the consumer of digital products sees these products through the
eyes of the applications that are useful to him, not in terms of
technological advancement (that remain useless to him for lack of
applications that will benefit him or her). Component technology promises
to decentralize software development and make it more portable.
Things are being done about that. IMHO, the Oberon 2 language due to its
minimalistic and yet very powerful approach of introducing advanced object-
and component oriented technologies is a tremendous step in the right
direction. I think that Oberon/F is a very useful implementation of a
development environment based on Oberon 2. (I'm writing this on a machine
loaded with (legally obtained) goodies such, Borland C++ 4.5, Visual C++
4.0, Borland Delphi 1.0 and 2.0, Dolphin Smalltalk, Scheme, Franz Lisp,
Power Builder, Paradox, MS Java, to name a few. As a consultant, I am
forced to use whatever programming language my customer's require.) My
choice development environment is Oberon/F! With reason.
How about this for a lengthy apologee. Maybe I should become a novelist
after all?
Sorry,
Elan