A cognitively-based methodology for designing languages/environments/methodologies

Abstract

In designing a programming language, programming environment, or programming methodology there are a whole lot of both implicit and explicit “shoulds.” By a “should” we mean the claim that the appropriate use of language/environment/methodology X will lead to good habits and result in good products. For example, ADA's commitment to strong typing and mechanisms for constructing data types implies that these components are good and should result in more effective programming. The top-down design methodology implies that designers should start at the specifications and refine downward; this process will result in a good design. Etectera. The problem is that it is not clear that the current crop of languages/environments/methodologies (L/E/M's) do result in more productive programming and design, and that the “shoulds” implied by them are really all that good ([7]).