Value Binding and Shadowing

[Richard]

(added comp.lang.oberon to the newsgroup list)

In truth, the more I look into FP languages, the more I appreciate
Wirth's use of Einstein's one-liner, "Make it as simple as possible, but
not simpler", in reference to his Oberon language.

in past times... i also likes such filosofy, likes Oberon.

The rating "as simple as possible" always depends on the goals one
wants to achive. The Oberon programming language was designed to
implement the Oberon System and its application programs.

Nevertheless, it is a general-purpose programming language and
contains features like local procedures which are not available in
many other programming languages and would not really have been
necessary to implement the Oberon System.

1) Oberon do not define libraries, and their complexity way bigger
than language complexity. it's small project for specific purpose. and
makes specific solutions, solutions only for that purposes, not generally
applicable.

A lot of libraries (modules) are targeted to the Oberon System and its
unique user interface. If you want to create native user interfaces
for other operating systems, you have to use different libraries. This
is the same for all programming languages.

2) Oberon language is minimum-minimorum, procedural-only sequential
core. it's for system programming, not for applications.

I do not agree with this assertion. Applications can and have been
created with Oberon and other "procedural-only sequential" programming
lanuguages.

Also, Oberon supports type extension and thus reuse and extensibility
similar to object-oriented languages. Therefore, I would not call it a
"procedural-only" programming language.

It don't have lists or other frequiently used in applications data
strictures and send user to libraries for such functionality. meanwhile, like Ada.
SML has lists.

Oberon is similar to Java before version 1.5 in this respect: It is
possible to create and use collection libraries, however, due to the
lack of generics, it is often preferable to use built-in arrays or
pointers resp. references explicitly.

3) Oberon not defines parallel semantic, it mere ephemeral/procedural.

Similar to many other programming languages there is no explicit
support for parallelism. This does not preclude parallelism supported
by libraries and operating systems.

4) Oberon do not permit to have two independently developed
applications coexist. Oberon just do not thinks about interoperability,
like Ada 83. All oberon system must be one, extensible, application.
All modules have only one "true" implementation.
By design, one version for all.

These are concepts of the Oberon System. When using the Oberon
language on other operating systems, it is easily possible to link
different versions of a module to a program or library.

Oberon is good, but you can not directly compare it with other languages,
with general-purpose languages, like SML. They have different semantic
and different powers, they have different purposes and different solutions,
different functionality.

The Oberon language is a general-purpose programming language
comparable to languages like Java. The Oberon System and it's
libraries are, however, quite different from everything else.

Richard

[Владислав Натаров]

to achive. The Oberon programming language was designed to implement the
Oberon System and its application programs.

exactly. and only for that target.

2) Oberon language is minimum-minimorum, procedural-only sequential
core. it's for system programming, not for applications.

I do not agree with this assertion. Applications can and have been
created with Oberon and other "procedural-only sequential" programming
lanuguages.

sure applications _can_ be created with systems programming language
like C
or Oberon or even assembler. it just only somewhere harder because
language is not
for that, because language works with lower level of abstractions.

but application development can be done _easier_ if language directly
supports
frequiently used data structures, for example, and with simple
readable uncluttered syntax.

...about question of making _portable_(running on any processor with
any
available number of cores without modifications) parallel applications
(not OSes!)...
multicore is mainline now. and _portable_ parallelism is just harder
in Oberon or
any other procedural language, than in SML. All that concurrency,
threads, locks is dpendent on number of cores and on width of memory
buses...
madness! errorprone! And... is just not necessary in 90% of
applications!
Deterministic parallelism will be sufficient.
For that we need higher level of language abstractions (for automatic
parallelising program transformations "map-reduce" is way better than
"if"
and "while"), we need immutability-by-default and strict-by-default
(meanwhile,
lazy-by-default makes parallelisation _harder_). We need strong static
typing.
list of such languages is not big.

