Oberon in practice 
Author Message
 Oberon in practice

After reading the article about Oberon in the last issue of Byte,
I downloaded the DEC version and played around with it a bit.
It is impressive in many respects, but I wonder whether it can
be used for "real" applications (as opposed to training purposes).

Apart from some problems I see in the current implementation
(like lack of debugging support and interfaces to other
languages), there are also two conceptual problems with the
Oberon system:

1) There is only a global name space for modules
2) No multitasking

The first problem is relevant for people who use application
programs from different developers. Of course, "application
program" means "collection of application modules" in Oberon,
and large application will probably consist of many modules.
There is then a large chance that two applications will use
the same module name, perhaps even for almost the same purpose,
but probably not with an identical interface. Since modules
are automatically global (if I didn't overlook something),
it would be impossible to have both applications in the system
at the same time.

Lack of multitasking seems to be a deliberate design decision,
but one I don't understand. While it is true that users
normally interact only with one program at a time, there
are always operations that need no user interaction, but
much time, and should therefore be run as background processes.
A common example would be background printing, another one
the execution of lengthy numerical computations.

I would be interested in comments on these topics by more
experienced Oberon users.




Sun, 29 Oct 1995 19:25:12 GMT  
 Oberon in practice

Quote:

>Apart from some problems I see in the current implementation
>(like lack of debugging support and interfaces to other
>languages), there are also two conceptual problems with the
>Oberon system:

>1) There is only a global name space for modules
>2) No multitasking

>The first problem is relevant for people who use application
>programs from different developers. Of course, "application
>program" means "collection of application modules" in Oberon,
>and large application will probably consist of many modules.
>There is then a large chance that two applications will use
>the same module name, perhaps even for almost the same purpose,
>but probably not with an identical interface. Since modules
>are automatically global (if I didn't overlook something),
>it would be impossible to have both applications in the system
>at the same time.

There is no specific language mechanism for handling this case.
I can imagine tools that would resolve name conflicts and 'repair'
sources, symbol files, and object files. But as far as I know,
such a tool does not exist.

Quote:

>Lack of multitasking seems to be a deliberate design decision,
>but one I don't understand.

The low level background printing could be handled by interrupt
driven mechanisms. The ETH view on time intensive tasks is that
they should be off-loaded to dedicated 'compute servers'. Of
course one can argue that the latter do not exist, but I think
that such a vision of the future is the correct one. The ratio
of people to computers used to be 100:1. Today it approaches 10:1
(if you include all people). Eventually, the ratio will be 1:100.
Compute servers will then be the norm rather than the exception.

--

"Shatter the harmony and you shatter the social structure."
    -- Biba Kopf on Einstuerzende Neubauten, 1989



Mon, 30 Oct 1995 00:40:44 GMT  
 Oberon in practice
Quote:
>Apart from some problems I see in the current implementation
>(like lack of debugging support and interfaces to other
>languages), there are also two conceptual problems with the
>Oberon system:

>1) There is only a global name space for modules
>2) No multitasking

Well have been having a lengthy and interesting discussion with Marc Brandis
at ETH on multi-tasking and perhaps he should be responding. It seems the
two points arent necessarily disjoint. Oberon has a global address space
too and this makes it difficult to implement pre-emptive multitasking
because of difficulties in protecting large areas of code. Oberon can I
believe achieve background printing etc. with "tasks" which appear to be
cooperative multi-tasking. Nonetheless, I agree, without pre-emptive
multi-tasking the Oberon system is pretty useless to me so I restrict my
interest for real-world purposes to the language.

I shouldnt be speaking for the Oberon developers but appears attitude is
if it cant be done simply, if there isnt an obvious ONE TRUE WAY to do
something then it wont be done. Wirth appears anti- committee involvement
in extending the language for obvious reasons and with ETH uninterested
in real world complexity, it looks a bit like the Oberon system may be a
dead-end. Hopefully it will inspire other OS developments that are prepared
to address the complexity of pre-emptive multitasking because I dont think
a system is going to be much without it.
        Phil



