Group: object-oriented programming
Group: requirement specification
Topic: abstraction in programming
Topic: application generator
Topic: aspect-oriented programming
Topic: design for change
Topic: design pattern
Topic: function library
Topic: information hiding
Topic: language flexibility
Topic: programming with a database of modules
Topic: pseudocode design
Topic: object-oriented templates and containers
Topic: scripting language
Topic: software components
Topic: software management
Topic: software portability
Topic: Thesa as a database of modules
Topic: type inheritance as reuse
Topic: understanding systems
Topic: user-centered operating system
| |
Summary
Many difficulties of programming and software management can be attributed to non-reusable programming. Almost all programs must be built from scratch. The result is duplication of effort, unpredictable development, massive documentation, poor readability, and untested programming. A language goal is reusable programming which produces simple, tested software usable in many applications. Such software provides amplification of programming effort by building on previous work, easy manipulation of details, and effective channels for communicating program ideas. Details once specified and implemented would then be ignored and forgotten.
In traditional systems program code was shared in commonly called programs to reduce total program size. Such code is not reusable since it depends on the calling context. Instead reusable code evolves from clean, bottom-up design and is atomic to the top-down designer. He uses this code to build simple tree structures which do not share components. (cbb 5/80)
Subtopic: reuseability
Quote: the future is like the past [»weinGM_1975]
| QuoteRef: smitDC6_1975 ;;35 Picasso, Pablo: "to copy others is necessary, but to copy oneself is pathetic"
| Quote: engineers limit the amount of innovation in a design by recycling; increases safety [»demiRA_1977]
| Quote: modern engineering practice rests on a bedrock of reusable things such as I-beams; programming does not [»gordRM3_1990]
| Quote: software tools are reusable resources like capital goods; capital is then reusability [»wegnP7_1984]
| Quote: instead of researching abstract interfaces ought to study source code to find out what makes programs easier to reuse [»weisM11_1987]
| Subtopic: reuse is important
Quote: programmer productivity has not improved because every line is handcrafted; newer techniques only make it more so [»alfoM_1980]
| Quote: it is important to create reusable artifacts rather than transitory ones [»wegnP7_1984]
| Quote: software engineering will remain a craft until able to develop building-block software [»fairRE_1985]
| Quote: computer scientists stand on each other's toes [»wulfWA4_1974]
| Quote: during alchemy, compounds were primitive; like software modules in reuse of software [»alfoM_1980]
| Quote: at Bell Labs a tremendous amount of similar software is written for each of a hundred general purpose computers [»mcilMD10_1968]
| Quote: with traditional software, a system is not made of discrete components; and if discrete components exist, they are not used elsewhere [»stroB_1991]
| Subtopic: reuse as social
Quote: reuse is a social phenomenon: it must work, be comprehensible, be supported, be economical, co-exist with other software, and be found [»stroB_1991]
| Quote: reuse works only if someone takes the responsibility; use a standard components group [»stroB_1991]
| Quote: promotion of software reuse failed due to lack of participation [»potoTE10_1999]
| Quote: design patterns are reusable experience; building blocks for more complex design; microarchitecture [»gammE7_1993]
| Subtopic: abstraction as reuse
Quote: abstraction is the essential feature of reuse; otherwise can't tell what an artifact does or how to use it [»krueCW6_1992]
| Quote: a generalized component should be seen as an operation of an abstract machine; internals are inaccessible [»jackMA_1975]
| Quote: a reuse technology must provide natural, succinct, high-level abstractions that describe artifacts by what they do [»krueCW6_1992]
| Quote: in an ideal reuse technology, quickly select, specialize and integrate abstract specifications; for any application domain [»krueCW6_1992]
| Quote: in an ideal reuse technology, automatically translate abstract specifications into an executable system
| Quote: large-scale reuse can't be based on source code; need external, abstract properties [»meyeB9_1990]
| Quote: most reusable techniques are abstractions of implementing applications
| Quote: very high level languages use a mathematical abstraction that is both executable and effective for software development; e.g., sets in SETL [»krueCW6_1992]
| Quote: data abstraction allows abbreviation, code sharing, and reuse; like subroutines [»parnDL3_1976]
| Quote: a functionally strong module performs only one generic function, like square root; highly reusable [»joneTC4_1979b]
| Quote: component reuse is most successful in application domains with "one-word" abstractions such as sine and matrix multiply; universally understood [»krueCW6_1992]
| Subtopic: specification as reuse
Quote: formal methods should improve reuse; they clearly state requirements with high component integrity without implementation bias [»boweJP4_1995]
| Subtopic: patterns as reuse
Quote: the benefits of automatic programming are from the reuse of knowledge about cliches [»richC8_1988]
| Quote: a programming cliche is a skeleton which doesn't change, a set of roles which do change, and constraints on what can fill the roles [»richC8_1988]
| Quote: the name of a stereotypical program plan is an explicit label for a structure that will be used repeatedly
| Quote: usage cliches should be given first class syntactic status in programming languages, databases, and knowledge representation [»ridjD6_1983]
| Subtopic: identifying reuse
Quote: behavior samples of 12 inputs identified relevant subroutines (compatible interfaces); use for automatic, reuse retrieval [»podgA7_1993]
| Quote: premature commitment -- avoid making a decision before there is information to do so [»joneSP8_2003]
| Subtopic: library as reuse
Quote: different problems solved by automatic calculating machines share many parts in common; develop a library [»wheeDJ6_1949]
| Quote: reuse successful for system libraries, numeric libraries, and window management; fixed set of fully-specified data types and interfaces [»dehnJC4_1998]
| Quote: libraries are limited by specific resources (e.g., heap objects for malloc) and multiple interfaces (e.g., container operations for ordered vs. unordered collections) [»voKP2_2000]
| Quote: discipline and method libraries define resource requirements and resource management independent of code; one library for many purposes; e.g., vmalloc, sfio, cdt [»voKP2_2000]
| Quote: disciplines capture resource requirements in an abstract data structure; e.g., regions for memory management [»voKP2_2000]
| Quote: library methods represent an algorithm or policy on a handle; for example vmbest, vmpool, vmlast, vmdebug, vmprofile for memory management
| Quote: to use a GP library, need a catalogue of written descriptions for each routine [»randS_1957]
| Quote: since a GP library changes rapidly, need to be able to read as well as write routine descriptions [»randS_1957]
| Subtopic: data type as reuse
Quote: user-defined data types improve data portability between systems; helps reduce the amount of program rewriting [»parnDL3_1976]
| Subtopic: copying, prototype as reuse
Quote: Self showed that copying (i.e., prototypes) was a unifying basis for programming [»edwaJ10_2005]
| Quote: reuse existing spreadsheet code by creating a user-defined function; low-cost and low-risk
| Subtopic: bottom-up vs. top-down reuse
Quote: common subroutines from bottom-up design are reused; those from top-down design are for optimization [»jackMA_1975]
| Quote: generalized components are only created by bottom-up design [»jackMA_1975]
| Quote: part of stepwise refinement is using subproblems for which you already have canned solutions [»soloE9_1986]
| Quote: low cost implementation allows design problems to be turned into many independent decisions [»simoC12_1976]
| Quote: application developers should assemble or reuse code; without using a facility to write code [»mariB5_1996]
| Quote: break a problem into subroutines; this simplifies the problem and creates useful routines for other problems [»turiA3_1951]
| Quote: it is better to split up functions into smaller pieces which may be useful for other purposes; abstraction [»wileDS11_1973, OK]
| Quote: a primitive operation should be used in many places in many different programs [»jackMA_1975]
| Subtopic: configurable reuse
Quote: reusable software should allow same-as-except as well as use-as-is; maintenance becomes a cycle of design refinements [»bassPG7_1987]
| Quote: frame is a formalization of same-as-except since it accommodates variations [»bassPG7_1987]
| Quote: for software reuse must be able to freeze some elements of behavior while leaving others open; e.g., Eiffel's deferred classes [»meyeB9_1990]
| Quote: reuse source code fragments by design and code scavenging; manually edit to specialize for a related application [»krueCW6_1992]
| Subtopic: object-oriented classes as reuse
Quote: in object-oriented programming, reuse classes; a method is not reusable independently of its class [»meyeB9_1990]
| Quote: inheritance with late binding, self-reference, and super-reference allows objects to be reused without textual copying or editing; a new way to write programs [»taivA9_1996]
| Quote: in object-oriented programs, inheritance means that the same compiled code is shared by descendents [»taivA9_1996]
| Subtopic: language as reuse
Quote: a high-level language reuses assembly language patterns, i.e., its primitive statements and operations; memorized [»krueCW6_1992]
| Quote: Eiffel can call or be used by utilities written in other languages; allows full use of Eiffel's structuring capabilities [»meyeB9_1990]
| Quote: the Common Lisp reader is also useful for lexical analysis and parsing of input; somewhat programmable [»tichWF11_1987]
| Subtopic: spreadsheet as reuse
Quote: a radically tailorable system allows a wide range of different applications by modifying a working application; e.g., spreadsheets [»maloTW11_1992]
| Subtopic: typeless, scripting as reuse
Quote: generic programming decomposes software into components with minimal assumptions; allows reuse without modification, like successful libraries [»dehnJC4_1998]
| Quote: scripting languages are often string-oriented; provides a uniform representation for many different things
| Quote: unlike object-oriented systems, scripting languages have generated significant software reuse
| Quote: scripting languages are usually typeless; makes it easy to reuse and connect components [»oustJK3_1998]
| Quote: strong typing discourages reuse through incompatible interfaces; it does not raise the level of programming [»oustJK3_1998]
| Subtopic: portable run-time system
Quote: C-- replaces C as a portable assembly language; includes a low-level, reusable run-time system that hides calling conventions and stack allocation; permits register allocation, liveness analysis, and garbage collection [»joneSP9_1999]
| Subtopic: problems with reuse
Quote: safety is a quality of the system in which the software is used; it is not a quality of the software itself; reused software may be unsafe [»leveNG7_1993]
| Quote: reuse is difficult because of superstructure to support composition; large units have largest benefit but too specialized; library design is time-consuming; uneven quality control [»boweJP4_1995]
| Quote: reuse is not free; you must find the reused functions, learn their use, and avoid unexpected side effects [»nielJ5_1989]
| Quote: it is often easier to replicate software than to integrate it into a new system [»winoT7_1979]
| Quote: if a program reuses components then the context of a statement depends on the prior execution history; requires a trace to debug [»jackMA_1975]
| Quote: idiosyncratic interfaces are not usable for widely reusable components and generic programming; interfaces should be obvious and consistently applied [»dehnJC4_1998]
|
Related Topics
Group: object-oriented programming (26 topics, 822 quotes)
Group: requirement specification (11 topics, 307 quotes)
Topic: abstraction in programming (67 items)
Topic: application generator (21 items)
Topic: aspect-oriented programming (2 items)
Topic: design for change (76 items)
Topic: design pattern (17 items)
Topic: function library (50 items)
Topic: information hiding (50 items)
Topic: language flexibility (34 items)
Topic: programming with a database of modules (94 items)
Topic: pseudocode design (43 items)
Topic: object-oriented templates and containers (27 items)
Topic: scripting language (27 items)
Topic: software components (11 items)
Topic: software management (28 items)
Topic: software portability (43 items)
Topic: Thesa as a database of modules (23 items)
Topic: type inheritance as reuse (27 items)
Topic: understanding systems (48 items)
Topic: user-centered operating system (24 items)
|