Introduction
Computer programmers often use the word scalable to describe a desirable feature of a program or algorithm. The idea is that something that is scalable not only works for very small scale jobs but is equally effective (or nearly as effective) when the job in question is much larger (or, more commonly, when the job grows from being small to being large). A trivial example of poor scalability might be an inefficient algorithm used in a prototype implementation of a program. It works fine as long as only very small data sets are being used, but it breaks down when larger data sets are used because the computation takes so much time that the program effectively grinds to a halt. This kind of scalability is well understood by any decent programmer. A different kind of scalability is represented by the architecture of a computer program. A program that can't easily be extended to cope with new requirements is called brittle, which is the opposite of scalable. Since effectively all programs that are successful grow new parts, a nonscalable program usually will require a total rewrite when the requirements change, which is very wasteful. The usual reason for this kind of non-scalability is poor design abstraction; too many fundamental design decisions have been hard-wired into the code in so many places that it is difficult to change them all without introducing lots of bugs. Many, many books have been written about good program design; a classic is Abelson and Sussman's Structure and Interpretation of Computer Programs, which covers this and much more interesting material as well and is highly recommended. But that's not what I want to talk about here. What I want to talk about is what makes computer programming languages scalable or not. I want to show that the notion of scalability is every bit as valid when applied to programming languages as it is when applied to programs or algorithms. I'll also discuss several well-known and not so well-known programming languages from this perspective and give some concrete recommendations, as well as discuss some of the social factors which hinder progress in this field.
No comments:
Post a Comment