Mon, 30 Oct 1995 05:04:10 GMT  
 Oberon in practice
: Apart from some problems I see in the current implementation
: (like lack of debugging support and interfaces to other
: languages), there are also two conceptual problems with the
: Oberon system:
:
: 1) There is only a global name space for modules
: 2) No multitasking
:
[ ...]
: Lack of multitasking seems to be a deliberate design decision,
: but one I don't understand. While it is true that users
: normally interact only with one program at a time, there
: are always operations that need no user interaction, but
: much time, and should therefore be run as background processes.
: A common example would be background printing, another one
: the execution of lengthy numerical computations.
:
:
: I would be interested in comments on these topics by more
: experienced Oberon users.

Ok, I'm not somewhat experienced, that I would have done some projects in
Oberon, it ist just part of my studies at the ETH :-)

I know, that the missing multitasking facility is a often discussed
subject, with different point of views, and I don't want do express my
one ones, but I quote some of J. Gutknecht, the co-author of the Oberon
System.

The First Ideas, about a new OS were written down 1985 in the Parc in
Palo Alto, in June '85, these were:

" 'Highlights'
a) modular structure
b) extensibility
c) dynamic loading
d) tiling viewers
e) no modes
f) garbage collector
g) multiple task, single process
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
h) commands instead programs
i) flexible integrated command interpretation
j) runtime parameters for commands
k) command tools
l) integrated text, no explicit editor
m) typed files
n) integration in local netwokr
.." (Output 1992 Jubilaeumsausgabe p.38 - 44)

Some of these (j and m) were abandoned later.
Gutkencht writes, that they were inspired on the 'Cedar' System at the
Parc, which was considered as state-of-the-art.
But they discovered the achillesheel of the System: Cedar was a
Mulitasking Machine, which was led it to be not very stable.
For simplicity, the Oberon-System became a 'Single Process' Machine. If
you look at the original System, you see the result:
The whole System was about 144k big, with a souce-code of about 10380
lines in Oberon!

The Metapher 'multiple task, single process' hints to the ability of the
Oberon-System, to have some multistaking features. It is possilbe to hook
up you ownr routines to the idle-loop (Oberon.loop). This feature is used
for Clocks and similar things.

The whole project stood under N.Wirths word:

"Make it as simple as possible, but not simpler"

and I think this goal was pretty much achived.

:

-daniel
--



DECnet              : EZINFO::CLUESCH



Mon, 30 Oct 1995 06:16:15 GMT  
 Oberon in practice

(kluge daniel) says:

Quote:

>The whole project stood under N.Wirths word:

>"Make it as simple as possible, but not simpler"

>and I think this goal was pretty much achived.

That's a famous quote, and one with which I tend to agree. In fact,
the basic simplicity of Oberon is what makes the system attractive
to me. Still, "possible" must be interpreted as "possible without
compromising the usability of the system", otherwise the simplest
system would clearly be none at all.

The question then is whether multitasking (and maybe some other
features) are essential to important real-life applications or not.
For me, the answer is yes, at least as long as there are important
tasks that take more than a second to execute. No matter how fast
the hardware gets, this will probably remain true forever.




Mon, 30 Oct 1995 20:09:37 GMT  
 Oberon in practice

Quote:
>The low level background printing could be handled by interrupt
>driven mechanisms. The ETH view on time intensive tasks is that
>they should be off-loaded to dedicated 'compute servers'. Of
>course one can argue that the latter do not exist, but I think
>that such a vision of the future is the correct one. The ratio
>of people to computers used to be 100:1. Today it approaches 10:1
>(if you include all people). Eventually, the ratio will be 1:100.
>Compute servers will then be the norm rather than the exception.

Well I guess I mostly write for compute servers then. Tell me, what is your
vision for these compute-servers? C/Unix? Preserve us! If this is the case,
then I consider Oberon half-done. How about a nice useful language and system
for the compute-servers to go with it and then we will have a complete system
worthy of some serious consideration.
        Phil


