to achive. The Oberon programming language was designed to implement the
Oberon System and its application programs.
exactly. and only for that target.
Post by NatarovVI
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
sure applications _can_ be created with systems programming language
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
frequiently used data structures, for example, and with simple
readable uncluttered syntax.
...about question of making _portable_(running on any processor with
available number of cores without modifications) parallel applications
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
madness! errorprone! And... is just not necessary in 90% of
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
and "while"), we need immutability-by-default and strict-by-default
lazy-by-default makes parallelisation _harder_). We need strong static
list of such languages is not big.
look at existentialtype.wordpress.com, Robert Harper say some VERY
arguments about teaching parallel programming to first-course newbies.
I even spend month of my time to translate his truths to my sarcastic
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"
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
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,
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
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
with inheritance. And inheritance was included not because it
wants just to try it and see how it works. Plus all that OOP hype of
He just wants to build some new coherent "system of axioms" with this
This was just good experiment, no more. Yes, he builds some GUI
So what? why you conclude that such system is "one true paradigm for
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
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 only shortens programs, at the end of words...
real stop is inability to automagically achieve portable and easy
too many interdependencies in code, making it almost impossible to
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-
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
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-
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
of sequential apps. let alone parallel....
it's just used because of management.
Oberon is good, in sequential case, but don't have management
And it don't make future parallel programming easier, and because of
remains in history. Rest in peace, unknown hero Oberon.