EDBT 2026 Demo / reviewers in the wild / expert
Louis G. Michael IV
dblp:246/5367
· DBLP profile ↗
2ranked-venue papers
1as first author
0since 2021 · last 2019
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 2 · 1 first-author
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
2 papers |
Empirical software engineering · 50% Software maintenance and evolution · 25% Programming languages and type systems · 25% |
Topics — the 4 heaviest of 4, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Software maintenance and evolution
code readability |
0.4 | 1 | 2019 | Regexes are Hard: Decision-Making, Difficulties, and Risks in Programming Regular Expressions · ASE 2019 |
Empirical software engineering
developer studies |
0.4 | 1 | 2019 | Regexes are Hard: Decision-Making, Difficulties, and Risks in Programming Regular Expressions · ASE 2019 |
Programming languages and type systems
language design |
0.4 | 1 | 2019 | Why aren't regular expressions a lingua franca? an empirical study on the re-use and portability of regular expressions · ESEC/SIGSOFT FSE 2019 |
Empirical software engineering
mining software repositories |
0.4 | 1 | 2019 | Why aren't regular expressions a lingua franca? an empirical study on the re-use and portability of regular expressions · ESEC/SIGSOFT FSE 2019 |
Methods — techniques the papers use, named apart from their topics
survey · 0.4interview study · 0.4
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2019 | Regexes are Hard: Decision-Making, Difficulties, and Risks in Programming Regular ExpressionsabstractRegular expressions (regexes) are a powerful mechanism for solving string-matching problems. They are supported by all modern programming languages, and have been estimated to appear in more than a third of Python and JavaScript projects. Yet existing studies have focused mostly on one aspect of regex programming: readability. We know little about how developers perceive and program regexes, nor the difficulties that they face. In this paper, we provide the first study of the regex development cycle, with a focus on (1) how developers make decisions throughout the process, (2) what difficulties they face, and (3) how aware they are about serious risks involved in programming regexes. We took a mixed-methods approach, surveying 279 professional developers from a diversity of backgrounds (including top tech firms) for a high-level perspective, and interviewing 17 developers to learn the details about the difficulties that they face and the solutions that they prefer. In brief, regexes are hard. Not only are they hard to read, our participants said that they are hard to search for, hard to validate, and hard to document. They are also hard to master: the majority of our studied developers were unaware of critical security risks that can occur when using regexes, and those who knew of the risks did not deal with them in effective manners. Our findings provide multiple implications for future work, including semantic regex search engines for regex reuse and improved input generators for regex validation. Louis G. Michael IV, James Donohue, James C. Davis 0001, Francisco Servant |
ASE | 1 |
| 2019 | Why aren't regular expressions a lingua franca? an empirical study on the re-use and portability of regular expressionsabstractThis paper explores the extent to which regular expressions (regexes) are portable across programming languages. Many languages offer similar regex syntaxes, and it would be natural to assume that regexes can be ported across language boundaries. But can regexes be copy/pasted across language boundaries while retaining their semantic and performance characteristics? In our survey of 158 professional software developers, most indicated that they re-use regexes across language boundaries and about half reported that they believe regexes are a universal language.We experimentally evaluated the riskiness of this practice using a novel regex corpus — 537,806 regexes from 193,524 projects written in JavaScript, Java, PHP, Python, Ruby, Go, Perl, and Rust. Using our polyglot regex corpus, we explored the hitherto-unstudied regex portability problems: logic errors due to semantic differences, and security vulnerabilities due to performance differences. We report that developers’ belief in a regex lingua franca is understandable but unfounded. Though most regexes compile across language boundaries, 15% exhibit semantic differences across languages and 10% exhibit performance differences across languages. We explained these differences using regex documentation, and further illuminate our findings by investigating regex engine implementations. Along the way we found bugs in the regex engines of JavaScript-V8, Python, Ruby, and Rust, and potential semantic and performance regex bugs in thousands of modules. James C. Davis 0001, Louis G. Michael IV, Christy A. Coghlan, Francisco Servant |
ESEC/SIGSOFT FSE | 2 |