mkremins

It’s always funny to read general-public takes on academic peer review, because they almost always betray a complete misunderstanding of how peer review works. Academic reviewers for the vast majority of journals notoriously do not get paid; in fact, paying peer reviewers is one of the most frequently suggested approaches to peer review reform.

This is a really poor selection of events. Even if you restrict “AI” to mean “LLMs and diffusion”, this timeline starts years too late to cover the complete history of GPT models alone; I first became aware of LLMs a bit after Talk To Transformer launched in May 2019. Super frustrating.

This is exactly my feeling. I was on both pretty early, and was more excited about Mastodon in the early days – but when I started seeing the pattern of hackers who’d built cool new features being flamed off the platform, it became clear to me that the Mastodon community didn’t actually want to be part of the open internet. Which is fine with me, but not at all the kind of thing I’m on social media for. I’ll take my chances with Bluesky.

He also gets a fair amount of attention from game designers, especially those of us who have one foot in academia and one in the industry / "real world".

Yep, I'm aware. I'm still just a student, but I try to follow PX-related research pretty closely, and I'm actually something of a fan of your work in this space in particular :) I've also got a lot of respect for projects like Elm, where an explicit focus on programming-as-UX has produced a language and development environment that (although incomplete) are collectively more accessible and learnable than many of the existing alternatives.

That said, I'm still of the opinion that programmer culture at large is too quick to disregard design. I'd really like to see more programming tools for general use developed with an eye to design, and for more industry and hobbyist programmers to realize that the current baseline state of existence is not an absolute maximum but a local one. We've pushed plain text pretty far, but it seems obvious to me that there's much bigger wins to be had if we throw out some of the assumptions our culture tends to make.

This is spot on. In programming communities, design is frequently dismissed as an "implementation detail" or part of "making it look good" (i.e. marketing). This is a distinct and recurring cultural blind spot – more conceptually interesting programming tools than I can count have been torpedoed by a lack of attention to visual/UI/UX/HCI design.

Design is absolutely critical when it comes to helping people understand complex systems. Well-designed tools work with the human brain to mitigate cognitive load, allowing the user to focus on making stuff happen rather than on juggling handfuls of information. Few programming tools, experimental or mainstream, fit this description; even fewer have anything like it in mind.

Successful efforts to make programming less opaque and more accessible will necessarily involve massive leaps forward in design. I'm glad to see design beginning to make some inroads into programming culture, but we've got a long way to go yet considering how frequently the Unix CLI is still held up as the state of the art.

Makes sense to me, although I suppose there's probably an argument to be made in favor of the uniformity that comes with using :require for everything.

(:use clojure.test) is probably a worthy exception – 90% of the time I see :use in the wild, it's in exactly that context :)