look at existentialtype.wordpress.com, Robert Harper say some VERY
simple
arguments about teaching parallel programming to first-course newbies.
I even spend month of my time to translate his truths to my sarcastic
russian...

agin. this is not question of "can". this is more like "how easy".
and such thing is named "progress of technologies"))
yes, SML is more complex... but... we can't live without such features
as RH clearly shows.

Also, Oberon supports type extension and thus reuse and extensibility
similar to object-oriented languages. Therefore, I would not call it a
"procedural-only" programming language.

hmm... i really do not understand wich "reuse" OOP adepts mean in
his blind stupid prairy enchantations about "superiority" of OOP.
this is definetely not reuse, reuse must not ever be "reuse-all"
because
that "all" is continuously changed in real world.
reliable reuse must be "reuse separately specified functionality,
verbose list of that functionality is attached".

modules, with separate interface and implementation parts, gives such
good, real, reuse. but inheritance purposely broke
modularity("incapsulation"),
tightly glues parts and so broke reuse in oop.
inheritance is more like "technology of patches",
transforming solid replaceable (because independent!) modules to
uncontrollable intertwined heap of ropes. Inheritance is really,
really BAD
idea in our "stupid programmer's, managers, users" world.
_internal_ structure of module is showed on the level of modules?
oh-o, thats bad! but this is theme for other separate long news
thread...
and i not want to explain lenghty program reliability and
modication problems here.

so... what with that Oberon type extension? i think Wirth just try to
experiment
with inheritance. And inheritance was included not because it
_needed_, Wirth
wants just to try it and see how it works. Plus all that OOP hype of
that time.
He just wants to build some new coherent "system of axioms" with this
axiom.
This was just good experiment, no more. Yes, he builds some GUI
system.
So what? why you conclude that such system is "one true paradigm for
all"?
He just want build GUI for workstation, no more. OOP is good for GUIs.
Because buttons always will be buttons...
meanwhile, followers of Wirth (like Michael Franz)
understands problems with inheritance... and their recommendations
just looks like they try to build old modular interface-implementation
relation
with ropes of inheritance... like pushing nail with screwdrivers.

Oberon is similar to Java before version 1.5 in this respect: It is
possible to create and use collection libraries, however, due to the
lack of generics, it is often preferable to use built-in arrays or
pointers resp. references explicitly.

SML have polymorphism and functors...
...but real brick on way of procedural languages to future is not
generics.
generics only shortens programs, at the end of words...

real stop is inability to automagically achieve portable and easy
deterministic
parallelism.
too many interdependencies in code, making it almost impossible to
automatically
transform program for current multiprocessor.
functional language is _required_ for parallel era.
let alone mere data-parallelism, we need more general mechanic,
and easily used, deterministic mechanic. not threads or other low-
level
concurrency madness. more like Sisal, Nesl.. that way.
current slogan is "get 90% of available parallelism almost for free",
that's the way. threads is like parallel goto. too many errors.

Similar to many other programming languages there is no explicit support
for parallelism. This does not preclude parallelism supported by
libraries and operating systems.

and that other languages also will die in future years as i think.

about libraries... they must be designed such so to be not only
general,
efficient but also bulletproof in use. on language level checking of
contracts is done simpler. by typesystem.

These are concepts of the Oberon System. When using the Oberon language
on other operating systems, it is easily possible to link different
versions of a module to a program or library.

Yes, by purposely maked OS ways, not Oberon ways. as as say, Oberon
system and it's garbage collector and module loader is thing-in-
itself,
closed world. And because of _that_ it simple.

The Oberon language is a general-purpose programming language comparable
to languages like Java. The Oberon System and it's libraries are,
however, quite different from everything else.

"general-purpose" is so undefinite word...
assembler is also general-purpose (MenuetOS).
maybe we must just say some like "turing-complete"? hehe))

...as i sayed, question is not "can be used" but "how easy".
many modern languages is NOT easy or reliable or even good at
development
of sequential apps. let alone parallel....
it's just used because of management.
Oberon is good, in sequential case, but don't have management
backings.
And it don't make future parallel programming easier, and because of
that
remains in history. Rest in peace, unknown hero Oberon.

