#fuck I might even take up coding classes just to learn some basic JavaScript

[death-by-moth]

I’m really gonna do it this time (finish a project)

[shinelikethunder]

Fandom Userscript Cookbook: Five Projects to Get Your Feet Wet

Target audience: This post is dedicated, with love, to all novice, aspiring, occasional, or thwarted coders in fandom. If you did a code bootcamp once and don’t know where to start applying your new skillz, this is for you. If you're pretty good with HTML and CSS but the W3Schools Javascript tutorials have you feeling out of your depth, this is for you. If you can do neat things in Python but don’t know a good entry point for web programming, this is for you. Seasoned programmers looking for small, fun, low-investment hobby projects with useful end results are also welcome to raid this post for ideas.

You will need:

The Tampermonkey browser extension to run and edit userscripts

A handful of example userscripts from greasyfork.org. Just pick a few that look nifty and install them. AO3 Savior is a solid starting point for fandom tinkering.

Your browser dev tools. Hit F12 or right click > Inspect Element to find the stuff on the page you want to tweak and experiment with it. Move over to the Console tab once you’ve got code to test out and debug.

Javascript references and tutorials. W3Schools has loads of both. Mozilla’s JS documentation is top-notch, and I often just keep their reference lists of built-in String and Array functions open in tabs as I code. StackOverflow is useful for questions, but don’t assume the code snippets you find there are always reliable or copypastable.

That’s it. No development environment. No installing node.js or Ruby or Java or two different versions of Python. No build tools, no dependency management, no fucking Docker containers. No command line, even. Just a browser extension, the browser’s built-in dev tools, and reference material. Let’s go.

You might also want:

jQuery and its documentation. If you’re wrestling with a mess of generic spans and divs and sparse, unhelpful use of classes, jQuery selectors are your best bet for finding the element you want before you snap and go on a murderous rampage. jQuery also happens to be the most ubiquitous JS library out there, the essential Swiss army knife for working with Javascript’s... quirks, so experience with it is useful. It gets a bad rap because trying to build a whole house with a Swiss army knife is a fool’s errand, but it’s excellent for the stuff we're about to do.

Git or other source control, if you’ve already got it set up. By all means share your work on Github. Greasy Fork can publish a userscript from a Github repo. It can also publish a userscript from an uploaded text file or some code you pasted into the upload form, so don’t stress about it if you’re using a more informal process.

A text editor. Yes, seriously, this is optional. It’s a question of whether you’d rather code everything right there in Tampermonkey’s live editor, or keep a separate copy to paste into Tampermonkey’s live editor for testing. Are you feeling lucky, punk?

Project #1: Hack on an existing userscript

Install some nifty-looking scripts for websites you visit regularly. Use them. Ponder small additions that would make them even niftier. Take a look at their code in the Tampermonkey editor. (Dashboard > click on the script name.) Try to figure out what each bit is doing.

Then change something, hit save, and refresh the page.

Break it. Make it select the wrong element on the page to modify. Make it blow up with a huge pile of console errors. Add a console.log("I’m a teapot"); in the middle of a loop so it prints fifty times. Savor your power to make the background wizardry of the internet do incredibly dumb shit.

Then try a small improvement. It will probably break again. That's why you've got the live editor and the console, baby--poke it, prod it, and make it log everything it's doing until you've made it work.

Suggested bells and whistles to make the already-excellent AO3 Savior script even fancier:

Enable wildcards on a field that currently requires an exact match. Surely there’s at least one song lyric or Richard Siken quote you never want to see in any part of a fic title ever again, right?

Add some text to the placeholder message. Give it a pretty background color. Change the amount of space it takes up on the page.

Blacklist any work with more than 10 fandoms listed. Then add a line to the AO3 Savior Config script to make the number customizable.

Add a global blacklist of terms that will get a work hidden no matter what field they're in.

Add a list of blacklisted tag combinations. Like "I'm okay with some coffee shop AUs, but the ones that are also tagged as fluff don't interest me, please hide them." Or "Character A/Character B is cute but I don't want to read PWP about them."

Anything else you think of!

Project #2: Good Artists Borrow, Great Artists Fork (DIY blacklisting)

