[Oberon] Trivialising formality considered harmful
fusionfive at comhem.se
Wed Mar 15 03:26:43 CET 2006
John Drake wrote:
> --- easlab at absamail.co.za wrote:
> A concrete example. It's irritating to me
> that the ETH Math module uses lower case for
> the procedure names.
> It's doubly irritating when one considers
> that there was no rational reason for this.
One reason may be that these functions are commonly written in lower
case in mathematics. Moreover it feels kind of awkward to write e.g.
arcsinh (arcus sinus hyperbolicus) as ArcSinH. To use Arcsinh would be
> The ETH Math module is moduled off of the
> Modula-2 ISO math module which uses upper
> case. Also Math procedures are upper case
> in the Oakwood guidelines (the one and only
> serious attempt to standardize Oberon compliers
> and libraries.)
No, the Oakwood math procedures are in lower case for sure.
It's ironic that despite the relative smallness and simplicity of Oberon
and the Oakwood libraries, as far as I know, there is *not a single*
freestanding Oakwood conforming Oberon(-2) compiler. Not even Oakwood
What the language needs is a complete Oakwood compliant compiler that
supports standard Oberon-2 and nothing else! If you want lots of extra
features you can go Java and I don't see why you appreciated Oberon in
the first place. (Here, "you" is of course a general "you").
> FAR more irritating to me are the ETH modules
> Strings and Dates. While they got the cases
> right, they got the functionality wrong IMO.
> I started to include what I don't like about
> them in this reply, but I realized that would
> make it too long. ;) I'll put that in a
> seperate post.
Please, do! The only oddities I have noticed are the procedures In.Open
and Out.Open. On mainstream operating systems the IN and OUT streams are
[Chris Glur said:]
>>The only way to advance is to delegate the initial
>>decisions [eg. the
>>syntax of identifiers- uppercase..start-char
>>...etc.] to agreed rules,
>>to free-up mental creativety for REAL decisions.
I agree 100 percent.
> And yet every other programming language on the
> planet has people making all sorts of creative
> "REAL" decisions without resorting to
> artificially forcing a case convention.
I don't see anything artificial about it. If I want to use a library
that has its own conventions, I have to waste time and study those
conventions and if my client module uses libraries with different
conventions the program text will be inconsistent (and look ugly as
well). If the language designer defines the conventions and everyone
adheres to those it's all really a non-issue. In this case Eiffel got it
More information about the Oberon