Cover Image
close this book Food Composition Data: A User's Perspective (1987)
close this folder Other considerations
close this folder Systems considerations in the design of INFOODS
View the document (introductory text)
View the document Introduction
View the document Staff turnover and system growth
View the document Documentation
View the document The choice of environmental and basic tools
View the document Choices of operating systems
View the document Choice of programming language
View the document User interface
View the document Data representations
View the document System architecture and linkages
View the document Stability
View the document Primitive tool-based systems
View the document Summary
View the document References

Choice of programming language

Choice of programming language

The choice of a programming language (or set of languages) usually follows that of an operating system. While there have been cases in which an operating system was chosen because it supported a particular language, such cases are rare. All things being equal, systems that can be built entirely in a single language are much easier to cope with than those that require two or three. If nothing else, use of a single language makes the management task easier, since few programmers are equally comfortable and efficient in several languages at the same time; just as with natural languages, it is difficult to "think" in more than one language concurrently, regardless of what one can manage at separate times or in different places.

Unfortunately, from the language standpoint, operating systems requirements involve procedures for data entry and recording, for locating and aggregating data, and for doing statistical computations on surveys and to construct food tables. Historically, almost all good software for screen management and data entry support has been created in or for COBOL or PL/I. By contrast, almost all of the research and development work in numerical algorithms has been done in FORTRAN and ALGO-60. While FORTRAN and ALGOL are quite suitable for computational codes, they are not suitable for systems work unless machine dependencies, assembly language subroutines, and other forms of idiosyncratic and incomprehensible code are introduced. COBOL is terrible for systems work, and not much better for numerical computation. The languages that are very good for systems work tend to be too poor or untested for serious computational work. While there are two possible exceptions, both are very large and complex as languages go, and there are allegations that they are very clumsy and hard to learn; further, they tend not to appear very often (at least in complete form( in microcomputer implementations.' The alternative, writing in assembly languages rather than relatively high-level ones, usually leads to trouble, and should not be seriously considered in building a large system with a long life expectancy. There is a third alternative in languages like BCPL, BLISS, and C that are really medium-level, nearly machine-independent assembly languages. For serious applications work, however, as distinct from systems work, they can be nearly as much trouble as assembly languages and for much the same reasons.