Contemporary IDEs know a whole lot about the programming languages they are intended for. They know their syntax and static semantics (including type and name binding rules); they know how to fix malformedness (both syntactic and static semantic), how to complete programs, and sometimes also how to refactor them (even though this is the hardest, as the necessary behaviour preservation usually requires static regard of the dynamic semantics of a programming language). In fact, it seems fair to say that the IDE knows more about a programming language than the average programmer using it. The one thing it does not know is the program the programmer wants to write.

In his 2016 SPLASH keynote “How to Tell a Compiler What We Think We Know?”, Guy Steele suggested that programming should be like a conversation with the compiler. To some extent, this is already the case: the IDE checks the input of the programmer and reports errors in a problems view; it also makes suggestions how to x the errors, and how to complete an incomplete program. While this may not be quite what Steele had in mind, the current static checking implemented by an IDE can readily be extended by additional checks (see, e.g., [3]) and, assuming the programmer is ready to spell out formal specifications to the IDE, ultimately also with theorem proving that decides whether an entered program fulfills this specification (and, if not, aids the programmer with making it do so).

However, even if reduced to basic static checking, the current situation is a far cry from this vision. Instead, IDEs make suggestions that seem surprisingly ignorant of even the simplest well-formedness rules — for instance, error fixes and code completions regularly suggest changes that introduce (new) errors (refactoring tools are notorious for doing so anyhow). Also, as a conversation partner, the IDE is rather passive — except for issuing error reports, it remains silent unless prompted for help.

Technically, there is no need for this ignorance or passiveness: given its perfect knowledge of syntax and static semantics, an IDE could at all times engage the programmer in a dialogue in which the programmer expresses intended changes and the IDE responds immediately with complementing changes necessary to maintain well-formedness. This would stop the problems view from folling and, particularly compelling, save the programmer from having to undo long chains of changes because at some point it turns out that an earlier decision was wrong (as evidenced by the fact that a current malformedness is impossible to x without undoing). Such dialogues are possible (see, e.g., our prior work [9–11]) and can even be automatically derived from a program and a formal specification of a programming language [6–8, 10, 12]; yet, it is unclear whether programmers really want to program in such a way and, what is more important for the long term programmer experience, whether such a more dialogue-style programming will ultimately lead to better results.