Tue, 31 Oct 1995 05:54:02 GMT  
 Oberon in practice

Quote:

>that such a vision of the future is the correct one. The ratio
>of people to computers used to be 100:1. Today it approaches 10:1
>(if you include all people). Eventually, the ratio will be 1:100.
>Compute servers will then be the norm rather than the exception.

Ahem !
Do you mean, when everybody has 100 workstations on his desk, they
will tend to use compute servers ?

Or do you just mean that the more computers there are, the more sense
it makes to share a compute server ?

In any case, it seems bogus :-)

        Stefan



Sat, 04 Nov 1995 08:58:51 GMT  
 Oberon in practice

Quote:


>>that such a vision of the future is the correct one. The ratio
>>of people to computers used to be 100:1. Today it approaches 10:1
>>(if you include all people). Eventually, the ratio will be 1:100.
>>Compute servers will then be the norm rather than the exception.

>Ahem !
>Do you mean, when everybody has 100 workstations on his desk, they
>will tend to use compute servers ?

>Or do you just mean that the more computers there are, the more sense
>it makes to share a compute server ?

>In any case, it seems bogus :-)


>    Stefan

I have to agree with Cheryl here.  My interpretation of her statement is
that computers will begin (more and more) to permeate our lives.
Eventually, there will be 100 computers servicing each human.  (i.e. (some
possibilities) linguistic translator, banking, library, TRON houses, etc).
 As the number of ocmputers servicing people, it seems logical to use
servers to do the bulk of the task.  

(Hmm, seems a lot like the glass-computing-room scenario that the
consultants are trying to get people away from.  I think all this client
server stuff, in a nutshell (on the local consultant level) is a way to
get people to buy new hardware and put it in a different glass room).

Taylor "Anti Consultant" Hutt
Championing worldwise self-sufficiency!

BTW, I will be eternally grateful to any old TRS-80 users that can tell me
something about a spreadsheet program written for it.  I cannot remember
the name right now, but it was something like 'Analysis Pad'.

Specifically, who was the author, and what year was it released.



Sat, 04 Nov 1995 11:31:03 GMT  
 Oberon in practice

Quote:


>>that such a vision of the future is the correct one. The ratio
>>of people to computers used to be 100:1. Today it approaches 10:1
>>(if you include all people). Eventually, the ratio will be 1:100.
>>Compute servers will then be the norm rather than the exception.

>Ahem !
>Do you mean, when everybody has 100 workstations on his desk, they
>will tend to use compute servers ?

There was a time when personal calculators were very rare things. Today
they are commonplace. Wrist watches were once rare and expensive things.
Today they are common.

This is the history to technological advancement.

The 100:1 ratio is meant to include ALL computers you use. Did you know
your microwave oven has a computer? You car (if a new one) have quite a few.
Of course, the spare clock cycles in these computers cannot be used for
solving your equations, because they are custom devices.

But there are already a few researchers looking at how to use the cycles of
idle machines in your own office site.

Eventually there will be many more machines than you can possibly use.

--

"All you need is HEADCLEANER!" -- Einstuerzende Neubauten



Mon, 06 Nov 1995 00:46:20 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Frage Oberon 3 / Question Oberon 3

2. CD-Oberon - Oberon/F

3. CD-Oberon Oberon 3 Printer Problem

4. Oberon System 3 / Native Oberon projects

5. inquiry about Visual Oberon/PC Native Oberon System 3

6. Native Oberon: Getting DOS based installation out of Oberon-0

7. Oberon-2 in Native Oberon System 3

8. modula2-to-Oberon, C++-to-Oberon

9. oberon kernel sources (Article 4814 in comp.lang.oberon)

10. POLL: Interest in PC Oberon (Native Oberon)

11. Oberon-Growth-Limit was Re: Oberon: beginners questions

12. Learning Oberon or Oberon/F

 

 
Powered by phpBB® Forum Software