Group:
natural language
Group:
systems
Topic:
design for change
Topic:
dynamic vs. static data type
Topic:
generic operations and polymorphism
Topic:
grammar modification
Topic:
identifying program modules
Topic:
in-line machine code
Topic:
language extension via macros
Topic:
loosely structured data
Topic:
meaning of words
Topic:
non-constraining system
Topic:
orthogonal extension and cartesian products
Topic:
programming language design
Topic:
resourceful, redundant systems for reliability
Topic:
reusable programming
| |
Summary
A language should be universal, allowing any idea to be communicated. A programming language needs to describe any kind of data, any sequence of machine operations, any user interface, and any programming chore. It must have this flexibility, while being simple enough for machine processing. High-level languages fail this criterion. They limit users to a primitive set of data types and language operations. They preemptively define many trivial decisions before a program is written. (cbb 5/80)
Flexibility must be designed for from the start. It can not be added latter; possibly because it is fundamentally in conflict with efficiency and system. Macro processors can add some flexibility. (cbb 1/90)
Subtopic: what is flexibility 
| QuoteRef: gilbT_1977 ;;164 "flexibility is useful complexity
| | Quote: measure language effectiveness by counting the modifications needed to satisfy a user's needs and to effect change during evolution [»blumBI_1985]
| | Quote: a functionally rich system is not orthogonal; there are multiple ways to achieve a result
| | Quote: a program is a complex combination of diverse materials that must undergo continuous modification; how can they be supple [»smitDR11_1985]
| | Quote: language should define the essential semantics of a construct with multiple, equivalent, implementations [»shawM3_1980]
|
Subtopic: flexibility is key
| Quote: flexibility is a fundamental consideration of language design; it should be planned for from the start [»halpMI1_1968]
| | Quote: can program in Smalltalk anything that the user can do; e.g., create automatic, intelligent editors; came from Lisp [»goldA10_1995]
| | Quote: the naming systems for programming languages are inflexible [»backJ_1972]
| | Quote: a language should be able to represent any information known by the user that is useful to the compiler [»maclBJ_1987]
| | Quote: FORTRAN designed to express any numerical procedure [»backJW_1957]
| | Quote: an encyclopedic system must be enormously flexible to transform knowledge into understanding [»kochM_1967]
| | Quote: flexibility is a fundamental consideration of language design; it should be planned for from the start [»halpMI1_1968]
|
Subtopic: system clay
| Quote: a Smalltalk user should be able to rapidly change the conceptual model of a system without strong technical skills; needed for simulation [»goldA10_1995]
| | Quote: Hypertext is clay [»vandA7_1988]
| | QuoteRef: cbb_1973 ;;11/30/73 want a language which is locally definable (i.e. continuous) but no where differentiable
| | QuoteRef: cbb_1973 ;;7/21/79 what I really want is the ability to define arbitrary sequences of relocatable code
|
Subtopic: pre-emptive language design
| Quote: pre-emptive language design makes many trivial decisions before a program is even written [»shawM3_1980]
| | Quote: programming language designers have made unnecessary, pre-emptive decisions about the nature of various features; e.g., array implementation [»shawM3_1980]
| | Quote: language design, especially by committees, includes doubtful features under the argument that they can be ignored by non-users [»ritcDM7_1978c]
| | Quote: more efficient code if don't overspecify the language; e.g., include a pseudo-op for branch with equal case unspecified [»dewaRB1_1977]
| | Quote: von Neumann languages provide an immense framework and limited changeable parts [»backJ8_1978a]
|
Subtopic: radical change of working applications
| Quote: a radically tailorable system allows a wide range of different applications by modifying a working application; e.g., spreadsheets [»maloTW11_1992]
|
Subtopic: flexibility vs. efficiency
| Quote: flexibility and efficiency are fundamentally in conflict
|
Subtopic: flexibility and namespaces
| Quote: inflexible namespaces lead to conflicts; avoid flat namespaces requiring conventions, package conflicts, restricted scoping, static services [»acheF9_2000]
|
Subtopic: flexibility within a domain
| Quote: a successful, flexible manufacturing system is only flexible within its repertoire [»whitDE4_1986]
| | Quote: PROMIS explicitly defines options for flexible decision making [»waltPL11_1979]
|
Subtopic: flexibility via macros
| Quote: a macro processor adds flexibility to a base language; allows alteration, delayed binding, and extensions [»browPJ_1974]
| | Quote: a macro processor allows alteration of a general programming language to fit specific needs; e.g., knitting and crop-rotation [»browPJ_1974]
| | Quote: define macros for anything that may change; allows delayed binding for implementation of the macros [»browPJ_1974]
| | Quote: every aspect of a program is liable to change, but languages require details to be fixed; use macros
|
Subtopic: flexibility via slots
| Quote: Self emphasizes concreteness, uniformity, and flexibility: program by copy-and-modify, uniform objects and messages, flexible slot structure [»smitRB10_1995]
| | Quote: easy to create a new class; decentralized representation with locally defined state
|
Subtopic: causes of inflexibility
| Quote: data description does not support collections of data; hard to change without impacting applications [»coddEF6_1970]
| Quote: avoid representational dependencies in data; e.g., ordering, indexing, and access path
|
Related Topics
Group: natural language (16 topics, 539 quotes)
Group: systems (17 topics, 530 quotes)
Topic: design for change (76 items)
Topic: dynamic vs. static data type (24 items)
Topic: generic operations and polymorphism (67 items)
Topic: grammar modification (10 items)
Topic: identifying program modules (26 items)
Topic: in-line machine code (5 items)
Topic: language extension via macros (23 items)
Topic: loosely structured data (20 items)
Topic: meaning of words (21 items)
Topic: non-constraining system (25 items)
Topic: orthogonal extension and cartesian products (11 items)
Topic: programming language design (53 items)
Topic: resourceful, redundant systems for reliability (38 items)
Topic: reusable programming
(77 items)
|
