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.
Academics don't make any money from sales of paywalled journal articles. If you click a link to a journal article and hit a paywall, it's usually because whoever shared the link has institutional access to the journal and forgot that the paywall was there (since it effectively isn't for them.)
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".
I was one of those who left. I let my adminship elapse after 10 years.
I also don't contribute much to SO, or to any SE properties, despite being on the early public beta. (remember the signup as a google spreadhseet). I'm ID 479 on SO.
Yep. And the deletionists where more often the "majority" culture and male, which resulted in a feedback loop for the nonminority and female. New minority turn up, have a bad experience and leaves. I think it was studied let me see if I can find the paper. I know the results were replicated with comment bots.
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.
You do know there is a whole field called programming language design right? Not everyone in the PL field is doing theory or chasing better performance, some of us actually focus on design (and I'm not the only one, and design has been studied and practiced since at least the 70s). Visual design is where we are especially weak, but we have our PX down (like UX, but User becomes Programmer).
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 interpretation is error-prone. (seq 1), for instance, throws an IllegalArgumentException at runtime. Meanwhile, (seq nil) returns a falsey value even though in many cases it's possible to transparently pass nil in place of a collection of any kind.
Essentially, seq already assumes that its argument is seqable. Don't use it to test an argument of unknown type for seqability; prefer something like the seqable? function from core.incubator [1], or a different core function like coll? or sequential? where the semantics of one of these will do.
Both :use and :require :refer :all slurp symbols into your namespace unqualified. This behavior can cause confusion when someone reading your code tries to figure out which symbols are defined where. Most of the time, more explicit alternatives are preferred:
(:require [foo :as f])
gives the required namespace a short alias with which symbols defined in that namespace can be qualified, while
(:require [foo :refer [bar baz quux]])
explicitly provides a set of symbols to import unqualified.
Generally speaking, :require :refer :all is also considered non-idiomatic. In fact, ClojureScript has explicitly avoided supporting both :require :refer :all and naked :use [1]. Backwards compatibility seems to be the only reason either is still supported by Clojure on the JVM.
I totally agree about requiring :as or :refer to specific functions, but it still seems like the clojure team prefers naked `use` over `require refer all`, so should the style guide be changed to allow naked `use` in some circumstances?
I guess a popular example is `(:use clojure.test)`
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 :)
