Modern software is embedded in sociotechnical and physical systems. It relies on computational support from interdependent subsystems as well as non-code resources such as data, communications, sensors, and interactions with humans. General-purpose programming languages and mainstream programming language research both focus on symbolic notations with well-defined semantics that are used by professionals to create correct solutions to precisely-specified problems. However, these address only a modest portion of this modern software.

Persistent myths reinforce this focus. These myths provide a lens for examining modern software: Highly-trained professionals are outnumbered by vernacular developers; writing new code is dominated by composition of ill-specified software and non-software components; general-purpose languages and functional correctness are often less appropriate than domain-specific languages and fitness for task; and reasoning about software is challenged by uncertainty and non-determinism in the execution environment, especially with the advent of systems that rely on machine learning. The lens of our persistent myths illuminates emerging opportunities and challenges for programming language research.

Mary Shaw once designed traditional general-purpose programming languages, even languages with support for formal specification and verification, but realized that the real action is in the high-level organization of systems and turned to architecture description languages, whereupon the High Church of Programming Languages read her out as a heretic. In this journey to apostasy she

• accepted aliasing as dangerous but not evil, in the late 1970’s
• renounced belief in the assignment axiom, in the late 1970’s
• realized that types were added to programming languages to document broad intent and provide early warning of problems in execution, in the early 1980’s
• never accepted objects as the one and true path
• disavowed complete formally verified specifications of correctness, in the mid 1980’s
• embraced little languages for lightweight programming, in the late 1980’s
• decided that the right abstractions are more important than formal elegance and so espoused first-class architectural connectors, in the early 1990’s
• acknowledged that cost-effectiveness in context has higher priority than pure correctness, in the mid 1990’s
• recognized that most code doesn’t matter enough to need rigorous validation, around the turn of the century
• anticipates more heresies yet to come