Download (direct link):
The big reduction in the number of lines of handwritten code required to automate business functions also improved the quality of computer programs. They became more intellectually manageable. The opportunity for subtle error is greater when you have to write dozens of instructions for some purpose, as opposed to just a few.
3GLs also increased program longevity. The instructions used in 3GL programs were far removed from the minutiae of the native processor instruction set. If a change in hardware brought in a new processor with a different instruction set, a new compiler could process an unchanged (or minimally changed), preexisting 3GL program and generate machine code targeted to the new hardware. Changes in processor architecture no longer made programs obsolete. The ability to retarget 3GL programs to different processors became known as portability. At first portability, while nice in theory, was shaky in practice. However, over time, 3GL standards and tools matured and portability became a practical—if somewhat imperfect—reality.
Once again, all three of the viability variables changed in the right direction. A large reservoir of pent-up demand for application development was tapped. Whole new classes of applications became economically viable. It was possible to write more ambitious programs that would have been prohibitively massive in assembly language. Companies below the top tier could now computerize some of their operations, a trend that was reinforced by plunging hardware costs. Well before the end of the twentieth century, most, if not all, medium and large businesses had software applications managing at least some of their basic business operations and providing management decision support. Many small businesses were computerized as well. See Figure 1.3.
8 Chapter 1
1s and 0s
Figure 1.3 3GLs further raised the level of abstraction.
Operating Systems and the Abstraction Gap
Whereas 3GLs raised the level of abstraction of the programming environment, operating systems raised the level of abstraction of the computing platform. If a 3GL compiler has to produce detailed machine code for routine functions such as disk and display manipulation, its job is harder than if it can simply generate machine code that invokes operating system disk and display services.
Thus, by raising the level of abstraction of the computing platform, operating systems reduced the abstraction gap between 3GLs and the platform, as Figure 1.4 depicts.
Object-Oriented Languages and Virtual Machines
Inevitably, as demand for complex features and quick time to market increased, viability problems began to surface with application-centric computing, spurring efforts to improve development methods. The result was several important incremental improvements that extended the lifetime of application-centric computing.
Structured 3GLs evolved into object-oriented 3GLs, including Smalltalk and C++. These new languages make it easier to reuse parts of programs in different contexts.
Some object-oriented languages introduce an interpreter called a virtual machine that executes intermediate code generated by the language compiler. Smalltalk, Java, and C# are the prime examples of such languages. The intermediate code is processor- and operating-system-independent. Thus, implementing the virtual machine over different processors and operating systems makes it possible to port even the compiled form of applications to different computing environments. The greater portability improves application longevity.
Pressure and Progress: How We Arrived at This Point
//3GL Source Code
Machine Code with Operating System
Level of Abstraction
Figure 1.4 Operating systems narrowed the abstraction gap.
Over time the expectations of the degree of automation that computing could achieve continued to increase. It was no longer enough to have islands of automation within the enterprise. The various islands had overlapping functionality that duplicated information and applied scarce resources to solve similar problems multiple times. It became necessary to integrate the islands across the enterprise.
Component-Based Development (CBD) draws on lessons learned from industrial production processes, promoting a world where applications are assembled from interchangeable components.
Componentization moves the production process away from reinventing the same solution in different applications, thus improving productivity and decreasing the cost of production. Componentization also tends to improve quality because it isolates functionality, allowing a team to debug and upgrade the functionality in one place.
10 Chapter 1
There isn't complete agreement in the software industry on the exact definition of component, but usually the term refers to a software module that can be packaged in compiled form so that it can be independently deployed as part of applications or assembled into larger components.