@jfdm Sounds like a cool course! Would love to hear about your experience. My inbox is always open.

@lindsey Revisiting human-centered ideas poorly done by well-meaning but ill-equipped programmers is my passion!

@alilly We eagerly await the programmer of legend, the one who knows the entirety of C++26.

@dysfun Then they can read our other textbook designed to teach people ownership!

https://rust-book.cs.brown.edu/ch04-02-references-and-borrowing.html

We've been thinking about: what would a resource designed specifically to facilitate transfer from one language to another look like, at least for the relatively common case of C++ to Rust? This is our first step in that direction.

We've just released an early access version of the C++ to Rust Phrasebook, a resource for helping devs translate C++ idioms into Rust. Check it out here:

https://cel.cs.brown.edu/crp/

@jonmsterling @carloangiuli I've wrangled with bug reports from those kinds of users as well. IME the most effective strategy is to have a community discussion board (usually a Discord) staffed with knowledgeable users who can handle common problems and escalate as needed. It just sucks that it's not meaningfully searchable.

@jonmsterling I think those templates are primarily scaffolding for less experienced engineers. The alternative is a flood of people saying smth like "my compiler said it has an internal error" or otherwise not understanding the conditions for reproducibility.

This work is joint with Gavin Gray (https://gavinleroy.com/) and Shriram Krishnamurthi (@shriramk).

A core problem with diagnostics is that they have to reduce a ton of information into a CLI-friendly output. Many folks have worked on this problem by devising clever algorithms for picking the "right" info to show to users.

This work asks instead: what if we didn't have to reduce any information by using a GUI instead? We focused on designing a variety of interactions to empower users to iteratively explore whatever information is relevant to their debugging task.

If you've ever struggled with trait/typeclass compiler errors, or if you're interested in better user interfaces for compiler diagnostics, check out our upcoming PLDI paper: "An Interactive Debugger for Rust Trait Errors"

Rust famously has good error messages. But we found that with the right interface, people become ~3x faster at identifying the root cause of a trait error. See our blog post, including a live demo in your browser:

https://cel.cs.brown.edu/blog/an-interactive-debugger-for-rust-trait-errors

Honored to have our paper on the pedagogy of Rust ownership selected for the SIGPLAN Research Highlights. I'm so glad to have found a community of wonderful, supportive people who appreciate my idiosyncratic research ideas!

This week, the NSF Director became complicit in the administration’s efforts to undermine American science. https://bit.ly/nsfresign

@jedbrown You're an expert tokenizer!

@qualmist Whoops fixed thanks!

Here's a few of the ideas I bounced around (top-left is the control):

Btw one things CS academics need to Figure Out is a style guide for typesetting code, especially inline code. I had a fun thread on this a few years ago: https://twitter.com/tonofcrates/status/1636169920009621504

A few handy things I learned from The Elements of Typographic Style. Wrote last year but forgot to share:

https://willcrichton.net/notes/typography-misconceptions/

@monkey1 But the behavior of that interactive element has to be defined in Javascript. Pollen is not designed to compile arbitrary Racket into Javascript, to my knowledge. It's only designed to compile a document tree into HTML.