Cover Image
close this bookFood Composition Data: A User's Perspective (United Nations University - UNU, 1987, 223 pages)
close this folderOther considerations
close this folderSystems considerations in the design of INFOODS
View the document(introductory text...)
View the documentIntroduction
View the documentStaff turnover and system growth
View the documentDocumentation
View the documentThe choice of environmental and basic tools
View the documentChoices of operating systems
View the documentChoice of programming language
View the documentUser interface
View the documentData representations
View the documentSystem architecture and linkages
View the documentStability
View the documentPrimitive tool-based systems
View the documentSummary
View the documentReferences

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.