Cabin in central NY

Can’t help thinking this section of the full video is incredibly important. @Mer__edith sounding the alarm bells over “agentic AI”.

https://www.youtube.com/live/AyH7zoP-JOg?t=50m16s

I was talking to someone at PLDI and the topic of novelty came up.

Here's a quiz! It randomly picks papers from PLDI 2014 and PLDI 2024. Can you tell which year each paper appeared in?

https://patricklam.ca/pldi-quiz/

Tagging @regehr, who had something to do with the PLDI 2024 program...

So jealous of Word users. You want to write something: you fire up Word, you start writing.

Me, I first spend months on my authoring tool and whether it can give me all the abstractions I want. No two of my books have used the same tool. Nearly exhausted before I even begin!

In a certain sense, the Turing test has already been deployed on a large scale: Try calling a customer support rep or looking at support pages and you'll be confronted with CGPT 0.5.

Once we acknowledge this reality the road ahead is quite clear, IMHO: We need an AI to deal with the support AI *until* we finally reach the good old customer support rep. Amazing progress, we repeatedly fail the Turing test *and* waste time and energy to get to the system that was already in place before.

Wow, can we get `lifetime_capture_by` for C?
https://llvm.org/devmtg/2025-06/slides/technical-talk/yasuda-safety.pdf

Preprint by Christoph Jung and me is now online: 'Low Overhead Allocation Sampling in a Garbage Collected Virtual Machine'
https://arxiv.org/abs/2506.16883

@bert_hubert For a visual representation: Watch "The Parliament".

Turns out I was channeling Jerry Pournelle's Iron Law of Bureaucracy: "In any bureaucracy, the people devoted to the benefit of the bureaucracy itself always get in control and those dedicated to the goals that the bureaucracy is supposed to accomplish have less and less influence, and sometimes are eliminated entirely". https://en.wikipedia.org/wiki/Jerry_Pournelle#Pournelle's_iron_law_of_bureaucracy

You have a performance problem and you think, "I know, I'll add a cache". Now you have a memory leak, and your performance problem is harder to measure reliably.

@wilbowma I vaguely remembered @lexi_lambda having interesting things to say about this paper at some point. Searched & while I didn't find whatever it was I half-remembered, I did find this 2018 thread on the racket-users mailing list that has some thoughtful posts by her, @greghendershott, Michael Ballantyne, & Matthias Felleisen:

https://www.mail-archive.com/racket-users@googlegroups.com/msg37892.html

#LiquidTypes are a lightweight way to specify and check code properties. What stands in the way of more widespread adoption?

Friday at 10:30, Catarina Gamboa presents our #PLDI2025 paper (with Abigail Reese and @alcides "Usability Barriers for Liquid Types."

@krismicinski Maybe also a good idea to incorporate an LLM service, particularly to get students familiarized with the technology (compilers was always the course to teach students *real* programming, no?).

We didn't write our own fuzzer but used Grammarinator instead. Has the added benefit to get students thinking about the various grammars they encounter along the way. (Plus easy to generate data for Lisp-like languages, something probably not immediately obvious...).

@krismicinski I also implemented the compiler myself, more to get a feeling for Racket, though. It's quite a lot of work, but there is a lot of code provided from GitHub already. We, as in me and my grad students, decided to do our own course completely from scratch (students were confused about surface syntax) and we decided to directly embed a fuzzer into the course. So tests come in naturally and the fuzzer is kind of a first class citizen. 10/10 can recommend! (Book is amazing!)

You can read more in our paper: https://steuwer.info/files/publications/2025/PLDI-Slotted-E-Graphs.pdf

This contains a formalization of Slotted E-Graphs and our evaluation shows that for some applications we have massive space savings enabling us to solve problems that traditional e-graphs can't solve within reasonable memory and time thresholds.

You can also look at the paper's artifact https://github.com/memoryleak47/slotted-egraphs-artifact and Rudi's implementation of slotted e-graphs in Rust https://docs.rs/slotted-egraphs/latest/slotted_egraphs/

If you are at #PLDI come to Rudi's talk tomorrow!

@smarr @cfbolz 🤣. I'd love to, but have already done 3x more travels than originally planned and thus will have to skip. I will, however, be at KPS at the end of September (quite unsurprising as I'm the organizer).

@cfbolz Classy!

I think there is space for updating Landin's classic: The next 700 smart contract languages.
(In particular highlighting security problems that inevitably occur since deeper knowledge of proglangs hasn't proliferated as much as it should.)

@sbrunthaler @tekknolagi Anyhow, I think you're missing a little known paper of my PhD advisor that advocates for single-instruction graphs and, iirc, also treats edge-labelled vs. node-labelled IR graphs. (Paper is a CC'98 paper titled "Basic Blocks: Useless Dinosaurs" or some such [busy right now so can't check]).

@tekknolagi The IR space is thoroughly unexplored in compilers, although I believe that the area is extremly important for optimizations, etc. I'd love to see a large survey paper of this space, but as things are going, I'd probably have to write one myself :(