
Oberon-2, a high performance alternative to C++ (1996) - open-source-ux
http://www.modulaware.com/mdltws.htm
======
codr4life
I spent 13 years doing Object Pascal full time and wrote plenty of Modula-3 in
school. From my perspective, everything from Wirth suffers from having too
much syntax and focus on perfect abstractions, while not providing enough rope
when "perfect" isn't perfect enough. I have similar experiences from Eiffel,
it's all fine as long as you're solving the kinds of problems that the authors
had in mind. Everything that can be done in these languages can be done in
more pragmatic languages like C/++/Lisp; and as an added bonus, they don't
pretend to know everything about the problem you're solving.

------
open-source-ux
Such a shame that Oberon-2 never took off. It has a refreshing simplicity and
a small, compact set of features.

The OOP implementation is easy to understand and is grounded in existing
concepts like the record type and procedures, rather than inventing and
supporting a new vocabulary.

It feels like a practical and pragmatic language too: if you want to simply
write procedural code, you can do that easily without having to use the OOP
features (shock, horror).

That practical, pragmatic aspect of the language reflects Wirth's own beliefs.
Here is an interview from 1997 where he says:

> "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."

From:
[http://www.eptacom.net/pubblicazioni/pub_eng/wirth.html](http://www.eptacom.net/pubblicazioni/pub_eng/wirth.html)