[Richard]

Post by Владислав Натаров
but application development can be done _easier_ if language directly
supports
frequiently used data structures, for example, and with simple
readable uncluttered syntax.

I have found the ability to organize application programs based on
type hierarchies to be more important than having concise syntax for
data structures.

Post by Владислав Натаров
so... what with that Oberon type extension? i think Wirth just try to
experiment
with inheritance. And inheritance was included not because it
_needed_, Wirth
wants just to try it and see how it works. Plus all that OOP hype of
that time.

Wirth needed a type-safe way to build an extensible system. So he
included type extension in the language. He did not include other
object-oriented features like methods and multiple inheritance. So, no
experiments there.

Post by Владислав Натаров

Similar to many other programming languages there is no explicit support
for parallelism. This does not preclude parallelism supported by
libraries and operating systems.

and that other languages also will die in future years as i think.

On the other hand, as Jonathan Edwards (alarmingdevelopment.org) put
it, CPU cycles are a lot less important than programmer cycles.

People will probably not leave their favorite programming languages
just to help compilers perform optimizations which are not needed in
most cases anyway.

Richard

[Владислав Натаров]

Post by Richard
I have found the ability to organize application programs based on
type hierarchies to be more important than having concise syntax for
data structures.

i just want to say that having simple lists etc. in language is good.

...hierarchy? it shows our understanding of task. there is nothing
bad with OOP-ish hierarchies... but only until our task or our
understandings not changed))
if such situation is possible then doing flat modularity
from start is better.
OOP hierarchies is hard to modify, just it.
All knows it, but many programmers continue to achieve
his "true, final, universal, solutions" and until now thinks
that "adding more code is always better".
Do not patch legacy, peoples! Just throw to archive and replace...

Post by Richard
Wirth needed a type-safe way to build an extensible system. So he
included type extension in the language. He did not include other
object-oriented features like methods and multiple inheritance. So, no
experiments there.

old modula-2 variant records also gives extensibility...
SML has extensibility without OOP...
...there is many other typesafe ways for polymorphism
and extensibility.

i say, there is nothing "inherent truths" in Wirth solutions,
just good, artistic, ingeneering expression of one of possible styles.

meanwhile, inheritance imho is NOT type-safe "in time", safe only in
one moment. exactly, it do not _saves_ type-safety after code
modufications. contracts not checked because detailed contracts
just not exist.

Post by Richard

Post by Владислав Натаров
and that other languages also will die in future years as i think.

On the other hand, as Jonathan Edwards (alarmingdevelopment.org) put
it, CPU cycles are a lot less important than programmer cycles.

yes, maybe. parallelism is just optimisation for efficiency.
correctness and quality of program is imho more important.
hmm, i may also rephrase JE saying: programmers is too greedy now))

on the other side, performance difference or latency reduction in N
times is hard to miss by user. this is concurent advantage and will
be used by leaders sooner or later. is they want to be leaders.

and more thoroughly thinked, more abstract project in FP style is
usually more correct also, has less bugs. by design.

Post by Richard
People will probably not leave their favorite programming languages

yes, mind lasiness is inherent for peoples.

[Chris Burrows]

Post by Владислав Натаров

Post by Richard
Wirth needed a type-safe way to build an extensible system. So he
included type extension in the language. He did not include other
object-oriented features like methods and multiple inheritance. So, no
experiments there.

old modula-2 variant records also gives extensibility...

Yes, but ...

Variant records in Modula-2 are NOT type-safe. They are plagued with the
same problems as variant records in Pascal:

"An undisputed candidate for elimination was Modula's variant record.
Introduced with the laudable intent of providing flexibility in data
structuring, it ended up mostly being misused to breach the typing concept.
The feature allows to interpret a data record in various ways according to
various overlaid field templates, where one of them is marked as valid by
the current value of a tag field. The true sin was that this tag could be
omitted."

