Re: [dev] Project Oberon

From: Paul Onyschuk <blink_AT_bojary.koba.pl>
Date: Fri, 21 Mar 2014 15:50:15 +0100

On Fri, 21 Mar 2014 13:18:45 +0100
FRIGN <dev_AT_frign.de> wrote:

> I honeslty never heard of Project Oberon and I now read into the topic
> a bit more to find out. What bugs me is the fact Oberon is an object
> oriented programming language.
> This concept has already been discussed a lot on this ML and even
> though I can't speak for everyone, I prefer using procedural ones.
> However, considering how little time I spent reading into the
> language, I'm open for corrections.

OOP is very limited in Oberon, to the point where some folks don't
consider it an object oriented language at all. It is still procedural
Pascal-like language with some features borrowed from OOP (type-bound
procedures and type extensions). I would expect Algol-like syntax
(begin-end instead of curly braces and capitalized keywords) gaining
more negative response than that.

In book "Programming in Oberon" (I linked it in previous message) there
is a section at the end describing OOP (Wirth is mildly bashing
Smalltalk there). I found decent quote, where Wirth describes his take
on OOP [1]:

---
NIKLAUS WIRTH:
Many people tend to look at programming styles and languages like
religions: if you belong to one, you cannot belong to others. But this
analogy is another fallacy. It is maintained for commercial reasons
only. Object-oriented programming (OOP) solidly rests on the principles
and concepts of traditional procedural programming (PP). OOP has not
added a single novel concept, but it emphasizes two concepts much more
strongly that was done with procedural programming. The fist such
concept is that of the procedure bound to a composite variable called
object. (The binding of the procedure is the justification for it being
called a method). The means for this binding is the procedure variable
(or record field), available in languages since the mid 1970s. The
second concept is that of constructing a new data type (called
subclass) by extending a given type (the superclass).
It is worthwhile to note that along with the OOP paradigm came an
entirely new terminology with the purpose of mystifying the roots of
OOP. Thus, whereas you used to be able to activate a procedure by
calling it, one now sends a message to the method. A new type is no
longer built by extending a given type, but by defining a subclass
which inherits its superclass. An interesting phenomenon is that many
people learned for the first time about the important notions of data
type, of encapsulation, and (perhaps) of information hiding when
introduced to OOP. This alone would have made the introduction to OOP
worthwhile, even if one didn't actually make use of its essence later
on.
Nevertheless, I consider OOP as an aspect of programming in the large;
that is, as an aspect that logically follows programming in the small
and requires sound knowledge of procedural programming. Static
modularization is the first step towards OOP. It is much easier to
understand and master than full OOP, it's sufficient in most cases for
writing good software, and is sadly neglected in most common languages
(with the exception of Ada). 
In a way, OOP falls short of its promises. Our ultimate goal is
extensible programming (EP). By this, we mean the construction of
hierarchies of modules, each module adding new functionality to the
system. EP implies that the addition of a module is possible without
any change in the existing modules. They need not even be recompiled.
New modules not only add new procedures, but - more importantly - also
new (extended) data types. We have demonstrated the practicality and
economy of this approach with the design of the Oberon System.
---
> Now, looking at the Oberon Operating System, there definitely are some
> similarities.
> However, and that's where I see the big problem, this system doesn't
> comply with the set of common POSIX-standards and thus would require
> huge changes or even complete rewrites of basic software we use every
> day.
> I don't say every free operating system should be unix-like (hell, I'm
> open for new concepts!), but it sure makes it a hell lot easier to run
> a big set of software on it with relatively little work.
Oberon is older than POSIX, so no surprise there.  I find refreshing
than 80 years old professor is still advocating system, so radically
simple that it can be called primitive: flat filesystem without
hierarchy, no preemptive multitasking etc.  In many ways originality of
Oberon can be only matched by Chucks Moore's ColorForth.
I don't plan to do anything significant or serious with Oberon.  Yet I
think it can be a great source of inspiration.  Oberon doesn't provide
interactive command line interface or pipes, yet it can get away with,
since it still text based.  Command typically creates new window with
text output, this text can be selected and another command can be
executed consuming selection and so on.
Even if it's only a mere curiosity, reading "Project Oberon" book can
be worthwhile.  There aren't just that many places, were clarity and
simplicity of software are celebrated.
[1] http://www.eptacom.net/pubblicazioni/pub_eng/wirth.html
-- 
Paul Onyschuk

Received on Fri Mar 21 2014 - 15:50:15 CET