Оберон-клуб «ВЄДАsoft»

Твердыня модульных языков
Текущее время: 17 апр 2024, 11:20

Часовой пояс: UTC + 2 часа

Начать новую тему Ответить на тему  [ Сообщений: 5 ] 
Автор Сообщение
СообщениеДобавлено: 23 авг 2014, 12:15 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
В Лондоне есть фирма Padded Cell Software Ltd, которая активно использует язык Оберон для разработки программного обеспечения повышенной надёжности для своих клиентов, среди которых — государственные организации Англии. Об этом говорит Пол Рид в своих статьях «Building Your Own Tools - An Oberon Industrial Case-Study» и «An Oberon Linker for an Imperfect World – More Notes on Building Your Own Tools»

Эти статьи не являются публично доступными, видимо, таковы соглашения с издательством. Но я получил от Пола разрешение цитировать их частично, поэтому вот:

Paul Reed писал(а):
Summary: Our experience creating custom application software has taught us that total control over our development tools is a necessity. Project Oberon provided an excellent starting point for us to build our own cross-platform application programming environment. Our adaptation of Wirth's compiler is re-targetable at run-time via a small set of installable up-calls, enabling a single machine-specific code-generation module of typically less than a thousand lines of code. The only significant additions to the original Oberon language are floating-point binary-coded decimals and open-array variables with string concatenation (e.g. s := "Error: " + t). Accompanying run-time libraries, written in Oberon, for operating systems such as Microsoft Windows (32-bit) and MS-DOS have been developed. Several systems created using the new tools have been in use by customers for some time.

1. Introduction

We present an industrial application of Niklaus Wirth's and Jiirg Gutknecht's research project [1], the programming language [2] and operating system Oberon, which aims to retain the original's simplicity, clarity and reliability. First the motivation for developing the software is explained, and the occasionally roundabout route which led to it is described in some detail. The particular design aspects of our version of the Oberon compiler and its target run-time environment are summarised, and finally we outline the steps involved in writing a new code generator for a given machine. In publishing these experiences, we hope that others may be encouraged to take Wirth's blunt attitude to 'bells and whistles', and enjoy reliable software as a natural result.

2. Motivation

Providing working software for real customers is in most cases hard work, yet despite warnings [3] the complexity involved continues to be underestimated by the industry's practitioners. Many large, high-profile software projects fail completely - and 'small' software is often unreliable. Critics often contrast this with civil engineering, where (on the whole) bridges do not tend to collapse during construction. Considering that in software we have far more control over the properties of our tools and materials than in other branches of engineering, the phenomenon is all the more surprising.

We reject the argument that computing is still in its infancy and therefore that such failures are only to be expected - consider aviation, where through great effort and the will to create a safety culture, passenger flights were made acceptably safe by the 1930's and fatality rates were improved again by an order of magnitude by the late 1950's.

In our experience, the biggest obstacle to providing finished software is finding the time to write it. Analysing our past projects, which used the complex development tools available commercially, it dawned on us that a frightening proportion of intellectual effort and time was being wasted on installation, configuration and debugging of these tools - we estimated in one extreme case as much as eighty percent of the entire project time.

We feel that it is partly because software offers the freedom to design ridiculously over-featured compilers and other development tools (most of which are far from bug-free) that the complexity of projects can get out of hand. Wrestling with the unpredictable properties of a fault-ridden programmer's tool may be stimulating, but it is distracting, and leaves less of our mental capacity available to solve the problems in the customers' domain.

Creating simple, single-purpose tools is unfashionable because it restricts scope and flexibility; but this can sometimes actually be beneficial, reducing the sheer number of decisions to be made along the way. An example of this is the software running the tiny computer fitted to the Voyager 2 space probe, whose outstandingly successful mission inspired Wirth to begin the original Oberon project [1].

The concept of providing just enough is expounded repeatedly in Project Oberon. But what makes it unique is the presentation of the entire source code of the operating system and compiler, and extremely lucid descriptions of their design and construction, all in a single compact volume. Many excellent expositions of compiler design and compiler-writing toolkits exist, for example [4], [5]; but the emphasis is often on a general approach. Attention in the literature tends to be focused on writing a 'front-end', where statements formulated in the source language are parsed, whereas actual code-generation (the 'back end') is sometimes even left as an exercise to the reader.

Knowing that we could fall back on the source code and explanations in the book, at the beginning of 1997 we decided to start a project to build some new in-house development tools based around the hand-crafted, single-pass, recursive-descent Oberon compiler designed by Wirth.

