Abstract The BLISS programming language was invented by William A. Wulf and others at Carnegie‐Mellon University in 1969, originally for the DEC PDP‐10. BLISS‐10 caught the interest of Ronald F. Brender of DEC (Digital Equipment Corporation). After several years of collaboration, including the creation of BLISS‐11 for the PDP‐11, BLISS was adopted as DEC's implementation language for use on its new line of VAX computers in 1975. DEC developed a completely new generation of BLISSs for the VAX, PDP‐10 and PDP‐11, which became widely used at DEC during the 1970s and 1980s. With the creation of the Alpha architecture in the early 1990s, BLISS was extended again, in both 32‐ and 64‐bit flavors. BLISS support for the Intel IA‐32 architecture was introduced in 1995 and IA‐64 support is now in progress. BLISS has a number of unusual characteristics: it is typeless, requires use of an explicit contents of operator (written as a period or ‘dot’), takes an algorithmic approach to data structure definition, has no goto, is an expression language, and has an unusually rich compile‐time language. This paper reviews the evolution and use of BLISS over its three decade lifetime. Emphasis is on how the language evolved to facilitate portable programming while retaining its initial highly machine‐specific character. Finally, the success of its characteristics are assessed. Copyright © 2002 John Wiley & Sons, Ltd.

This presentation describes the simultaneous development of Bliss compilers for three machine architectures. A highly unusual combination of characteristics makes this development of general interest to the software development community: the development involved extensive sharing of code among the several compilers; involved bootstrapping and transportable programming using a machine-oriented systems implementation language; involved prototyping and subsequent evolutionary development; and involved developing software on, as well as for, three machine architectures. The unusual problems that arose are discussed and the methodologies for dealing with them are described. This experience should be of interest to others contemplating projects with similar characteristics. It should also be relevant to research in the area of software development environments as an example of the diverse needs to be met.