[Oberon] ThisCommand, semi missing

Paul Onyschuk ptmelville at gmail.com
Wed Apr 16 07:47:13 CEST 2014


On Wed, 16 Apr 2014 01:45:32 +0200
Jan Verhoeven <jan at verhoeven272.nl> wrote:

> LOOP/END gone. Multiple RETURNs gone. Silly WHILE/ELSIF construct.
> CAP, HALT, MIN, MAX gone. WITH gone. Programming used to be about
> Freedom, in order to create software that is as good as can be.Now it
> needs to be as good as can be with a crippled language.
> 
> When a C programmer has the choice to go for Oberon-7 he will stick
> to C since Oberon-7 is way too restrictive. It's almost pedantic.
> Due to its strong TYPE checking, Oberon already was restrictive to
> the Portable Assembler guys. Yes, with a purpose, I know. But with
> the new rules Oberon-7 has put itself outside the arena of serious
> languages. It is over-structured.

Funny, I was reading "Why Pascal Is Not My Favorite Programming
Language" by Brian Kernighan the other day.  Some points he made don't
apply to Oberon - things have changed since Pascal.  Other points aren't
considered valid anymore and can be turned upside down.  You can find
paper online, if you look.

"The is no escape." - this point was against strong type checking.  It
seems silly now, since static weak typing is considered one of the
main weaknesses of C.  Compared to strong static typing and weak
dynamic typing it is worst of both worlds.  Type casting is one thing,
but implicit type conversion... I don't think anyone likes it.  Not
surprisingly pretty much the same camp that was mentioned in paper, went
and used strong static typing in Go.  Probably only lack of bound
checking (how much buffer overflows did cost so far?) can be
considered worse feature of C that weak static typing.  

As for multiple exit points.  Pretty much every functional programming
language uses implicit return for functions, which is typically result
of last statement.  Same applies to lacking in continue/break like
statements.  Oberon is no alien beast by any means here.

There is thin line between freedom of language and protecting
programmer from shooting himself into the foot.  Which you prefer is
mostly matter of taste.  I provided some examples how Oberon
compares to other languages, since I don't want to argue which is
better (it is asking for bikeshedding).

-- 
Paul Onyschuk



More information about the Oberon mailing list