a while ago I saw a thread somewhere (I think on GitHub?) about replacing oppressive terminology in sclang. I thought this was awesome, and it made me feel really good to be (a small) part of a community which, in contrast to many others, genuinely seems dedicated to inclusion and making everyone feel good. Props to the team and community for this!
Recently I realised that the term ‘stutter effect’, common in electronic music, might be kinda ableist. I spoke with my sister, who’s a speech pathologist, and she agreed that it’s not cool. I was wondering if it would be super difficult to come up with a different name for Pstutter and any other examples in sclang that are based on this terminology.
This isn’t something I want to make a big deal about, just something that occurred to me, and I wondered if anyone else has any thoughts on the topic. Since I don’t actively contribute to SC (and couldn’t because I am still a baby in the world of programming), I can’t really make demands. But I’d be grateful if people who do work on SC could maybe think/talk about it.
The second “bracket” is due to SC lacking a flatMap operator (I guess it would be called flatCollect). Putting these terms together is probably not feasible. I would also not use terms like ‘multiply’, ‘repeat’, or ‘times’ that could be confused with arithmetic operations, or operations on the entire collection. Somehow the operation on each element must be conveyed. And there is no Each tradition in SuperCollider (AFAIK), so there is no precedence of saying dupEach or repeatEach.
I guess reproduce could work, even though it’s another metaphor, given that we imagine a bottom-up multiplication on the basis of individual elements of a population? In terms of a non-interpolating expansion, perhaps stretch could work as well, if it wasn’t already used by patterns. Maybe dilate? Or if you think of a volume (balloon), perhaps inflate.
Edit: Or if staying with the idea of getting stuck: hang (taken by Condition), stick (bit unclear), stall.
Ah yeah, this is a good point, thank you for bringing it up. This is whole topic in itself, but I’ve been really disappointed by the number of artists who will exploit speech and neurological disorders to make their work appear more interesting (if I had a dollar for every “aphasia-inspired” piece I’ve sat through…).
I don’t think it would be hard at all. I just took a quick look over our codebase for some common words considered ableist, and found a few uses of “crazy” and “idiot” that we could easily change (I am still trying to remove these from my vocabulary myself). Usage in actual function and class names is a bit harder to remedy, but by no means impossible. The typical approach is to:
mark to-be-removed functions and classes as deprecated, which causes a log message when they are used that indicates the intended replacement/alternative
wait. This depends a lot on how popular the feature is and how difficult it is for people to change their code, and we unfortunately still haven’t landed on a super clear idea of how long is long enough.
remove the feature in a future release and document this in the changelog
There is one small hangup, which is that Dstutter is actually a server plugin, too, and I don’t know if we’ve ever gone through a deprecation cycle with that before.
No, thank you for bringing it up! This is really important and something we absolutely have a responsibility to address.
This also reminds me that we’ve had complaints for a long time that screen readers do not work well with the IDE. So yes, this is something we developers definitely need to get better at prioritizing.
SuperCollider’s been around for almost a quarter century(!); removing this would presumably break a lot of compositions. Why not leave the function as-is, create an alias to something with a name you prefer, and leave a note in the docs that modern style prefers a different name?
I’m aware of one music programming language that occasionally alters syntax between versions: LilyPond.
To handle this, LilyPond supplies scripts for version upgrades, to search for old-style syntax and replace it with the newer version. (LilyPond also has a convention to tag each source file with a \version "x.y.z" line at the top, so that the scripts know the version from which the files are being converted.)
We probably couldn’t do this 100%. A class name change would be straightforward (as I said on github this morning, in UNIX environments, a simple sed would take care of the change being proposed here). A method name change could be trickier, unless it’s globally changing all definitions of the same method.
But, at minimum, we could help users find places where something may have changed.
The current way to advise users of deprecated keywords is, practically speaking, to flood their post window with warnings. (Sure, it’s in the changelog, but when the changelog is hundreds of lines, it’s very easy to overlook.) From a user-experience perspective, that’s certainly not ideal. But it isn’t the only way to handle it, either.
I’m stuttering and I find zero offence in Pstutter… shrug. I think it’s a fitting metaphor and it’s not used in a negative way (except for people who think that repetition in music is bad :-p)
I agree there’s zero offence in “stutter”. I’ve stuttered all my life (sometimes), and I can’t think of a better word to describe the speech pattern. It’s the word I use to prepare strangers for my stuttering on the phone.
In a rhythmic context, the word stutter does very well to describe the process. Is there even another word? For me, “reiterate” doesn’t seem right.
Generally speaking, stuttering (sometimes) is part of my “character”. It’s pretty low-down on the list of things I’d like to change about myself, however terrible other people might think it is…
Hope I don’t come over as ‘ranty’ or ‘opinionated’, I just want to give my 2p as a stutterer/Pstutter user. But admittedly, I do really like the word ‘stutter’. When I’m not stuttering, it just rolls off the tongue…
We probably couldn’t do this 100%. A class name change would be straightforward (as I said on github this morning, in UNIX environments, a simple sed would take care of the change being proposed here). A method name change could be trickier, unless it’s globally changing all definitions of the same method.
I’d strongly recommend against giving people a script that just seds through the user’s source files. This will rewrite comments, strings, variables with the same prefix or suffix, import statements, etc.
The current way to advise users of deprecated keywords is, practically speaking, to flood their post window with warnings. (Sure, it’s in the changelog, but when the changelog is hundreds of lines, it’s very easy to overlook.) From a user-experience perspective, that’s certainly not ideal. But it isn’t the only way to handle it, either.
As a side note, where is the RFC for this? If implemented as a deprecation-then-removal, many users’ code will be broken (or, as James notes, flooded with deprecation notices such that useful post window output will be buried). On Github people are already discussing the replacement name with breakage a foregone conclusion but afaik this hasn’t even been mentioned on the mailing lists at all. Quoting from the RFC doc: “Visibility and inclusivity are important values for RFCs.”
Fwiw I don’t have much skin in the game, as Vivid doesn’t use these terms at all, and none of my “legacy” SC code uses them. The biggest effect for me might be that a lot of sccode.org examples would break. The demand-rate UGen question is a trickier one, though.
The deprecated method and error object predate RFCs. We could have an RFC to change established practice but I doubt we will spend time RFCing every previously established practice.
As for a sed script – there’s another thread for this, where the idea of automatically sed-ding has already been discarded.
I did not discover stutter for some time because it was not immediately clear what it would do - repEach or repElement are technically clear (especially for non English speakers who may have good technical vocabulary but limited vocab otherwise.)
a non-desctructive deprecation, which aliases the function and removes the previous version from documentation is cost-less (excepting some bloat)
If ppl want to spend energy moving the language toward greater clarity and/or inclusion I think that’s great - keeps the language alive.
