Dron написал(а) ...
Совместимость - это вообще тормоз!
Вообще ни на какой совместимости зацикливаться не надо. а программы должны быть просты... тогда их и менять будет проще. (под новые требования реали)

Chapter Five; The Programmer's Guide написал(а) ...
5.1 Introduction

Programming with the Oberon system involves extending the Oberon run-time environment. The reader familiar with programming will equate programming with writing a program. Once completed, the program is run. The program requests input data, does some calculation, and then outputs the result. This may happen many times until the program terminates and releases the resources it used.
In Oberon, there are no programs. Programs are relics of the days when computers had little memory and other resources. Programs wait in line until the user decides to execute them. After termination, the program removes itself from memory to make space for the next program. Communication between different programs running at different times takes place by storing a message in non-volatile storage (a file for example). Today however, computers have more memory and programs routinely run concurrently with each other. This is called multi-tasking. The computer resources are shared between all running programs. Unfortunately, communication between different programs has not progressed much further than in the earlier days of batch processing, which makes the cooperation and integration of different programs a difficult task.
The reason for this state of affairs can be traced back to the technology used for writing programs. If a program were unsafe, that is, doing the wrong thing, it could damage the integrity of the system, and thus negatively influence the other programs running on the computer. Most of today's programming languages allow the programmer to write (knowingly or unknowingly) programs that crash the system when run. Rather than solving the problem at its root (i.e. the bad programs), software systems started using the concept of memory protection. Using memory protection, a program is encapsulated in a "shield", preventing other programs from damaging it. Sadly enough, a memory protection shield also prevents easy communication with a program, thus hindering integration and cooperation between different programs.
In contrast, the Oberon system is an example of an open and extensible system. Open means that a high level of cooperation, integration and re-use of code between applications is practised. Extensible means that anybody can add a new part to the Oberon system. This new part might be using a part somebody else added, or might be used itself by another part added later. To achieve this flexibility, Oberon does away with programs completely. Instead, Oberon provides two concepts: modules and type safety .

Modules.An Oberon module contains (part of) the executable program code of an Oberon application. Modules are typically much smaller than programs, and an application often consists of more than one module. The modules of all activated Oberon applications share the memory of the Oberon system. There are no barriers between modules of different applications. Once loaded into memory, a module normally remains there until the computer is switched off. A module X may use (or re-use) the code contained in other modules A, B, C, etc. We say that module X imports modules A, B, C, and that module X is a client of modules A, B and C. Because a module is always visible to other modules (when in an import relationship), a large level of code or module re-use is possible. That means that applications can share useful modules between each other. For example, the Oberon system provides modules for managing text, bitmaps, data compression, network communication like file transfer and e-mail. These and other modules are often shared between different applications. The set of modules loaded into memory form the module hierarchy. The Oberon module hierarchy is a directed acyclic graph (DAG), in other words, no recursive imports are allowed.
But how do modules get into the computer memory in the first place? The Oberon system contains a module loader that can dynamically load and link a module into the running system. All imported modules are loaded automatically if they are not loaded into memory already. Instead of running a program, Oberon allows you to execute a command located in a module. A command is nothing more than a procedure located in a specific module, that is, a command M.P results in procedure P of module M being called. Thus, executing a command will result in a module being loaded into the system (from disk) by the module loader. The module typically remains in memory until the computer is shut down or until it is freed explicitly by the user.

Type safety.To prevent a module from corrupting the system, a danger in such an open arrangement, the Oberon programming language provides type safety. Type safety guarantees that a module cannot do bad things (by mistake or on purpose) to the system and to other modules. This is accomplished by a strong typing system in the Oberon language, and by checking the correct use of modules by the Oberon compiler. Each module provides additional functionality to the Oberon system, the use of which is determined by the module's interface or definition. The interface of a module tells us what components of a module are visible to the outside world (i.e. to the other modules in the system).
We say that these components are exported from the module. Type safety ensures that only these components and nothing more can be accessed by client modules. This allows the Oberon programmer to hide implementation details behind module interfaces and so ensure that private data structures can not be altered from outside the module. The value of type safety should not be underestimated. It protects the system and the programmer in a world of hundreds of cooperating but also at times menacing modules.
How do modules communicate with each other? As expected, one module can call the exported procedures of other modules directly. Another powerful technique is to share data structures between modules. In Oberon, all dynamically allocated memory is shared by modules in the so-called heap. Type safety ensures that only valid references to memory allocated on the heap are passed as pointers from one module to another. In fact, this is the basis of much of the run-time behavior of the Oberon system. We can imagine the heap to be a large database of collective data. Activating a command causes a module to transform data in the database, the result of which is again inserted into the database. This is a powerful way for applications to communicate directly without barriers, and even for applications to influence each other. As an example we can write a module containing a command that colors all the occurrences of the word "and" in a text document in red - simply by directly accessing the abstract text data type of a text document. In a similar way, we can add new functionality to all Oberon applications.
In conclusion, it should now be clear that Oberon has an advantage over other systems when it comes to integrating different applications with each other, protecting the system from the user (or the user against himself), supporting the ordered re-use of code, and constructing applications rapidly from prefabricated building blocks. The remainder of this chapter will enable you to do so yourself.

В Обероне сделано ещё проще - там нету программ.

Dron написал(а) ...
А иначе это были бы модулисты и язык модулирования,
Или объектисты и язык объектирования.

Dron написал(а) ...
Если есть программисты, и язык программирования, знгачит есть и программы...

Dron написал(а) ...
Программа - это вовсе не синоним exe файла...

Программа - понятие абстрактное...

3.4 Активизация операций

Другим примером, иллюстрирующим нашу стратегию, будет активизация операций. В Обероне выполняются не программы а, отдельные процедуры экспортируемые из модулей. Если некоторый модуль M экспортирует процедуру P, то P может быть вызвана простым указанием на строку M.P, присутствующую в любом видимом на экране тексте - то есть с помощью позиционирования курсора на строку M.P с последующим щелчком клавишей мыши.

Программа - это обычно нечто законченное, ограниченное и standalone.

Dron написал(а) ...
Если это не запуск - то я балерина.

В Обероне выполняются не программы а, отдельные процедуры экспортируемые из модулей.

captain cobalt написал(а) ...
динамическая библиотека - это программа?

Freeman написал(а) ...
Это слишком низкоуровнево и не типизировано, поэтому не может быть объектно-ориентированным. Для меня всегда это было фактом. Теперь даже на Вирта сослаться могу.

Freeman написал(а) ...
Вот тут не понял. А что должно быть - текстовая совместимость?

Freeman написал(а) ...
Есть мнение, что текстовые протоколы UNIX возникли как следствие недостаточно проработанной концепции двоичных контейнеров. На сегодняшний момент - еще один тормоз на пути прогресса.

Freeman написал(а) ...
Объекная система, спроектированная одним человеком, с четкой концепцией, и все такое. Но не хватает чего-то...