Looking at existing scripts as a model for the boilerplate you'll need, create a script that runs on a site you use regularly that doesn't already have a blacklisting/filtering feature. If you can't think of one, Dreamwidth comments make a good guinea pig. (There's a blacklist script for them out there, but reinventing wheels for fun is how you learn, right? ...right?) Create a simple blacklisting script of your own for that site.

Start small for the site-specific HTML wrangling. Take an array of blacklisted keywords and log any chunk of post/comment text that contains one of them.

Then try to make the post/comment it belongs to disappear.

Then add a placeholder.

Then get fancy with whitelists and matching metadata like usernames/titles/tags as well.

Crib from existing blacklist scripts like AO3 Savior as shamelessly as you feel the need to. If you publish the resulting userscript for others to install (which you should, if it fills an unmet need!), please comment up any substantial chunks of copypasted or closely-reproduced code with credit/a link to the original. If your script basically is the original with some key changes, like our extra-fancy AO3 Savior above, see if there’s a public Git repo you can fork.

Project #3: Make the dread Tumblr beast do a thing

Create a small script that runs on the Tumblr dashboard. Make it find all the posts on the page and log their IDs. Then log whether they're originals or reblogs. Then add a fancy border to the originals. Then add a different fancy border to your own posts. All of this data should be right there in the post HTML, so no need to derive it by looking for "x reblogged y" or source links or whatever--just make liberal use of Inspect Element and the post's data- attributes.

Extra credit: Explore the wildly variable messes that Tumblr's API spews out, and try to recreate XKit's timestamps feature with jQuery AJAX calls. (Post timestamps are one of the few reliable API data points.) Get a zillion bright ideas about what else you could do with the API data. Go through more actual post data to catalogue all the inconsistencies you’d have to catch. Cry as Tumblr kills the dream you dreamed.

Project #4: Make the dread Tumblr beast FIX a thing

Create a script that runs on individual Tumblr blogs (subdomains of tumblr.com). Browse some blogs with various themes until you've found a post with the upside-down reblog-chain bug and a post with reblogs displaying normally. Note the HTML differences between them. Make the script detect and highlight upside-down stacks of blockquotes. Then see if you can make it extract the blockquotes and reassemble them in the correct order. At this point you may be mobbed by friends and acquaintainces who want a fix for this fucking bug, which you can take as an opportunity to bury any lingering doubts about the usefulness of your scripting adventures.

