I love that Types and Programming Languages has a dependency graph of its chapters, followed by a recommended curriculum as a curated topological sort.
If you're learning Rust right now, try out our interactive version of the Rust Book. It has:
- Quizzes to help check your understanding
- Highlighting to help you keep notes and give feedback
- Plus more features on the way!
We just added a new chapter on ownership to the Rust Book Experiment. It provides a deeper look into how Rust works at runtime, and why the borrow checker will catch unsafe programs. Check it out:
1 year, 1 RFC, and 1k LOC later... it's finally here! Rustdoc can now automatically scrape code examples from your workspace's examples/ directory as documentation for functions. Check out a live demo:
PL papers are hard to read, and LaTeX / PDF doesn't make it easier. So I decided to make the LaTeX of the future. You can check out in my HATRA'21 paper: "A New Medium for Communicating Research on Programming Languages"
Personal news: I'm starting a postdoc with
@ShriramKMurthi
! Our goal is making Rust easier to learn.
We'll be designing curricula, visualizations, and IDE tools to help devs understand concepts like ownership and traits.
And we are partnering with the inimitable
@nikomatsakis
.
Monday Memory Mystery: guess why these assertions hold in Java. (Note that this behavior is *in the language spec*, not an implementation detail of the JVM.)
An underappreciated aspect of functional programming is that it's different from other styles because it arose from a historical context where the foremost goal was to formally reason about semantics, not to accomplish programming tasks on existing hardware.
Guess who's about to become Rhode Island's
#1
Rustacean and
#2
document engineer (behind Andy van Dam, ofc). Catch me as an assistant prof at Brown CS in 2025!
Relearning that PHP has absolutely psychotic semantics for higher-order functions:
function foo() { echo "bar"; }
function twice($f) { $f(); $f(); }
twice('foo')
That's right, you pass the function name **as a string**!
Hey I'm on the academic job market. I build systems to make programmers smarter, informed by PL theory (to make correct & generalizable tools) and HCI theory (to make humanly-useful tools). Also, students say I'm "one of the best lecturers at Stanford."
One striking stat from the Rust Book Experiment is that 60% of Rust learners self-report as not proficient in a systems language (C or C++). 95% self-report as not proficient in a pure functional language (OCaml or Haskell).
A debugger is not a debugger, it is an interactive program executor. The sooner we internalize this, the sooner we can talk about what should really be considered a “debugger.”
(nervously reading a script, glancing at an offscreen presence) The picture above is not a string. A string is a... beautiful abstraction which would never have so many fields. Strings have always looked like this:
Flowistry is a set of powerful IDE tools for Rust. It uses techniques from my research to analyze a program's information flow, and visualize the flow in several ways.
An alpha release is now available! Works with VSCode and nightly Rust projects.
"The systems programmer has read the kernel source, to better understand the deep ways of the universe, and the systems programmer has seen the comment in the scheduler that says “DOES THIS WORK LOL,” and the systems programmer has wept instead of LOLed."
> open a PL paper
> shit it uses category theory
> fine it's time to learn
> open "Category Theory for PL Dummies"
> 800 pages of definitions
> at last, motivating applications
> "X is actually Y. to see why this connection is useful, read these 5 papers"
> mfw
New paper w/
@ShriramKMurthi
, conditionally accepted to POPL'24: how do document languages compose content and computation? The key mechanism is the *template*, which we model by extending to System F to create the *document calculus*.
Excited to announce my debut PL/HCI paper appearing at CHI'21: "The Role of Working Memory in Program Tracing".
Ever found it hard to remember stuff while you read a program? That's working memory! Check out our experiments exploring this phenomenon.
Our OOPSLA'23 paper is now on arXiv. We developed a new pedagogy for teaching Rust's ownership model, and we evaluated the pedagogy's learning outcomes with data from thousands of Rust learners.
I've noticed a lot of Rust APIs nowadays use "trait sugar" for flexibility, e.g. impl Into<String> instead of String. But a concern for users is how much worse the error messages become. Compare:
fn f(s: String) {}
fn g(s: impl Into<String>) {}
fn main() { f(0); g(0); }
When I taught CS 242, I argued PL history can be divided between Turing languages and Church languages. Turing languages were invented with respect to the machines that existed at the time. Church languages were invented usually for formalizing mathematical or logical domains.
Really liking this interaction -- I call it "focus mode". Turns slicing into an ambient interaction. Click anywhere, immediately see the forward and backward slice of what's under your cursor.
It's sad that ownership/borrowing is always explained in terms of application to memory management. One day, we'll talk about a static aliasing discipline the same way we talk about types today. Knowing who points to what is fundamental to good system design.
I'll be presenting our OOPSLA'23 paper "A Grounded Conceptual Model for Ownership Types in Rust" tomorrow at 11:18am in Room I. Come and hear about a recipe for helping people understand a type system. A preview:
New paper out w/
@ShriramKMurthi
accepted to OOPSLA'24: a psychometric analysis of programming language learning. We added ~200 quiz questions to a popular book on Rust and collected ~1,000,000 answers from ~60,000 people over 1 year.
Big thanks to everyone who attended my thesis defense. If you missed it, here's a recording. I cover important topics like:
* Why (human) memory matters when programming
* How the Rust borrow checker works
* How to make a lemon meringue pie
What should be considered a design pattern in the era of functional languages? I wrote a paper about this question for FUNARCH @ ICFP. Would love to hear your thoughts:
Dissertation is out! "Revisiting Program Slicing with Ownership-based Information Flow". You might like:
* A philosophy for combining theories of cognition & PL
* A history of cogpsych research on programming
* A perspective on how to make slicing useful
I was curious about the landscape of research about Rust, so I put together a Zotero library of 50+ publications from the last 10 years and loosely organized them. For the interested:
@shwestrick
Honestly no idea. TS modules aren't great but are workable enough.
But FWIW the TS type system is actually insanely complicated. It variously supports: gradual typing, structural subtyping, dependent typing, type combinators, multiple inheritance through mixins, ...
Also, one last brag: I have *impeccable* taste in programming languages. In 2018, I was teaching in my PL course:
- OCaml
- Rust
- WebAssembly
- Lean
Five years later, I'm running 4/4 in terms of "languages people are excited to use in 2023".
I am defending my thesis, "Revisiting Program Slicing with Ownership-based Information Flow", next Friday May 6 at 3pm PT.
Please attend if you're interested! The talk is designed to be broadly accessible. Gates 174 in-person, or you can watch on Zoom (DM me for the link).
I feel like there should be more DSLs (and corresponding theory) for describing patterns. Regular expressions are nice for basic sequences, but what about:
* Multiple overlapping sequences
* Spatiotemporal data
* Trees, DAGs, graphs
Is there a version of math with better names for things? Imagine if we had "Naur loop" and "Hoare loop" instead of "for loop" and "while loop." Yet we have Cauchy–Schwarz inequality, Kullback–Leibler divergence, Euler's formula, ...
While folks are starting to get excited about GC-ified Rust, just remember -- real ones have been asking since 2016, "what if we just wrapped everything in Rc<RefCell<T>>?"
I would hate it if everyone read my dissertation. I bet you would find soooo many issues if you read it cover-to-cover and grappled with all the ideas. God forbid that people find the convenient link on my website:
One striking feature of programming language history is that two of the most influential languages ever created were designed by committee: Algol and Haskell, both under quite similar circumstances.
Hah, frontend web devs are so stupid, using an arbitrary assignment of integers to manage z-index conflicts. Time to take a big sip of coffee and see how type theorists deal with overlapping type classes.
Devising a demented vocabulary so my students will never be able to use Copilot. Good luck asking for a method that can hedgetrim an N-way pseudo-shrub
After a brief trial, this seems like a useful complement to other information sources, but not a real game-changer. Eg I opened the Rust compiler source and asked where I could find diagnostics relating to trait errors, and it hallucinated 5 files that don't exist.
I'm excited to announce that Cody is here for everyone. Cody can explain, diagnose, and fix your code like an expert, right in your IDE. No code base is too challenging for Cody.
It's like having your own personal team of senior engineers. Try it out!
This historical perspective falls apart in the last decade. Many new languages (Rust, Swift, Scala, ...) have both Church and Turing influences. I argue in my course that this is because software is getting so complex that primitives designed for reasoning are now essential.
Excited for my upcoming book, "Rust for Clojurists Who Also Know A Bit of Haskell and Took a Systems Programming Class Back in College But It's Been A While"
@ShriramKMurthi
Q: "How do you make a deep copy of an object [in Java]?"
A: "A safe way is to serialize the object, then deserialize. This ensures everything is a brand new reference."
The world wants a better document language for the web! If you are an HCI researcher, a tools-for-thought enthusiast, a Javascript nerd -- now is the time to work on this problem.
But we need a revolution, which I don't think will come from incremental improvements on Markdown.
Today we’re open-sourcing Markdoc, the content-authoring system that powers the Stripe docs.
You can now freely build documentation, static pages, or tooling with the same tools we use: . ✍️
Giving several talks, most virtually. Come watch!
5/23: LangSec - "Towards Language-Theoretic Security for Dynamic Documents"
5/28: JetBrains TV - "Teaching Rust"
8/22: Topos Institute - "The Human Factors of Type Systems"
10/23: P99 Conf - "The Performance Engineer's Toolkit"
ES6 JS is actually a very pleasant language now. But its tools require so much more work than in a centralized ecosystem like Rust. Billions of .config.json files, dozens of interop packages like esbuild-jest or estrella.
Proof assistants are a great motivator for abstract algebra. "Ugh I don't want to prove all these facts for my new data structure... Oh wait, but if I think of it as a semilattice, I'll get these theorems and tactics for free!"
One extension of this idea, from a convo with
@neurocy
: what if tools could indicate the conceptual dependencies of an object in context?
Eg "you must understand closures, traits, and async to use this Rust library."
This Google PM really gets me. The thing I hate the most about conferences is meeting new people, and the solution I'm looking for is to replace myself with an AI.
What if Rosetta Code actually had a good interface? Check out my "expressiveness benchmark" for data analytics DSLs that helps compare implementations of the same task in different languages.