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
http://www.inr.ac.ru/~info21/

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

1. The educational project Informatika-21 [1] has grown out of (i) a discovery that programming languages from the Oberon family[1] hit the nail on the head in regard of the problems that plague programming in modern physics [6], (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 [17], etc.

Specifically, in physics as practiced at CERN etc., the following trends are observed:

— Even run-of-the-mill projects increasingly require the use of two or more conventional specialized and non-interoperable programming systems. The problem of symbol­ic/nu­meric 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 [7].

— Specialized 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[2] across many non-interoperable systems (cf. the above example).

— There 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 problematic.

— Even rank-and-file physicists-programmers should be familiar with elements of large scale software design.

— An 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 [8]). The thought patterns of algorithm design must become part of the theorist’s problem solving arsenal.

— Systematic 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.

The above trends have been manifest in the physics community but one cannot fail to notice similar trends in other scientific fields.

CERN 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 [18], which is notorious for segment violation crashes.[3]

Clearly, a lucid minimalism is absolutely key if the programming language is to synergize in physicists’ brain space with all the required physics and mathematics.

2. 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 [10], another one was of a numerical nature [9], and the bulk of effort goes into large-scale theoretical symbolic manipulation ([8] 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 [11] 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.).

These 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. [4]) 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 mani­pu­lation (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.[4]

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.

3. 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:

— Various 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, etc.).

— Completely missing from the courses are the key notions of programming in the large (software evolvability, interfaces, patterns, …).

In short, the complexity and disparity of various programming platforms used through­out the programming curriculum have a hugely adverse effect on what students’ actually learn about programming.

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

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

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

4. 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 follows:

— 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++).

— Oberons 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.

— Even 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.

— Critically 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 with Oberons.

— Last 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.

5. 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.)

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

6. 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 [12]. 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.

A 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 [19]). 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.

7. Implementation of this vision must take into account a number of circumstances specific to post-USSR space:

— Obsolete hardware in most schools and homes will be precluding the use of heavy-weight programming systems for quite a while.

— A 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 influences.

— A 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 [20]; his heritage is very much alive, especially in Siberia where, incidentally, most of the Russian aerospace industry is located).

— An 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 [13] (incidentally, Oberon is mentioned in the introduction as a potentially more elegant choice).

— A 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.

— The Pascal tradition in education correlates with the industrial use of Wirthean languages. One example is a sizeable and active Russian community of Delphi programmers [21]. Another is the fact that all the embedded software in Russian communication satellites is being written in Modula-2 [22].

In 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 [14] authored by Prof. S.Sverdlov (Univ. of Vologda, some 450 km North of Moscow) to promote Oberon for IT majors at universities;[5] 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 [24]. Starting the Fall, 2003, the University of Osh (Kirgizia) is implementing an experimental professional programming education program based on Oberons [23].

8. These grassroots tendencies are being shaped via the project Informatika-21 [1] 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.

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

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

The described efforts would be much facilitated by an exemplary programming textbook as envisaged by Niklaus Wirth [15]. 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 system.

Acknowledgments. I thank Niklaus Wirth for many comments on programming education and Jürg Gutknecht for a constructive advice.

References

1.  Project Informatika-21, http://www.inr.ac.ru/~info21/

2.  Wirth, N.: The Programming 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)

3.  Wirth, N., Mossenbock, H.: Oberon-2 Language Report (1992)

4.  Oberon microsystems, Inc.: Component Pascal Language Report (2001); http://www.oberon.ch

5.  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/

6.  See e.g. F.V.Tkachov: From Novel Mathematics To Efficient Algorithms, http://arXiv.org/abs/hep-ph/0202033

7.  Bardin, D., et al.: Project SANC (2003); e.g. http://arxiv.org/abs/hep-ph/0212209

8.  Tkachov, F.V.: Algebraic Algorithms for Loop Calculations, http://arXiv.org/abs/hep-ph/9609429

9.  Tkachov, 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)

10. Tkachov, F.V.: Verification of the Optimal Jet Finder, http://arXiv.org/abs/hep-ph/ 0111035

11. http://www.inr.ac.ru/~ftkachov/projects/bear/dirac.htm

12. Kornilov, A.A.: A Course of Russian History of XIX Century, Vysshaya Shkola, Moscow (1993)

13. Shen, A.: Programming: Theorems and Problems, Moscow (1995); Birkhauser (2000)

14. http://www.uni-vologda.ac.ru/oberon/

15. Wirth, N.: Computing Science Education: The Road not Taken, Opening Address at the ITiCSE Conference, Aarhus (2002)

16. Veltman, M. and Williams, D.N.:  Schoonschip '91, http://arxiv.org/abs/hep-ph/9306228

17. Cf. the software package for linguistic studies CHRISTINE designed by the linguist G.Sampson: http://www.grsampson.net/RChristine.html

18.  http://root.cern.ch/

19.  http://www.intel.com/jobs/russia/sites/nizhny.htm

20. A.Ershov's archive: http://www.iis.nsk.su:81/ershov/english/

21. http://www.delphikingdom.ru/

22. Koltashev, A.A.: presentation at this conference.

23. http://www.kubanych.ktnet.kg/

24. http://www.mii.lt/