Demo Data from EDBT 2026 / reviewers in the wild / expert
Lambros Karkazis
dblp:225/0382
· DBLP profile ↗
1ranked-venue papers
0as first author
0since 2021 · last 2018
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 1
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Software engineering, system software, and programming languages
1 paper |
Programming languages and type systems · 50% Empirical software engineering · 50% |
Topics — the 4 heaviest of 4, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Empirical software engineering › developer studies
developer productivity study |
0.3 | 1 | 2018 | Assessing the type annotation burden · ASE 2018 |
Empirical software engineering
developer studies |
0.3 | 1 | 2018 | Assessing the type annotation burden · ASE 2018 |
Programming languages and type systems › type systems
type annotations |
0.3 | 1 | 2018 | Assessing the type annotation burden · ASE 2018 |
Programming languages and type systems
type checking |
0.3 | 1 | 2018 | Assessing the type annotation burden · ASE 2018 |
Methods — techniques the papers use, named apart from their topics
user study · 0.3qualitative analysis · 0.3
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2018 | Assessing the type annotation burdenabstractType annotations provide a link between program variables and domain-specific types. When combined with a type system, these annotations can enable early fault detection. For type annotations to be cost-effective in practice, they need to be both accurate and affordable for developers. We lack, however, an understanding of how burdensome type annotation is for developers. Hence, this work explores three fundamental questions: 1) how accurately do developers make type annotations; 2) how long does a single annotation take; and, 3) if a system could automatically suggest a type annotation, how beneficial to accuracy are correct suggestions and how detrimental are incorrect suggestions? We present results of a study of 71 programmers using 20 random code artifacts that contain variables with physical unit types that must be annotated. Subjects choose a correct type annotation only 51% of the time and take an average of 136 seconds to make a single correct annotation. Our qualitative analysis reveals that variable names and reasoning over mathematical operations are the leading clues for type selection. We find that suggesting the correct type boosts accuracy to 73%, while making a poor suggestion decreases accuracy to 28%. We also explore what state-of-the-art automated type annotation systems can and cannot do to help developers with type annotations, and identify implications for tool developers. John-Paul Ore, Sebastian G. Elbaum, Carrick Detweiler, Lambros Karkazis |
ASE | 4 |