(Note: Upside-down reblogs are the bug du jour as of September 2019. If you stumble upon this post later, please substitute whatever the latest Tumblr fuckery is that you'd like to fix.)

Project #5: Regular expressions are a hard limit

I mentioned up above that Dreamwidth comments are good guinea pigs for user scripting? You know what that means. Kinkmemes. Anon memes too, but kinkmemes (appropriately enough) offer so many opportunities for coding masochism. So here's a little exercise in sadism on my part, for anyone who wants to have fun (or "fun") with regular expressions:

Write a userscript that highlights all the prompts on any given page of a kinkmeme that have been filled.

Specifically, scan all the comment subject lines on the page for anything that looks like the title of a kinkmeme fill, and if you find one, highlight the prompt at the top of its thread. The nice ones will start with "FILL:" or end with "part 1/?" or "3/3 COMPLETE." The less nice ones will be more like "(former) minifill [37a / 50(?)] still haven't thought of a name for this thing" or "title that's just the subject line of the original prompt, Chapter 3." Your job is to catch as many of the weird ones as you can using regular expressions, while keeping false positives to a minimum.

Test it out on a real live kinkmeme, especially one without strict subject-line-formatting policies. I guarantee you, you will be delighted at some of the arcane shit your script manages to catch. And probably astonished at some of the arcane shit you never thought to look for because who the hell would even format a kinkmeme fill like that? Truly, freeform user input is a wonderful and terrible thing.

If that's not enough masochism for you, you could always try to make the script work on LiveJournal kinkmemes too!

[tariqk]

Thinking about Lisp, software development and collaboration.

So like I've been reading a lot of Paul Graham's On Lisp, and Doug Hoyte's Let Over Lambda, and it's been... interesting.

Cut to spare the timeline.

Like, I don't pretend that I understand these works completely, or that I have anything more than a semi-functional understanding of Lisp — most of my work on Lisps have been on Emacs Lisp, which is really showing it's age, and I've honestly never touched macros in any reasonable level, because honestly speaking macros have a frightening reputation. Thanks to Graham and Hoyte's walkthrough of some of the concepts, though, I think my understanding's a little better, though it can only be tested if I can implement stuff on Common Lisp, if that day ever comes.

What struck me about the commentary was that, well, how much both Hoyte and Graham are fans of the language, and how they often extol its virtues. To both of them, Lisp is something that transcends other languages, that allow programmers to do things that are closer to the problem domain than anything else that people have made. That, when you make a programming language approach the kind of power, extensibility and flexibility that Lisp does, surprise! You've made another flavor of Lisp.

This is a seriously grand claim, but I kept being bugged by one question:

If Lisp Was So Good, Why Isn't It Used More Often?

Like, seriously, I kept reading these claims, and to some degree I could see them backing these claims with examples... and yet if you look at Common Lisp and Scheme projects on the Internet... they're like... scattered and fragmented. You can code, and most importantly, an overwhelming number of people do, from the beginning to the end, full-stack web applications in JavaScript. Lua gets used in everything from window managers to video games customization to desktop widgets. Python's still prevalent in web development to data sciences, and yes, some video games are customized in Python. Like, Ruby was everywhere for a while before it receded.

Like the only exceptions to this are, I guess, Emacs Lisp, which basically sticks with Emacs, and Clojure, which is tied to the JVM, and ClojureScript, which outputs JavaScript. Note how reliant they are on other software and frameworks.

The Answers I've Seen So Far

So, what gives? Like, I've been looking around, and I've seen basically two answers:

Lisp Isn't Popular Because People Are Stupid

No, seriously. This is the argument. Paul Graham engages in it:

People frightened by Lisp make up other reasons for not using it. The standard excuse, back when C was the default language, was that Lisp was too slow. Now that Lisp dialects are among the faster languages available, that excuse has gone away. Now the standard excuse is openly circular: that other languages are more popular.

(Beware of such reasoning. It gets you Windows.)

Popularity is always self-perpetuating, but it's especially so in programming languages. More libraries get written for popular languages, which makes them still more popular. Programs often have to work with existing programs, and this is easier if they're written in the same language, so languages spread from program to program like a virus. And managers prefer popular languages, because they give them more leverage over developers, who can more easily be replaced.

Hoyt engages in this, as well:

Macros have, not by accident, almost as much history as lisp itself, being invented in 1963 by Timothy Hart[MACRO-DEFINITIONS]. However, macros are still not used to the fullest possible extent by most lisp programmers and are not used at all by all other programmers. This has always been a conundrum for advanced lispers. Since macros are so great, why doesn't everybody use them all the time? While it's true that the smartest, most determined programmers always end up at lisp macros, few start their programming careers there. Understanding why macros are so great requires understanding what lisp has that other languages don't. It requires an understanding of other, less powerful languages. Sadly, most programmers lose the will to learn after they have mastered a few other languages and never make it close to understanding what a macro is or how to take advantage of one. But the top percentile of programmers in any language are always forced to learn some sort of way to write programs that write programs: macros. Because it is the best language for writing macros, the smartest and most determined and most curious programmers always end up at lisp.

I mean, the argument is pretty clear: because Lisp is so powerful, and that it takes so much study and effort to work at it, that only top-tier programmers are the only ones who understand Lisp. Implied, however, is the assumption that if you don't get Lisp, well, you're not a top-tier programmer, and you Just Don't Get It.

Which gets to the second explanation of why Lisp isn't popular:

Lisp Users Are Assholes

I mean, the above quotes are a sampling, and, honestly, a mild one, of the perceived attitudes of Lisp aficianados to the outside world. And it doesn't help that Hoyt then proceeds to call other non-Lisp Languages “Blub”, which, despite his many attempts to soften the blow, just makes him sound like an asshole. Like, you could have said “other languages”, dude. Sure it's less efficient, but you're dealing with people, not machines.

Like, Mark Tarver has an essay about the assholishness of Lisp users, which I don't recommend you read, because CONTENT WARNING ableism1. Maybe if you wanna take a look at commentary on that, you can go for Rudolf Winestock's The Lisp Curse, which is a little better, I guess?

Lisp is so powerful, that it encourages individual independence to the point of bloody-mindedness. This independence has produced stunningly good innovation as in the Lisp Machine days. This same independence also hampers efforts to revive the “Lisp all the way down” systems of old; no “Lisp OS” project has gathered critical mass since the demise of Symbolics and LMI.

[...]

Why [doesn't the Lisp community] make a free development system that calls to mind some of the lost glories of the LispM, even if they can't reproduce another LispM?

The reason why this doesn't happen is because of the Lisp Curse. Large numbers of Lisp hackers would have to cooperate with each other. Look more closely: Large numbers of the kind of people who become Lisp hackers would have to cooperate with each other.

The argument is, commercially, if you're a brilliant asshole, no one wants you. While your brilliance would be an asset for a while, what really makes organizations and enterprises scale isn't the fact that they hire brilliant people, but that they hire and use people brilliantly, in ways that are robust and don't rely on having the Right Kind of People on board. It's also why computer security is such a fucking thing to get right, because most of the solutions seem to be... hire the best in the industry and go with that? Which works great until your Chief Security Officer gets run over by a bus a better offer from the competition. Then what?

I mean, yes, capitalist models rely on you having a development workforce that is fungible, because it is cheaper in the long run, but it also reduces risk, even if reducing labor costs aren't a thing for you. It's also more democratic that way, because, yes, you need it to be accessible and approachable to the people who are affected by your code. And it needs to be reproducible, because if not, what if it's scientific work and we need to verify it?

But, even then, this diagnosis — that, charitably, the expressiveness of Lisp attracts brilliant assholes who can't even be convinced to work with one another rankles, because it fundamentally means that there's no solution. The language is too good for normies, and only assholes will use it, ∴ that's the end. Nothing more can be said.

I wonder if there's more to it. And I suspect there might be.

The Social Models Around Lisp Might Actually Be Toxic

Notice the commonality around the four people I've quoted above?

Yup.

They're all white dudes.

I'm not saying that the Lisp community is so toxic because the loudest voices within Lisp are all white men. I'm saying that the fundamental assumptions that these white men have about what is good might actually be a reason why Lisp's community might be so toxic.

There's a difference. Bear with me.

Graham actually talks about the process of developing software in Lisp — the bottom-up approach — but he talks about it in a way that assumes that development occurs with a single person, and that the final vision of the problem space is the insight of one person, or a small group of people with a common enough vision: sort of a Cathedral-style system. Does it have to be?

Why can't bottom-up development occur in a collaborative, cooperative system? Sure, Lisp “doesn't have syntax” (which always weirded me out — it does have syntax, just one that's “invisible” and “self-evident” to a certain class of mind). One that eschews the models that we're used to in capitalist and hegemonic systems. If Lisp is one of the purest forms of mathematical expression, what Hoyt refers to as a “U-Language”, shouldn't it be universally accessible and open to critique?

Maybe the reason why Lisp doesn't work is because the social models around Lisp — one that erases and diminishes the contributions and the lives of people who aren't white men of a certain analytical mindset — make it fail. Maybe whiteness — the social construct, one that lionizes individual brilliance of a specific kind, emphasizes competition over collaboration, pretends that there is an Objective™ Truth over the experiences of others, and considers all emotions other than violent, abusive ones weakness — is the reason why Lisp fails, despite its expressiveness and power.

Maybe the way to do it is to change the way people learn Lisp, and work with Lisp, and collaborate with Lisp, rather than the model we have today.

Could something like that, a system that allows easy, safe collaboration, and organisations that deliberately go for minority and disadvantaged groups, be something that could kick Lisp out of its doldrums?

He calls these people “brilliant bipolar minds”, because, of course. Just because you can diagnose the problem doesn't mean that you don't have the problem as well. ↩︎