3. Objectives

The goal of our project was a simple, portable application programming environment gained in a reasonably short time scale.

Simplicity was essential in order to ensure a complete understanding of the tool on which we were totally reliant. This avoids being in the position, when developing software systems for customers, of blaming tools like bad workmen. There is also usually a need to maintain and adapt software long after it has been created, and our compiler tool would not be exempt from this.

Several different machines and operating systems, including at least Microsoft Windows (32-bit) and Apple Macintosh, would need to be supported. So the compiler would need to be portable, generating code for more than one processor chip (at least Intel 80386 and Motorola 68000 respectively).

The third requirement was that the programming of the tools should not be an undue distraction - either during their construction or afterwards. We had no intention of becoming a development tools company, spending large amounts of time on the maintenance of our compiler for each machine platform - we wished actually to use the tools.

Конечно жаль, что статьи недоступны полностью (хотя если поискать... ;) ), но ясно, что Пол Рид и его команда не считают Оберон-технологии такими уж маргинальными. Да и вообще складывается впечатление, что те, кто это утверждает, предпочитают больше аппелировать к эмоциям и устоявшимся мифам, чем к реальному состоянию дел. Конечно это нетипично, что коммерческая фирма использует Оберон. Но отнюдь не все фирмы, которые это делают, об этом активно рассказывают.

Вернуться к началу
Ответить с цитатой  
СообщениеДобавлено: 23 авг 2014, 12:22 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
Ещё пример: австрийская фирма Software Templ OG (список проектов). Я недавно впечатлился, прочитав статью о проекте FFF97.

Josef Templ писал(а):
(1997) We have developed a turn-key enterprise solution for the Austrian Fund for Industrial Research (FFF, renamed to FFG meanwhile) in Vienna. The solution covers all aspects of office automation inluding book keeping, reporting and money transfer. It interacts with standard components such as electronic banking software, book keeping software etc. We are still involved in maintaining this solution and adapting it to ever changing requirements. The FFF97-project is based on the BlackBox Component Builder from Oberon microsystems. An article about this project has been published in "The School of Niklaus Wirth" by dpunkt.verlag, Heidelberg.

Josef Templ писал(а):

The Oberon programming language and system, subsequently called the Oberon
technology, are well known in the software research community. Few applications,
however, exist outside academic institutions. This paper describes one of them
(FFF97), which constitutes a database front end application that has been in
mission critical use by more than 25 concurrent users since 1998. FFF97 makes
full use of Oberon’s innovations including dynamic loading, commands, garbage
collection, type extension, integrated text and form system, component
technologies, model/view separation, low resource consumption, etc. It is claimed
that choosing the Oberon technology and a particular approach to software
construction, known under the term ‘Prototyping’, was of vital importance for this
project, which, as one of the rare examples of custom software development
projects, was completed within the scheduled time and budget without
compromising quality or functionality.

1. Introduction

The successful application of research results to real world problems can be considered
the ultimate justification for spending money on pure research and as a proof of the
correctness and relevance of the research results. In the field of software engineering, one
controversial research project was the Oberon project [1], carried out by N. Wirth and J.
Gutknecht at ETH Zurich starting in the late 80s. Many computer professionals still doubt
the advantages and relevance of this technology because it started from scratch and
ignored industry standards, and because it appears to be too simple to compare favorably
against industry standard technologies. This paper describes the story of FFF97, a
database front end application based on the Oberon technology, that has been in mission-
critical use by more than 25 persons since 1998. FFF97 embodies a perfect example of
applying the results of the Oberon project to the real world, not because it shows that the
problem could equally well be solved in Oberon, but because it shows that the problem
could better be solved in Oberon. In fact, we are not aware of any other system that would
have been suited better to this particular task.
In the following chapters we will describe the application domain, the chosen approach
to software development, the rationale for choosing the Oberon technology, architectural
and implementational aspects of the developed system. We will also present a summary of
vital points and some general remarks.

Josef Templ писал(а):
15. Summary of Vital Points

