A programmer's guide to object-oriented programming in Common LISP
A programmer's guide to object-oriented programming in Common LISP
The Common LISP object-oriented programming language standard
Object-oriented concepts, databases, and applications
Common LISP: the language (2nd ed.)
Common LISP: the language (2nd ed.)
Communications of the ACM
IEEE Std 1178-1990, IEEE Standard for the Scheme Programming Language
IEEE Std 1178-1990, IEEE Standard for the Scheme Programming Language
ISSAC '92 Papers from the international symposium on Symbolic and algebraic computation
Supporting complex flight scheduling tasks using CLOS and Statice
LUV '92 Proceedings of the 1992 conference on Lisp users and vendors
| Hi-index | 0.00 |
We consider here the importance of an overall systems viewpoint in avoiding computer-related risks. According to Webster's, a system is a regularly interacting or interdependent group of items forming a unified whole. In computer systems, one person's components may be another person's system, and one person's system may in turn be one of another person's components. That is, each layer of abstraction may have it own concept of a system. We speak of a memory system, a multiprocessor system, a distributed system, a multisystem system, a networked system, and so on. A system design can most effectively be considered as a unified whole when it is possible to analyze the interdependent subsystems individually and then to evaluate, reason about, and test the behavior of the entire system based on the interactions among the subsystems. This is particularly true of distributed systems that mask the presence of distributed storage, processing, and control. At each layer of abstraction, it is desirable to design (sub)systems that are context-free, but in reality there may be subtle interactions that must be accommodated—particularly those involving the operating environment.