This is not the world the Spice Girls wanted for us.

Since Mastodon saw its initial popularity circa 2017, I've noticed that most users and those reporting on it either don't think about the Fediverse as anything more than Mastodon, or treat its history as beginning with Eugen Rochko and the beginning of Mastodon. In fact, Mastodon is the latest in a long line of federated social networks going at least back to, and though I wasn't around for all of it, I find this history pretty interesting. (Thread; boosts welcome!)

Plane travel by academics in 2019. While #ComputerScience isn't the worst overall, a much larger portion of our flights are for conferences and presentations. Meanwhile other disciplines travel for fieldwork, research stays, etc, which are more justifiable as necessary to the research process. Attaching prestige to conference publications and requiring attendance means significant #CarbonEmissions (via

Perhaps at some point I'll write a thread on my deep concerns about our reliance on Google Scholar.

For now, though, why on earth does Google Scholar not let you sort your search results?

You have basically one choice: to see them in "relevance" order—and we're not even told the secret formula used to determine relevance.

You can also sort by date—for papers from the past year only.

It's really crazy that a mature tool supposedly designed to serve the community would be severely limited.

I am trying an experiment of using a separate account for non-professional stuff:

#til about a really cool feature of #swift package manager:

`swift package diagnose-api-breaking-changes main`

It checks for API breaking changes between the current code and a reference Git branch/tag/commit

Really useful if you're working on a library

A blog post describing some cool type-checking technology making its way from academic research into practice...

Maths and PL friends. We have PhD-student scholarships available at the University of Birmingham, UK.

In particular, Eric Finster, Vincent Rahli and myself would be very interested in getting students in type theory, homotopy theory, higher-categories, constructive mathematics, and related fields.

Please encourage your best students to apply.

Or, if you are a student reading this, consider applying:

Hey Rust folks,

In case you've missed it, our beloved This Week in Rust is also on Mastodon as @thisweekinrust :ferris: 🎉 🚀 !

Thank you so much @nellshamrell and @benny !!!

#rust #rustlang

The University of Nottingham department of Computer Science has 10 fully-funded PhD studentships for next academic year. The FP-lab would welcome applicants interested in functional programming, category theory, type theory and other foundational topics.


In the spirit of David Patterson's "How to Have a Bad Career in Research/Academia" talk here are 10 tips I just shared with the @PLDI Program Committee for winning the Undistinguished Reviewer Award.

1. Argue to reject papers because they are not to your personal taste. If the topic is something that you are not excited about, it's unlikely that anyone in the PLDI community will appreciate the work.

2. Argue to reject papers because you would have preferred they be written differently. Better to delay publication of the technical ideas, delay a PhD student's progress toward their degree, etc. than to have the paper be written in a way you don't like.

3. Argue to reject papers because you wouldn't have used a different approach -- especially if they didn't use the approach you invented! Introducing non-standard approaches into the literature is confusing, even if they reveal connections to other areas that may inspire interesting follow-on work.

4. Argue to reject papers simply because the proofs are not mechanized or the code is not publicly available. Regardless of whether a paper makes a significant advance and provides sufficient evidence to support its claims, the field now expects full mechanization and open artifacts.

5. Argue to reject papers because you'd like to see more experiments, better theorems, etc. Even if the the technical claims are already well-supported by the evidence presented in the paper, it will be even better after the next revision.

6. Argue to reject papers because the ideas are "too simple." Even though simple approaches that work well are often the ones that have the most impact in the long run, we should be selecting papers that optimize for technical complexity.

7. Argue to reject papers based on anecdotal evidence. For example, "I heard this paper was rejected previously" or “I used tool X once and it didn’t work" are fine things to bring to the discussion of PLDI submissions.

8. Argue to reject papers because the authors forgot to cite a few tangentially-related papers. You should especially do this if the omitted paper is your own -- after all, if you've written on the topic, you are the expert!

9. Argue to reject papers because they lacks citations to or comparisons with unpublished work. PDFs on the author's website or manuscripts on arXiv are flags planted in the ground and fair game!

10. Argue to reject papers because they build on prior work that you are unfamiliar with. If you don't have the background to understand a paper, it's unlikely that anyone in the PLDI community will appreciate it.

1/ "What programming language should I teach?" is the least productive question to ask in computing. There's a good reason: it's the wrong question to ask. The reason language wars feel pointless is that they're a symptom of this problem. Here's why:

2/ Curricula are never designed in isolation. All curricula, for anything, have to consider at least two things. First: goals. These include learning objectives, but often go farther (like "students must eventually get jobs"). ↵

"Luau origins and evolution" talks about the road from Lua to Luau that Roblox took, and the careful and deliberate process of making the language better.

@wilbowma The server was setup and operated by an undergrad at IU, but they have a donation page setup. Operating costs are currently covered by the users.

Twitter (and Watchmen spoilers) 

Oh, and yet again I forget the ALT text. "My name is Ozymandias, king of kings: Look on my works, ye Mighty, and despair!" quoted in Watchmen issue 11, Moore and Gibbons, 1987.

Show thread
Show older

A Mastodon instance for programming language theorists and mathematicians. Or just anyone who wants to hang out.