Let us now summarize the points which we believe were vital for the success of the

    • Prototyping turned out to be possible to circumvent the writing of detailed
    specifications, which nobody is able to accomplish for a complex project. It depends,
    however, on efficient tools and the close cooperation of all participants. The short
    feed-back loop avoids developments in the wrong direction, so we never had to throw
    away big pieces of work. Without an Oberon style IDDEE tool, we believe, it would
    have been impossible to achieve the required number of development cycles.

    • Error avoidance is of vital importance for a prototyping approach, since long
    debugging times simply cannot be afforded. Oberon’s approach of using an airtight
    type system and automatic garbage collection turned out to be an invaluable asset
    even in the world of commercial data processing. The procedure activation stack
    dump provided in case of a runtime exception and the possibility of inspecting global
    variables were sufficient for debugging logical errors. This is, by the way, more than
    one gets in traditional IDEs, since Oberon does not need to make a distinction
    between release (without debugging) and debug version.

    • Efficiency of the resulting programs in terms of time and memory consumption can
    only be achieved with a compiled general purpose programming language and
    reasonably designed libraries. Both is the case with BlackBox, which made it possible
    to run the application on i486/33Mhz with 16MB main memory. It is still an
    advantage after switching to bigger PCs, because it allows the user to start more than
    one FFF97 process or other office tools in order to perform certain parallel tasks. It is
    also an advantage when working offline on a Laptop, which must host a database
    server locally. A small disk footprint is also an advantage when starting a program via
    a network from a central file server.

    • Oberon’s dynamic loading strategy turned out to be of three-fold benefit to us: (1) it
    avoids the extra linking step during development, (2) it allows the application to be
    installed on a central file server and to be loaded incrementally with almost
    unnoticeable loading delays even on a 10Mbit network with about 30 active users, FFF97 13
    and (3) it allows us to maintain and update the system incrementally via remote
    access over a single 64 Kbit ISDN line.

    • Text integration pioneered by the original Oberon project and continued by BlackBox
    turned out to be at the very heart of our application. A simple SCP report generator
    needed just a few weeks of coding and allowed us to create text templates for a broad
    range of applications including reports and letters with little effort and great

    • Meta-programming support in BlackBox introduces many features of 4GL
    programming systems and allows a tight integration of the program with databases
    and user interface components. There is no extra coding required and there is also no
    code generator involved.

16. Concluding Remarks

The following contains some thoughts about lessons learned during the course of the
FFF97 project. Some of the points are actually statements made by Prof. N.Wirth that
proved to be more than true in practice.

    • “Keep it as simple as possible, but not simpler” (Einstein, often quoted by
    Wirth) is especially important in a prototyping approach in order to be flexible
    enough to incorporate additional or deviating needs. Whenever it is unclear
    what the user really needs, do not invest a big effort in a preliminary solution.

    • A user interface should be created using visual design tools, not by means of
    lengthy statement sequences. There is no need for a code generator within such
    a form editor, which simplifies development and the development system
    significantly. It also provides a clear separation of concerns, GUI design on the
    one hand and functionality behind the buttons on the other. Programmed user
    interfaces are only justified in exceptional cases, where dynamic layouts are

    • The lack of static typing in the database world constitutes a major problem for
    client applications whenever the data model needs to be changed. It is
    impossible to test all dependent programs systematically. With the common
    approach of using dynamic SQL inside a general purpose programming
    language, this situation cannot be expected to change in the near future.

    • Modern database systems and programming interfaces exhibit a degree of
    complexity that is hard to digest for someone used to the simplicity of the
    Oberon system. Most of the complexity stems from irregularities and
    exceptional cases that would better be omitted from the specifications. This
    might free some resources for introducing higher level concepts such as types
    and type extension into a database management system, which is still a long
    way off.

    • Wasting resources is never a good idea even if the resources appear to be
    unlimited, as is the case with disk space nowadays. With a highly normalized
    data model and compact representation of text documents we were able to fit
    the database into less than 160 MB, a small fraction of a modern hard disk.
    There are advantages, though. Backup is fast and our database fits almost
    entirely into the main memory of a modern server computer, where 256 MByte
    and more are the norm. The same argument holds for every level of the memory

    • Compiler construction is at the very heart of computer science. Even in a
    commercial data processing application, one can make good use of a simple
    language and a recursive descent parser as can be seen by the SCP example.
    Custom software projects such as FFF97 are always at the technological limit.
    With improved hardware and software technology user expectations are raised,
    because standard software created with thousands of man-years raises the
    standard of comparison to new heights. Keeping up to those expectations is
    everything but easy considering the limited development resources for custom

    • What a user wants is not always what a user needs. Taken literally, the wishes
    formulated by users range from trivial to unsolvable. They often include how to
    do it, based on a particular idea, and not only what to do. It is the developer’s
    task to find the intersection of realizable and powerful concepts, which in many
    cases deviates significantly from what the user originally wanted.

    • Sometimes the user is not able to distinguish between “always” and “often” and
    between “never” and “seldom”. This can easily lead to oversimplifications that
    do not take exceptional cases into account.

    • Oberon microsystems Inc. did an excellent job of hiding the complexities of the
    Windows API and preserving the spirit of Oberon in a Windows environment.
    There are some points left to be improved (e.g. advanced GUI interface
    elements), of course, which are mainly due to limited manpower. The
    complexities and irregularities of the Windows API make it difficult to integrate
    Windows services and components seamlessly with a reasonable effort.

    • The FFF97 project would certainly not have been possible in 1996 and would
    still not be possible in 2000 with the much hyped Java technology. Although
    Java resembles Oberon in some aspects (e.g. garbage collection, strong typing),
    its library is far from being useful for this kind of application. It would require
    at least five times the memory, execution time, development effort and program
    startup time, let alone the unsolved problem of text integration and printing.

