Íàóêà — Øêîëå
Contribution to the Joint Modular Languages Conference
(JMLC'2003, Klagenfurt, Austria, August 2003).
Published in: Modular Programming Languages. Lecture Notes in Computer Science 2789, Springer-Verlag, 2003, pp.69-77. Translation into Russian.
Fyodor V. Tkachov
Institute for Nuclear Research of Russian Academy of Sciences
Moscow 117312, Russia
A unique combination of properties makes the Oberon family of languages an ideal platform for algorithm design work in computational sciences as well as for a systematic general programming education. The project Informatika-21 builds on the strong Pascal tradition in Russia and purports to promulgate Oberon in Russian education with an ultimate goal to establish a system under which high school and university students would be universally and systematically exposed to the fundamentals of programming similarly to how they are exposed in Russia to the fundamentals of mathematics.
The educational project Informatika-21  has grown out of (i) a discovery that
programming languages from the Oberon family
hit the nail on the head in regard of the problems that plague programming in
modern physics , (ii) a realization that the design decisions behind Oberon
adequately address universal problems, thus providing an excellent foundation for a general programming
education for professionals in the fields beyond CS such as physics,
engineering, chemistry, linguistics , etc.
in physics as practiced at CERN etc., the following trends are observed:
run-of-the-mill projects increasingly require the use of two or more
conventional specialized and non-interoperable programming systems. The problem
of symbolic/numeric interface is an old example. A modern one is a web
service based on libraries of fortran and symbolic manipulation codes, managed
with a database and glued together by Java .
systems naturally evolve towards incorporating core features of a general
purpose language. The result is a duplication of this core with sometimes
strange variations and gaps
across many non-interoperable systems (cf. the above example).
is a trend towards large (100-1000 participants), long-lived (on the order of 20
years) yet volatile (students and PhD’s joining and leaving), loosely
organized international collaborations. One cannot rely on programming gurus
only: Involvement of rank-and-file physicists in software development is
necessary. Enforcement of standards such as language subsets proves to be
Even rank-and-file physicists-programmers should be familiar with elements of
large scale software design.
inflexible division of labor between programmers (even with a physics
background) and physicists proper may be detrimental for the project’s
success: the programmer may agonize over obstacles that could be circumvented by
minor changes at the level of formalism.
Vice versa, a competence in mapping formulae to data structures and algorithms
helps to focus the theorist’s work in a surprisingly productive fashion (cf.
the invention of what is considered to be the most popular family of algorithms
for one of the most important classes of calculational problems in theoretical
particle physics ). The thought patterns of algorithm design must become part
of the theorist’s problem solving arsenal.
programming is becoming physicists’ everyday instrument, and we should be able
to do it in as casual a manner, without becoming full-time programmers, as we
differentiate and integrate without becoming mathematicians. Unfortunately, such
a casual use is almost impossible with the most popular SD systems.
above trends have been manifest in the physics community but one cannot fail to
notice similar trends in other scientific fields.
made an attempt to create a common SD platform for its Large Hadron Collider
mega-project (2006-2020) by adopting C++ as a standard back in 1994. Needless to
say, C++ cannot be a half way adequate solution for the listed problems because
of its well-known critical design defects and extravagant complexity. In fact,
there is anecdotal evidence of splits in physics collaborations in regard of the
use of C++, and a number of physicists are hesitant to switch to C++ and choose
to stay with fortran. The failure of C++ is visualized, so to say, by the
CERN-developed data analysis and visualization framework ROOT , which is
notorious for segment violation crashes.
a lucid minimalism is absolutely key if the programming language is to synergize
in physicists’ brain space with all the required physics and mathematics.
The present author has been researching the subject of calculational algorithms
for theoretical physics of elementary particles since 1978 both at the level of
quantum field theory formalism and at the level of implementation of the
resulting algorithms. On the programming side, my last significant completed
project dealt with experimental data processing , another one was of a
numerical nature , and the bulk of effort goes into large-scale theoretical
symbolic manipulation ( and refs. therein). The large, “industrial” scale
of such calculations (CPU time on high end hardware measured in months; for
longer calculations it is more reasonable to upgrade hardware) makes run-time
efficiency a central consideration. A possibility to design data structures
fine-tuned for a specific class of problems and to compile significant portions
of the code can boost efficiency by many orders of magnitude compared even with
narrowly specialized conventional computer algebra systems (an example in 
shows an efficiency increase measured by a factor of fifty million). Software
evolvability is of paramount importance here due to all the experimentation with
data structures and algorithms needed to arrive at satisfactory (not to say
efficient) programs. This concerns both the level of code (static safety etc.)
and a proper design (a careful stratification, encapsulation, etc.).
considerations have eventually led me to the adoption since 1995 of Oberon
(specifically, the Component Pascal variation of Oberon-2 as implemented in the
BlackBox Component Builder from Oberon microsystems, Inc. ) for all my
algorithm design work. Oberon/Component Pascal has proved to be a superb choice
for the entire range of problems I deal with — from various flavors of
symbolic manipulation (large-scale algebra, graphs, combinatorics) to purely
numerical applications (e.g. multidimensional optimization and adaptive Monte
Carlo integration). The type safety, modularity, automatic memory management,
and a fast compiler in an unencumbered development environment capable of
running on any old PC or notebook, almost anywhere, result in a surprisingly
productive development and experimentation cycle even for purely numerical
projects to be eventually ported to fortran.
In fact, for creative algorithm design work,
especially where run-time efficiency is a top concern, Oberon transcends the
role of a mere “tool” and becomes a true brain extender.
A few years of failed attempts to find collaborators for projects based on
Oberon (despite sincere expressions of interest: my fellow theorists are too
busy debugging their fortran, C++, etc. codes; and this is less of a joke than
one might think), convinced me to start an experimental course of modern
programming techniques at the Physics Department of the Moscow State University
in the Spring semester of 2001. The experience quickly revealed that:
courses of the regular programming curriculum (which spans the first two years
and includes the usual introductory courses, a practicum, and a physics modeling
mini-project) use various programming platforms (from MathLab to C++) according
to a particular professor’s preferences.
Students waste mental capacity on learning syntactic peculiarities of archaic
systems rather than mastering the fundamentals of systematic program
construction (step-wise refinement, loop invariants, interfaces as contracts,
missing from the courses are the key notions of programming in the large
(software evolvability, interfaces, patterns, …).
short, the complexity and disparity of various programming platforms used
throughout the programming curriculum have a hugely adverse effect on what
students’ actually learn about programming.
the other hand, the lucid minimalism of Oberon/Component Pascal made it possible
to pack into a semester-long lecture course (formally similar to a standard
introductory course) a range of modern programming techniques including elements
of Dijkstra’s discipline of programming, the basic dynamical data structures,
essential OOP, COP and basic patterns (factory, carrier/rider, separation of
interface from implementation), basics of interactive graphics (MVC). The course
content could be further enriched as experience and the library of program
examples is accumulated. The duration of only one semester (16 lectures) is
dictated by extraneous circumstances and is, of course, somewhat too
restrictive: it would be better to devote a full semester to programming in the
small and another one, to programming in the large. Yet even a one-semester
course is possible (it acquired a pretty stable form towards the third edition)
thanks to the use of Oberon/Component Pascal as the foundation language.
lectures are based on program examples of increasing complexity; their subjects
are correlated with the main curriculum (math courses, physics lab practicum).
The course efficiency is greatly increased by distributing printed notes (with
complete program sources along with screenshots, excerpts from documentation and
various comments, slogans and admonitions) to students before each class. A
textbook — although a useful supplement and necessary for a wider distribution
of the course material — would be more limiting in regard of the material
presented, and a computer presentation — although sometimes irreplaceable —
would limit students’ activity in adding their own notes.
course attracted both students dissatisfied by the standard programming courses
for various reasons as well as students with a practical experience in
programming but seeking a systematic view of the subject, and also the faculty
looking to enhance personal productivity.
A correct positioning of the course was seen to be crucial in view of the
religious nature of debates around programming languages, and is currently as
Oberon/Component Pascal provides the least painful introduction into modern
programming. After learning the basics of program design in Oberon, switching to
other popular languages reduces to learning inessential (syntactic etc.) details
in the existing special courses traditionally devoted almost exclusively to such
details (fortran, C, C++).
are powerful productivity tools to take the sting out of students’ chores such
as data processing in physics labs, the practicum in numerical methods, as well
as for research assignments and subsequent individual research (we are talking
here about research in physics etc., not computer science). The latter assertion
is supported by the fact of the course attendance by the faculty.
when forced to program in other languages, following a systematic programming
style learned with Oberon mitigates their deficiencies. Students indeed reported
productivity gains and a reduced debugging agony, e.g. in a practicum on
numerical methods, with first developing their assignments in Oberon and finally
porting them to C as required.
important in the Russian context is that with Oberons, students are not limited
by the hardware at their disposal: some students only have unrestricted access
to an 486. But this proves sufficient to fully experience modern programming
but not least: Sun’s Java and Microsoft’s C# — the two languages vying for
dominance in the business software industry — have more in common with Oberon
than with their syntactic predecessors C and C++. This can be interpreted as
signifying a consensus of the software market leaders in regard of the core set
of essential features that a modern general purpose programming language must
possess — counting a (relative) minimalism as a feature. Of the three
languages, Oberon remains best suited for numerical applications (an important
argument e.g. in physics), and — owing to its superbly clean design — the
easiest introduction into what can be called the standard paradigm of modern programming. This point was nicely
illustrated by the fact of students obtaining well-paid part-time jobs involving
programming in C# after attending the first edition of the course.
A serious problem has also become evident. Namely, a number of students enter
the university with already a non-negligible experience in programming (often
from high schools with advanced curriculum in physics and math). Unfortunately,
it is either the old Pascal, Borland’s Pascal or C/C++ — taught by rarely
competent school teachers who mistake, as usual, complexity for power. Such
students are reluctant to attend what appears to them an introductory course,
opting to invest their spare time into commercial programming. And bad habits in
programming formed by inadequate training are hard to eradicate. (Note that
analogy with sports where proper techniques is essential for top achievements
sometimes works well to motivate such students to undertake the effort. The
analogy is less superficial than it may seem at first glance.)
soon as the problem of programming education at the high school level emerged,
an experimental high school course was initiated in the Fall of 2001 —
motivated partly by a necessity to ensure a flow of well-trained students,
partly by an idealistic view of the general importance of the problem.
A few remarks are in order on the subject of education system in Russia. The
disruptive economic reforms cause discussions of how to capitalize on Russia’s
strengths in basic research and education in a post-industrial transformation.
Since the educational reform of 1871 following the 1866 attempt on the life of
Czar Alexander II, a strong emphasis was placed on mathematics in the curriculum
(curiously, along with classical languages) as an antidote to propagation of
freethinking . After 1917, the education effort encompassed the entire
population with classical languages replaced by natural sciences. The education
system with a solid and universal mathematics curriculum proved to be an
excellent foundation for the development of the aerospace industry and the
schools of mathematics and theoretical physics.
natural idea then is to supplement the strong mathematical tradition with a
systematic education in programming. Indeed, IT analysts note that in the
international off-shore programming market Russia already tends to specialize in
mathematics-intensive software (cf. the projects of the Intel Software
Development Center in Nizhny Novgorod half-way between Moscow and the Urals
). Although the revenue volumes are small compared e.g. with India’s
software industry, but the dynamics is extremely positive, and such software is
less amenable to automation and its role and value is growing.
Implementation of this vision must take into account a number of circumstances
specific to post-USSR space:
hardware in most schools and homes will be precluding the use of heavy-weight
programming systems for quite a while.
poor knowledge of foreign languages in Russia and most other post-USSR republics
creates informational difficulties for teachers and students alike; on the other
hand, it creates a domain relatively less sensitive to foreign marketing
strong Pascal tradition: Pascal (various versions) remains by far the most
popular platform to teach programming in Russia. This in part is explained by
the popularity of Algol-60 in the USSR university education in the 70s (the
first systematic course of programming I took in 1976 was based on Algol-60).
That in turn was due to the influence of mathematicians who from the very
beginning advocated a systematic approach to programming and realized the
importance of the programming profession for the future (the most influential
person in this respect was A.P.Ershov ; his heritage is very much alive,
especially in Siberia where, incidentally, most of the Russian aerospace
industry is located).
army of relatively well-trained mathematics teachers from whose ranks
programming teachers are often recruited, and for whom Dijkstra’s discipline
of programming and Oberon’s regularity would have an appeal. Professional
mathematicians are often involved in teaching at high schools with extended
curricula in physics and mathematics (a system of such schools is also a
heritage of the Soviet era); cf. a textbook with many examples of systematic
algorithm construction in Pascal written by a mathematician  (incidentally,
Oberon is mentioned in the introduction as a potentially more elegant choice).
lack of guiding lines and reference points, which informatics teachers keep
complaining about. For those originally trained as mathematicians, the Euclidean
geometry would be an obvious model, and they would greet a similarly systematic
exposition of foundations of programming.
tradition in education correlates with the industrial use of Wirthean languages.
One example is a sizeable and active Russian community of Delphi programmers
. Another is the fact that all the embedded software in Russian
communication satellites is being written in Modula-2 .
view of the above, it is inevitable that Oberons should gain a popularity in the
post-USSR space. The adoption of Oberon is indeed happening in more than one
way. The research and education efforts at the Physics Department of MSU have
already been mentioned. In the aerospace industry, there is an interest in
Oberon as a natural successor to Modula-2. Since 1998 there exists a web-site
 authored by Prof. S.Sverdlov (Univ. of Vologda, some 450 km North of
Moscow) to promote Oberon for IT majors at universities;
it offers a rich selection of Oberon-related publications in translations into
Russian (notice the attention Oberon has been receiving in Russian-language
versions of IT publications such as ComputerWeekly and the PC World). Since
1999, the BlackBox Oberon is being promulgated for programming education at the
high school level by the Lithuanian Institute of Mathematics and Informatics
. Starting the Fall, 2003, the University of Osh (Kirgizia) is implementing
an experimental professional programming education program based on Oberons
These grassroots tendencies are being shaped via the project Informatika-21 
which started as a web site to serve the needs of the MSU course discussed above
and then to help spread the information about Oberon together with the high
school course material in Russian (most notably, a russification package for the
BlackBox version of Oberon including Russian-language versions of compiler
messages, instructions for the basic use, simple examples of program
development, etc.). The high school programming education space has been chosen
as a primary focus because this is where hand-holding is needed most whereas the
effect of switching to Oberon should be greatest, long-term.
has formed a board of advisors representing the aerospace industry, the Russian
Academy of Sciences, and the Moscow State University. The project is being
helped by volunteer coordinators in Siberia (Dr. A.I.Popkov) where a
considerable pool of engineering talent is located, and in Central Asia (Prof.
Kubanychbek Tajmamat oolu) where the education problems are similar to
Russia’s if somewhat exacerbated by demographics but there is more freedom for
experimentation due to less bureaucracy. Several dozen copies of the
russification package designed specifically for schools have been downloaded
from the Informatika-21 site (taking into account that a similar package for
professional developers is also available, this gives an estimate for the number
of teachers familiarizing themselves with the BlackBox Oberon). Starting the
Fall of 2003, new programming courses based on Oberon are due to begin, and
another web site is to be put up (the “Leader” Sunday school of programming
in Nizhnevartovsk; note how Sunday schools in Russia are about programming
rather than religion). Examples of other organizations where Oberon is being
evaluated for teaching purposes include the Urals State Politechnical University
(Ekaterinburg) and the Siberian Aerospace Academy (Krasnoyarsk). Publication
support has been pledged by the MSU Center of Pre-university Education.
secondary and high school programming curriculum ought to be a simplified,
follow-me version of the systematic approach to program construction to be
taught at the university level. The project’s main goal here is to accumulate
a commented collection of exemplary programs correlated with the course material
of other subjects. Also, the implications of the powerful automatic memory
management feature of Oberon are yet to be explored in the high school teaching
of programming. It may be possible, advantageous and fun to introduce dynamical
data structures much earlier than is usually done. At the age of, say, 12
kids’ very limited knowledge of math is an obstacle for using program examples
of a standard kind, whereas learning the basics of list manipulation is fun with
standard pictorial representations on the blackboard (e.g. kids’ interest is
aroused by programs manipulating information on themselves such as a lists-based
database of the class with grades, attendance information, etc.). Clearly,
Oberon opens non-trivial new possibilities for a more effective (in several
respects) course organization.
described efforts would be much facilitated by an exemplary programming textbook
as envisaged by Niklaus Wirth . Fortunately, the Oberon itself is an
excellent summary of the basic notions of computer programming and a solid
technological foundation on which to build a modern programming education
I thank Niklaus
Wirth for many comments on programming education and
Jürg Gutknecht for a constructive advice.
Project Informatika-21, http://www.inr.ac.ru/~info21/
Language Oberon, Software — Practice and Experience, 18 (1988) 671–690;
Wirth, N., Gutknecht, J.: Project Oberon: the Design of an Operating System and Compiler, ACM Press (1992)
Wirth, N., Mossenbock, H.: Oberon-2 Language Report (1992)
Oberon microsystems, Inc.: Component Pascal Language Report (2001);
Gutknecht, J.: in Proc. of JMLC'1997. Lecture Notes in Computer Sciences
1024, Springer Verlag;
Reali, P.: Active Oberon Language Report, http://bluebottle.ethz.ch/languagereport/
See e.g. F.V.Tkachov: From Novel Mathematics To Efficient Algorithms,
Bardin, D., et al.: Project SANC (2003); e.g.
F.V.: Algebraic Algorithms for Loop Calculations,
F.V., Manakova, G.I., Tatarchenko, A.F: How Much Better Than Vegas Can We
Integrate in Many Dimensions? FERMILAB-CONF-95-213-T (1995)
Tkachov, F.V.: Verification of the Optimal Jet Finder,
Kornilov, A.A.: A Course of Russian History of XIX Century, Vysshaya
Shkola, Moscow (1993)
Shen, A.: Programming: Theorems and Problems, Moscow (1995); Birkhauser
Wirth, N.: Computing Science Education: The Road not Taken, Opening
Address at the
M. and Williams, D.N.: Schoonschip
17. Cf. the
software package for linguistic studies CHRISTINE designed by the linguist
22. Koltashev, A.A.: presentation at this
For the present discussion the differences between the original Oberon ,
Oberon-2 , Component Pascal , Active Oberon , etc., are mostly
For instance, absent or rudimentary sets of standard control structures in
the symbolic manipulation systems (such as SCHOONSCHIP  and its
derivatives) that are highly popular among physicists.
As of March 2003, ROOT running on Linux would cause three segment violation
show stoppers in less than five minutes of a theorist’s demonstration of
his cosmic rays work where all one needed was to visualize positions of
various cosmic rays sources on a sky map. Another example: a highly
experienced and respected programmer changed her specialization in order not
to deal with the ever crashing C++-based software: she stated it crashes
even worse than how Soviet-made clones of IBM mainframes would require a
reboot every 15-30 minutes back in the 80s.
It is somewhat hard to quantify the productivity increase resulting from the
simplicity and safety of Oberon. As an example: it took less time to perform
all the algorithmic experimentation in Component Pascal to develop an
efficient algorithm for an optimization problem in O(2000) dimensions
reported in  (about four weeks), than to subsequently port it to
fortran. Moreover, a rounding-errors-related problem was only resolved by
switching back to CP after a failure to resolve it directly in fortran.
Prof. Sverdlov considers it a direct result of using Oberon in education
that his students’ team made its way into the 27th ACM Int. Collegiate
Programming Contest World Finals at Beverly Hills, March 25, 2003.
Íàóêà — Øêîëå