Cognitive strategies and looping constructs: an empirical study
Communications of the ACM
Beyond numbers: Don't ask “how many” ... ask “why”
CHI '83 Proceedings of the SIGCHI Conference on Human Factors in Computing Systems
Tapping into tacit programming knowledge
CHI '82 Proceedings of the 1982 Conference on Human Factors in Computing Systems
Software psychology: Human factors in computer and information systems (Winthrop computer systems series)
Separating content from form: A language for formatting on-line documentation and dialog
SIGDOC '85 Proceedings of the 4th annual international conference on Systems documentation
A novice programmer's support environment
ITiCSE '96 Proceedings of the 1st conference on Integrating technology into computer science education
Splitting the Difference: The Historical Necessity of Synthesis in Software Engineering
IEEE Annals of the History of Computing
Towards more intelligent programming environments
ACM SIGSOFT Software Engineering Notes
| Hi-index | 0.00 |
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]).