[Oberon] Trivialising formality considered harmful

[John Drake]

--- easlab at absamail.co.za wrote:

> 
> A recent observation/complaint that the suggested
> identifyer formats
> was ignored, was mostly trivialised. 

I don't know if it's accurate to say it was 
"mostly trivialised".  You had several replies
from the same person "trivializing it" and one
reply explaining what the current convention
being used is.  So that's one person for 
"trivialising" and one person for "explaining"
which is a 50/50 split.
 
> Some ideas on the RFCs system idea:
> Only by making and obeying agreed rules/standards
> can 
> geopgraphically  dispersed collaborators make
> combined progress.

To coin a phrase from Animal Farm "Some
rules/standards are more equal than others."
What I mean by that is some things fall into
the "irritation" category whereas other things
fall into the "prohibit what I want to do" 
category, and there are shades of grey
in between.

A concrete example.  It's irritating to me
that the ETH Math module uses lower case for
the procedure names.  

http://www.oberon.ethz.ch/ethoberon/defs/Math.Def.html

It's doubly irritating when one considers
that there was no rational reason for this.
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.)  

http://www.comp-inspirations.com/docs/oakwood.pdf

But this irritation doesn't stop
me from doing work.  I can always look
at the definition for module Math (trivially
easy to do in all flavors of Oberon)

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.

> ETH oberon seems already to have passed the stage
> when the loss by
> entropy exceeds the new value added - the added
> contributions are
> matched by the 'evaporation' losses of the
> contents-bowl.

Well, to some extent I agree.  But one has to
understand the REAL reasons for the loss.  I
don't think programmers not sticking to
capitalization conventions has much to do
with it.  Rather I'd chalk it up to divergence.
Divergence among various Oberon systems, 
divergence among versions of the same system
and lately divergence among compilers.

Just looking at the issue of capitalization,
to "fix" the problem you'll have to break
some old code.  Imagine all of the places
"Math.sin" might need to be replaced by
"Math.Sin".  Other communities have handled
this using a convention called "deprecation"
which basically means "We'll leave both
options in for now, but don't write any
new code making this library call because
eventually it will go away."  I know several
times in the past I had old code that was
broken because ETH changed a particular
procedure name.  I don't recall seeing these
changes in the change log.  Anyway, I fixed
my code and moved on.

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

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.

> Idealy these
> initial [now trivial] decisions would be captured
> and frozen, the way
> the language is frozen in the compiler. No
> possiblilty to mess with it
> in the name of artistic licence !

A) That would break old code (unnecessarily IMO).

B) What happens when the "powers that be" decide
to go for a different convention?  (As apparently
is the case with the latest Native code and 
BlueBottle code).

C) Such a "feature" adds more complexity to
the compiler for very little return.

> The progress from: 
> -  codeing in binary with switches,
> -  codeing in hex with papertape,
> -  codeing in assembler,
> ...
> -  codeing in a strongly typed language[s]
> should not end there.
> 
> The decision [artistic licence which creates chaos]
> of ID formats
> should be removed, and frozen into the language
> system.

Except this "chaos" really hasn't had a measurable
effect on any programming language that I can
think of.

> One step towards this is to first have a well
> considered 
> recommendation - which apparently is already the
> case ?

Well, now we have two.  The original one and the
one Thomas Frey mentioned.

> And to have this followed/tested for a [certain]
> time/volume.
> Of course this strong-typing/restricted-format is
> consistent with
> the Wirthian minimalist approach.

I don't think Wirth would ever put such a feature
in a compiler.  But that's just my opinion.  It
seems to be adding complexity to a compiler just
for aethestics.
 
> I've noted [perhaps wrongly] that for N-O fileIDs,
> the format
> 'Name.Extension' is inappropriate - probably being a
> [now 
> inapplicable] copy from some previous OS.
> 'NameExtension' seems better, especially since it
> avoids confusion 
> with syntax which MUST use the "." [period] and can
> avoid 
> unintentional 'Module.Command' execution.

That would make sorting files by type rather
chaotic.  I've never seen a case where a
Module.Extension actually matched to a
Module.Command, although that's certainly
possible.

Regards,

John M. Drake

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com