Lukas LazarekπŸ”—

Me

I’m a postdoc at Brown university working with Nikos Vasilakis and the ATLAS group. This page provides information about myself and what I have been doing recently. The other half of the site is a blog that I use to practice writing about technical things, my research, and my interests.


Research InterestsπŸ”—

My research is about empirically-driven Programming Languages approaches to understanding what and how language features are practically useful for regular people trying to build useful software.

People and their programs are imperfect, so one part of that work is in linguistic tools that support program robustness, monitoring, and debugging. My dissertation work on contract systems and gradual typing centered around empirically evaluating how these specification tools, intended to improve robustness, may or may not assist with debugging through experimental data collection and analysis. My ongoing work investigates how specification tooling for the Shell can provide practical robustness benefits in complex and imperfect existing systems.

Relatively few people are programmers, however, so another direction of my research is understanding how and why everyone else might find value in programming; my work in this direction explores languages, domains, and tools which enable non-experts to quickly make use of computing, while simultaneously providing a rich setting to learn about and apply powerful computing ideas to practical problems.


Contact informationπŸ”—

My github profile is llazarek.

I can be reached by email at

(or (concat "lukas" "lazarek" "@" "brown.edu")

    (concat "lukas" "a" "lazarek" "@" "gmail.com"))


PublicationsπŸ”—

2023πŸ”—

How to Evaluate Blame for Gradual Types, Part 2 (ICFP 2023)
Lukas Lazarek, Ben Greenman, Matthias Felleisen, Christos Dimoulas
[pdf] [bibtex] [doi]
Applies the rational programmer framework to evaluate the flip side of ICFP’21’s question, where mistakes occur in type annotations. Specifically, we investigate mistakes in type-interfaces (as in TypeScript’s DefinitelyTyped), and compare the error information provided by the leading semantics for gradual typing with and without blame. We find that dynamic type checks (for all semantics) appear to offer no better information for locating such bugs than Erasure, while Natural’s blame offers the best by a large margin.

2022πŸ”—

A Transient Semantics for Typed Racket (Programming 2022)
Ben Greenman, Lukas Lazarek, Christos Dimoulas, Matthias Felleisen
[pdf] [bibtex] [doi] [video]
Reports on the challenges of implementing a Transient semantics (a la Reticulated Python) for Typed Racket.

2021πŸ”—

How to Evaluate Blame for Gradual Types (ICFP 2021)
Lukas Lazarek, Ben Greenman, Matthias Felleisen, Christos Dimoulas
[pdf as published] [pdf corrected] [bibtex] [doi] [video]
Identifies the key idea of the empirical methodology of POPL’20 as the rational programmer. Refines the rational programmer into a framework able to evaluate and compare multiple different systems, as well as control for confounding factors. We apply that framework to evaluate blame and error reporting in Gradual Typing and find that while blame is helpful, dynamic type checks without blame appear to provide sufficiently useful information in the vast majority of scenarios.

Note (2023-04-04): Corrected typos in figure 8’s caption, which did not refer to the right numbers (the diagram and prose had the right ones), revised the first few sentences of section 9.1 to clarify the paper’s conclusions (the prior wording was unclear and potentially misleading), and fixed wrong doi url for my POPL paper in the references.

2020πŸ”—

Does Blame Shifting Work? (POPL 2020)
Lukas Lazarek, Alexis King, Samanvitha Sundar, Robert Bruce Findler, Christos Dimoulas
[artifact] [pdf] [bibtex] [doi] [video]
Proposes the first empirical methodology to evaluate the pragmatic value of blame in contract systems. At an intuitive level, the methodology evaluates the hypothesis that blame is systematically related to bugs in programs, using a controlled experiment performed with real programs. We evaluate Racket’s contract system using this approach and find that blame mostly does have the desired relationship with bugs, with some interesting caveats.

2018πŸ”—

Faster Variational Execution with Transparent Bytecode Transformation (OOPSLA 2018)
Chu-Pan Wong, Jens Meinicke, Lukas Lazarek, Christian Kästner
[pdf] [bibtex] [doi]
Introduces an approach to implement variational execution as a compilation strategy by rewriting Java bytecode. This approach significantly improves upon the performance of existing (interpreted) engines, and opens the opportunity to explore new optimization techniques.


SoftwareπŸ”—

  • complot - language for compositional data visualization design

  • configurable - library for simple software configuration via config files

  • process-queue - library for managing many parallel processes

  • mutate - mutation system for s-expression languages

  • rscript - language for scripts, mainly featuring an embedded declarative command-line argument description language

  • github-actions - library for using the github actions api

  • ruinit - unit testing library

  • webgrep - CLI tool to search webpages recursively (descending into linked pages)

  • asciigraph - CLI tool that makes ASCII plots


TalksπŸ”—

How to Evaluate Blame for Gradual Types, Part 2 (ICFP 2023, Seattle 2023-09-07)

[slides]
For the ICFP23 paper by the same name. (Recording video will be available soon.)

How to Evaluate Blame for Gradual Types (virtual 2021-08-24)

[video]
For the ICFP21 paper by the same name.

Does Blame Shifting Work? (POPL 2020, New Orleans 2020-01-22)

[slides] [video]
For the POPL20 paper by the same name.


Posters and Extended AbstractsπŸ”—

How to Efficiently Process 2100 List Variations (SPLASH 2017, Vancouver 2017-10-22)

[poster] [abstract]
Extended abstract and poster, won first place in student research competition.