[Oberon] Oberon-07 Application Domain

Chris Burrows chris at cfbsoftware.com
Mon Oct 2 01:18:53 CEST 2017

> -----Original Message-----
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
> August Karlstrom
> Sent: Sunday, 1 October 2017 10:16 PM
> To: oberon at lists.inf.ethz.ch
> Subject: Re: [Oberon] Procedure variables and local procedures
> On 2017-09-30 04:42, Chris Burrows wrote:
> > I would also not attempt to use a 'crippled' language like
> > Oberon-07 to write a multi-tasking, event-driven GUI program
> running
> > on a system with 16GB of RAM.

> Except for the availability of libraries, why wouldn't Oberon-07 be
> suitable for that?

Sorry - I should have been more specific:

'Windows GUI program ...'

Such a program written in Oberon-07 would be similar to this painful example
of a Windows program written in C:


That is because the Win32 API is inextricably associated with C. 

It is so much easier to use a modern component framework (not just
libraries) like the .NET framework that is no longer constrained by having
to run on a PC with the following spec:

* 8086/8088 processor or better.
* 384 KB of free conventional memory (real mode), 1 MB (Standard Mode), or 2
MB (Enhanced Mode)
* Hard disk with 6-7 MB of free space.

To make full use of such a component framework you need to use a language
specifically designed for it e.g. Gardens Point Component Pascal for .NET,
Microsoft C#, Visual Basic etc.

There are many reasons for this - here's just one of them:

.NET was designed from the ground up to be multi-language compatible.
Component Pascal was one of seven languages selected by Microsoft during the
development of .NET to test that this requirement was met. Part of the
design of .NET that enables this to happen is the definition of  the 'Common
Language Runtime' (CLR) which defines attributes required to be .NET
language compatible. e.g. to be able to completely consume and produce .NET
items all of the following data types and their corresponding operators have
to be supported:

* Boolean 
* Byte 
* Char 
* DateTime 
* Decimal 
* Double 
* Int16 
* Int32 
* Int64 
* SByte 
* Single 
* UInt16 
* UInt32 
* UInt64  

If you are interested in learning more I can recommend two books:

1. 'Programming in the .NET Environment' by Damien Watkins, Mark Hammond and
Brad Abrams (2002). ISBN 0-201-77018-0.

  Appendix E (pp 383 - 401) describes Component Pascal on the CLR

2. Compiling for the .NET Common Language Runtime (CLR) by John Gough (2002)

  John is the author of the Gardens Point Component Pascal compiler (as well
as the earlier GP Modula-2 and Oberon compilers).

Long gone are the days when you could expect to tackle every task on a
computer using a single programming language or tool. With the astronomical
decrease in the cost of processing power and memory storage in the last
three decades since Oberon was first imagined, efficiency is now less of a
priority than productivity. 

(Having said that, there is no excuse for a clipboard manager - like one
that was recently recommended to me by a colleague - to contain 60,000,000
bytes of code!!!)

Consequently there are now specialist languages and tools for all sorts of
application domains:

Hardware description languages, 
Operating system kernels*, 
Device drivers*, 
Embedded controller software*,
Automotive applications, 
Mobile device applications, 
Windows GUI applications, 
Mathematical computation, 
Web programming, 
Financial analysis tools, 
Database processing languages, 
Data mining tools, 
Text processing languages and tools 
etc. etc. etc. 

*Oberon-07 is perfect for serious work in these domains i.e. those that
otherwise would need to be implemented in assembly language or C.

Chris Burrows
CFB Software

More information about the Oberon mailing list