Ref: Modula-2 and Oberon> Niklaus Wirth, Paper submitted to HOPL-3, June
2005

"Variant records are eliminated, because they constitute a genuine
difficulty for the implementation of a reliable storage management system
based on automatic garbage collection. The functionality of variant records
is preserved by the introduction of extensible data types."

Ref: From Modula to Oberon, N.Wirth 1.10.1990

Regards,
Chris Burrows

CFB Software
http://www.cfbsoftware.com

[Владислав Натаров]

Post by Chris Burrows

Post by Владислав Натаров
old modula-2 variant records also gives extensibility...

Yes, but ...
Variant records in Modula-2 are NOT type-safe. They are plagued with the
"... marked as valid by the current value of a tag field. The true sin was
that this tag could be omitted."
"Variant records are eliminated, because they constitute a genuine
difficulty for the implementation of a reliable storage management
system based on automatic garbage collection. The functionality of
variant records is preserved by the introduction of extensible data
types."

hmmm... i remember, i read this words some years earlier))
looks like that will be long talk. let's begin...
imho, tagged record potentially _is_ typesafe, maybe just it
implementation in modula-2 is not? or automatic conversion of
base types do it's dirty work transforming tags or just
work with tags is not enough hidden from programmer?
hmm... yes, i think that working with tag was just not
enough hidden and automatic, like in SML.

and i do not remember if modula-2 compiler do exaustiveness checks
that is, check that programmer defines processing for all possible
type
kinds of variant record. i definetely can say that is SML this
mechanic,
pattern matching plus exaustiveness check in function definitions,
is typesafe and checked. maybe type inference or higher level of
that language helps?
what i want to say... definetely there _is_ other ways beside
inheritance, typesafe ways. without inheritance drawbacks.

...meanwhile, maybe Wirth say more about bad programmers,
not about bad variant records))
maybe programmers just try to misuse variants, try to store
in it different types, not different kinds of one type?
and because type system of modula (which is system's
programming language) is too permissive they can?
there is simple article at existentialtype.wordpress.com about
variants.
named "dynamic languages are static languages".

now about garbage collection. Wirth just selects way which he
think will be easier for him. but, imho, he just delay deploying
of full solution )) what i mean? the more i think, the more i
understand that inheritance is very like pointer, just on a bigger
time scale. pointer exist at runtime, inheritance exist at lifetime
of program.
meanwhile, goto, pointers, inheritance, threads, imperativeness,
ephemeral data structures... all that things look like each other,
and gives very similar problems to programmer. and i found why:
because that things based on principle of "one-way" dependence.
such dependencies permit changes flow only in one way, not back.
having that, with time we loose program consistency.
you see how simple? ALL problems of IT traced to loosing of
consistency (contracts) because one-way dependencies used.

...with the relational two-way dependencies such problem not exist
and consistency can be maintained automatically.
so, solutions to all IT problems are similar: goto and threads packed
in more safe and self-sufficient higher-level structures, pointers
packed
with garbage collector for restoring it consistency (or maked two-way
with ring of backpointers), ephemeral data structures and procedural
programming replaced by immutable data structires and parallel
functional programming etc...
... maybe i write article on all that sometime...

so... if you read me carefully, you already understand what Wirth
do. he pushes garbage collection implementation problems with
variants from runtime - to problems with inheritance at program
lifetime. and left to programmers restoring of consistency,
periodically broken by inheritance, manually...
problem still exist, it just harder to see now, because they
at bigger timescale. and we looks only at our hands, not around,
as usual)). he not solve problem, he just hide it from casual
observation.

to be fully complete (if he not want implement garbage collector,
correctly working with variants... hmmm seems that was hard
mainly because language is targeted as system's language,
because language is too low level) his solution must include
some "lifetime garbage collector" for programs, tracing and
showing problems with changes in inheritance hierarchy
to programmer.
Wirth solutions - is good solutions for _his_ problems, not
for _all_ problems. And _that is good_