fff97.png [ 153.21 КБ | Просмотров: 13156 ]
Вернуться к началу
Ответить с цитатой  
СообщениеДобавлено: 26 авг 2014, 19:42 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
В связи с Оберон-технологиями будет уместно также упомянуть фирму CFB Software. Среди её проектов есть среда разработки Astrobe (Embedded Development System for ARM7, Cortex-M3 and Cortex-M4 Microcontrollers) на языке Oberon-07, а также CPIde (An Integrated Development Environment for Component Pascal for .NET).

cpide.png [ 76.55 КБ | Просмотров: 13153 ]
Вернуться к началу
Ответить с цитатой  
 Заголовок сообщения: День Оберона в Москве - 2014
СообщениеДобавлено: 13 ноя 2014, 03:28 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
Кто там интересовался промышленным применением Оберон-технологий? Ну так вот. Видео с мероприятия «День Оберона в Москве - 2014». И если посмотреть вдумчиво — становится ясно, что эти ребята — не полоумные фанатики и не оригиналы без крыши. Иначе им бы просто никто не доверил разрабатывать софт для АЭС. Они прекрасно разбираются в IT-технологиях, и, в отличие от меня, знают не только плюсы, джаву и шарпы с дотнетами, но ещё и Rust, Go и прочие Lua. Они применяют Оберон совершенно сознательно, поскольку понимают его преимущества для своих проектов. А они не в том, чтобы завтра слезть с Оберона в пользу удобных компонентов для отчётов в C#, а в том, чтобы не переписывать завтра систему заново на другом языке. А подтянуть Оберон к своей системе. Под новый процессор или новую ОС. Да мало ли...

Встреча поклонников языков программирования семейства Оберон

Дмитрий Викторович Дагаев. Доклад №1: Коммуникационное ПО на языке Оберон для автоматической системы сбора данных на втором энергоблоке Ростовской АЭС.

Евгений Анурин & Павел Маркин. Доклад №3: Автоматизация медицинской лаборатории

Иван Александрович Кузьмицкий. Доклад №6: SDL2.0 как дополнительный слой для портирования Блэкбокса

Интересны конечно и другие доклады, но эти более "промышленные".

Ребята, спасибо всем, кто снимает такие материалы и способствует их распространению. Факт разработки серверного софта для АЭС — весьма сильный аргумент в пользу промышленного применения Оберон-технологий. И вообще — интересно было! :)

Дмитрий Дагаев, Вы там упоминали про то, что Ofront требует доработки. Так вот, сейчас я этим как раз занимаюсь. :) Оберон-среда для разработки на базе усовершенствованного Ofront — это и есть проект XDev. Со временем думаю переплюнуть XDS. И по качеству кода, и по мультитаргетности.

Вернуться к началу
Ответить с цитатой  
СообщениеДобавлено: 13 ноя 2014, 16:52 
Не в сети

Сообщения: 22
На первом блоке (не втором) все серверное прикладное ПО "черного ящика", включая коммуникационный пакет и систему сбора данных реализовано на Обероне-2.

Олег! Упоминал я и Ofront, портировать под него стал после ознакомления с материалами Вашего сайта.

Вернуться к началу
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 5 ] 

Часовой пояс: UTC + 2 часа

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 7

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Создано на основе phpBB® Forum Software © phpBB Group
© VEDAsoft Oberon Club