JTC 1 Subcommittee 22 - "The Portability Subcommittee"
Computers come in different sizes with a vast range of
capabilities and have a wide variety of hardware and software
architectures from many manufacturers in many countries of the world.
Computer users often need to interact with applications running on more
than one of these incompatible architectures. Application portability
addresses this dilemma.
JTC 1 Subcommittee 22 has a formidable title: Programming
Languages, their Environments and Systems Software Interfaces, but it can
be thought of more simply as "the portability subcommittee." Some other
committees also address portability but for SC 22, it is our main focus.
The work of SC 22 includes standardization of programming
languages in which applications are written, standardization of operating
system interfaces which permit execution of the applications, and
standardization of the interfaces used to develop portable software
engineering tools integrated in portable development environments needed
by application developers.
Portability Benefits
Portability has two benefits that are facilitated by
standardization. First, use of common programming languages and
interfaces allows portability of people, i.e., a person's skills are
transferable from one computing system to another perhaps incompatible
system when they are both using standardized languages and interfaces.
This can be critical for programmers and analysts in today's more fluid
job market. Second, application programs can be constructed that are
usable on diverse, incompatible systems, reducing the need for
reprogramming applications for new environments. Portability is not
perfect since standards usually include some specifications that are
environment dependent and implementations may contain additional
capabilities or extensions unique to a particular environment that are
beyond those specified in the standard. Still, these benefits drastically
reduce the conversion effort that would be required if our standards did
not exist. This ease of conversion allows software creators, big and
small, to produce the same application for a variety of computer systems
with a minimized effort.
Another important benefit of standardization involves the future
maintenance of application programs. Some applications continue to be
used for many years, sometimes even decades, long after the original
programmers have departed the organization. If written using our
standards, new personnel familiar with the standards will find it much
easier to understand and to modify these applications to accommodate
changing requirements.
Program of Work
Specifically, our Program of Work includes standardization of the
following:
- Programming Languages: Ada, APL, Basic, C, C++, CHILL, COBOL, FIMS,
FORTH, Fortran, Lisp, Modula-2, Mumps, Pascal, PL/I, and Prolog;
- Formal Specification Languages: Vienna Development
Language/Specification Language (VDM/SL), Z Notation, and Syntactic
Metalanguage Extended BNF;
- Language Independent (LI) Specifications: LI Procedure Calling
Mechanisms, LI Datatypes, and LI Arithmetic;
- Operating System Interface: Portable Operating System Interface (POSIX);
and
- Program Development Environment: Portable Common Tool Environment
(PCTE).
SC 22 has also produced a number of guidelines dealing with
aspects of language standardization and a framework for
internationalization of applications.
Programming Languages - Why so many?
A common question asked is this: If standardization is so
important, why are there so many languages? Why not only one?
In the early days of programming language development, there was a
belief that the number of languages would be limited, perhaps not to one,
but at least to one for each major application area, e.g., COBOL for
business applications or Fortran for scientific applications. Over time,
however, there has been a proliferation of languages designed with
specific goals in mind, with many of them gathering an enthusiastic
following. In many cases, as the language became more popular, the
language capabilities were expanded as its proponents desired to use it
for a wider variety of applications. Programming languages are part of a
free market system -- innovation is not limited to certain specific
environments and the success of each language is determined by the
marketplace. This phenomenon does not diminish the value of standards;
development and adoption of a language standard reduces the proliferation
of "dialects" of that language in the marketplace, significantly enhancing
portability.
POSIX Activity
The most active area of standardization within SC 22 is POSIX.
Standards have been adopted for the POSIX system interface, shell and
utilities, as well as for test methods for measuring conformance to POSIX
standards. Development work continues for system administration services.
POSIX is most closely associated with the C programming language but a
standard binding for the Ada language has also been adopted. POSIX
environments have been implemented on a wide variety of information
processing systems.
Internationalization - What is it?
Internationalization is a relatively new concept that is also an
important part of portability. Internationalization refers to the process
of developing an application for users with different natural languages or
with different customs. It involves the separation of cultural
conventions, e.g., for sorting or for formatting of dates, time, money and
numbers, from the rest of the application program so that the programming
for those conventions can be easily customized for each different user
environment. SC 22 is producing both guidelines and standards for use by
application developers.
The Global Information Infrastructure
JTC 1 is working hard to develop and deliver International
Standards that meet the rapidly evolving needs of the global information
market, as has been previously reported in the ISO Bulletin. As interest
continues to grow in meeting the requirements for a Global Information
Infrastructure (GII), the portability standards produced by JTC 1/SC 22
will play an increasingly important role.
Bob Follett, chair SC22
This article appeared in "ISO Bulletin", November 1996