[Oberon] Oberon usage

[Aubrey.McIntosh at Alumni.UTexas.Net]

Thanks for the reply.  I have struggled with this response all
afternoon, writing and erasing.

I do want to say in the sidebar that Oberon is a snapshot of a
language design from a quarter century ago.  In particular, the views
on strings has changed in the intervening years.  If you want to focus
specifically on Oberon and its design decisions, it would seem
appropriate to compare it to other languages available in 1984.  The
Oberon compiler and system that I use to compile and check my
responses before posting was last updated in about 1995.  It is very
reliable and frequently my tool of choice.

On the other hand, if you want to make a comparison to other languages
available today, then you might look at  the most current design in
the Algol/Pascal/Modula/Oberon language family, Component Pascal.
This design is only 10 years old.  Many of Doug's answers have
anticipated this shift to the current design ideas.

Now back to the conversation, I don't think that something needs to be
built in to do all these things that you desire:

> Builtin means:
> * No need to code it / reinvent the wheel.
> * No need to re-code it each time, for detail differences: here one needs one init proc for _every_ type.
> * It is very probably done the right way.
> * It is reliable.
> * It is a *shared* feature.

A Text is a wonderful thing.  It is more than a simple file filled
with human readable data.  An Oberon system that incompletely boots
can often put up a viewer with a log text.  This text is persistent,
and can be saved, edited, annotated, emailed to the developers.  This
is a capability that is far, far more valuable than a simple screen
window a memory buffer that scrolls off the top and is gone forever.
This is a far more ambitious type than just a complex number, but it
is well supported by the language.  Again, the Text system and editor
is my tool of choice, because it is powerful and easy to use.  The
design choices that allow this capability to exist, in the 1984
technology, is viewed with great awe and reverence by this community,
and the specific way that we have of making everything clear to the
*reader* of the sources, whether human or compiler, is accepted as a
fundamental part of what enables that power.

Other modules are published.  Strings and Dates come to mind
immediately.  Again, they are not built into the compiler.  They are
free standing modules.  So again, it meets all the criteria on your
list, but it is not built in.  I have written an abstract data type
that keeps track of significant digits, as I am a chemist, and used it
to produce documents where matrix calculations all have attention to
the significant digits.

The movement of these items to library modules and out of the language
definition allows the Oberon language to be so small that the entire
operating system, compiler, and sources can fit on a floppy disk.



On Sun, Jul 11, 2010 at 2:12 PM, spir <denis.spir at gmail.com> wrote:
> On Sun, 11 Jul 2010 10:28:49 -0500
> Aubrey.McIntosh at Alumni.UTexas.Net wrote:
>
>> > - no literal notation for arrays and records/objects (center := Point{x:=0,y:=0};)
>>
>> I don't understand how this notion is unsatisfactory for you:
>> center := ThisP ( 5.0, 7.5 )
> [...]
>> PROCEDURE ThisP(x, y : REAL ) : PointPtr;
>>       VAR
>>               aux : PointPolarPtr;
>> BEGIN
>>       aux.mag := Math.sqrt(x*x + y*y);
>>       aux.angle := Math.arctan( y / x );
>>       RETURN aux
>> END ThisP;
>
>
> Because it is not builtin, indeed. Why have arrays, & indexing, then? Why records, & extensible types? Why operators at all? We can hand-code all of this, cannot we? Why sensible abstractions like automatic dereferencing, too?
>
> Builtin means:
> * No need to code it / reinvent the wheel.
> * No need to re-code it each time, for detail differences: here one needs one init proc for _every_ type.
> * It is very probably done the right way.
> * It is reliable.
> * It is a *shared* feature.
>
> The latter point is often overlooked, but in my sense the most important one: the whole Oberon programming community share the feature; everyone knows, or will soon know, perfectly its precise semantics.
>
> And there are things we simply cannot build on top of a language as is. I would be pleased to contribute a module, if the language gave me the means to do it. But literal notation magic happens on the compiler side, thus I'm helpless (and can only complain ;-)
>
>
> All of this makes me sad for the following reason: when I first discovered Oberon-2, I was very surprised such a design quality in a super-hype field (OO) can even *exist* in our all-marketing time. And wondered why this language did not happen to challenge and offer prgrammer with higher quality expectations ("resistants") a sane & sensible alternative ("counter culture" ;-) in front of the all-C (C++,C#,java) power... exactly like Pascal one generation before. Reasons I read in an interview of Niklaus Wirth are certainly true: marketing, precisely, and not the right time for a new language.
> Maybe there is more on the topic. Namely: is it a wished perspective? I would love to see an active and enthusiastic eco-system around such a great language. Among other things, this requires a tiny minimum of agile tools & abstractions; ones that would not make the language less elegant, on the contrary (and let more place to the joy of programming instead of wasting our time and energy with administrative tasks). What do the language creators, promotors, users want?
>
> (Sorry for taking your reply as an oppurtunity, Aubrey. And sorry for the mood to all.)
>
>
> Denis
> ________________________________
>
> vit esse estrany ☣
>
> spir.wikidot.com
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>



-- 
-- 
Aubrey McIntosh, Ph.D.
1502 Devon Circle
Austin TX 78723-1814
http://home.grandecom.net/~amcintosh/aubrey/Search/