Thomas Dickerson @elfprince13@mumak.app

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"). ↵

@elfprince13 runtime, compile-time, edit-time & horned-snake-time

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.

@shriramk seems like a good thread to port over this doozy from Twitter.

“here's possibly the worst Python scoping rule I've ever seen.”

Try for yourself at https://replit.com/@elfprince13/RubberyFortunateCables#main.py

Compiler Explorer now supports some CUDA code execution on a real GPU: https://godbolt.org/z/a6rzTbKeM - let me know what issues you find :)

Anyone maintaining a Mastodon instance and losing sleep over the Great Migration should read this excellent technical discussion of the matter: https://nora.codes/post/scaling-mastodon-in-the-face-of-an-exodus/ This is also a really good description of the sort of problems we're confronting with the backend of hcommons.social (and some of the things we've tried), if you're interested. Good times are ahead, though! We have a dev instance that is a lot more powerful than the one that is running right now.