There appear to be a lot of folks in the comments, who came into the thread quickly to offer a negative reaction or critical review of the article. I think it's rather telling, to pay attention to...
Exemplary
There appear to be a lot of folks in the comments, who came into the thread quickly to offer a negative reaction or critical review of the article. I think it's rather telling, to pay attention to the focus they are bringing to this discussion and where that focus may have come from. Absent a single, currently collapsed comment, I don't think anyone who came here is coming with bad faith, but it is rather telling that the way they have chosen to approach and interact here is more or less entirely in alignment with the author's premise in both their article and their paper. There is a strong focus on "facts" as examined through the lens of logic and mathematics, and notably a particularly negative one. While there are discussions present about what the author does well, the statements are often hedged with qualifiers, such as "we already have a word for this". Yes, we do, and that word is a concept which exists today because it was built on the shoulders of feminism. But perhaps more importantly, why spend an entire comment's focus on the choice of words and close to none of a comment's focus on the material it addresses? Perhaps ironically, the author already addresses this very behavior in the paper under the section titled "Systems of Scientific Domination".
I don't mean to be excessively negative about the response I'm seeing, but it is rather surprising how consistently this kind of behavior can be observed whenever anyone offers a criticism aimed at institutions designed by men, even when they do not directly criticize any men directly. I personally found this article and paper well thought out, providing a lot of critical thinking points about the institutions we've built and what we lose by focusing too tightly on certain areas/specifics. For example, I've often thought that some programming languages are unnecessarily complex, using symbols in ways that are not easily readable in order to collapse a complex idea into a tidy bundle, but I never had good words to reason why we shouldn't be doing that other than "this is difficult to read". The author brings up a good point about how screen readers would struggle with this unnecessarily complex notation, which is a point I had never considered. Similarly, calling out that programming languages are often obsessed with mathematics, she helps to frame the concept of starting on different footing. What would a programming language which consciously focuses effort and energy at it's ability to be understood by non-programmers, to be accessible to those with disabilities, to center the programmer/designer, or to maximally allow collaboration look like? What other ways could the very idea of a programming language expand to, if we are to consider the far-reaching outcomes of some lines of code?
In a similar vein, there's a lot of criticism of this paper for being too broad and not offering enough meat to it's suggestions. I agree that it would have been quite nice if this paper was actually 100 pages long instead of 18 and really dove into the nitty gritty for each of the short subjects it touches on. But I don't think that was the purpose of this paper. Does it not surprise you that there is so much to talk about? That someone can write a coherent paper at a high level that touches on so many problems? This is, ultimately, a paper about design, not a paper about specifics. We don't live in a world where these design practices have been followed to fruition so it would be very difficult to provide specific examples because they either do not exist, or one would need a near-prophetic knowledge of the field to pull out examples where one of the use-cases was employed, but not starting from a design methodology as outlined by the author. Instead, each section of this paper could be a paper on it's own. This paper is meant to inspire people working in the field, to speak to feminists who are interested or already doing research on language diversity in programming (for example) and to provide them a rough framework on how to tie this back to other concepts. It's also meant to speak to people who are not feminists in these areas of expertise and remind or inform them of the merits of diverse thinking. Importantly, at least for me, it's here to speak to people interested in equity and inclusion and to give them talking points and thoughts to bring up when we're involved in processes such as hiring new employees, tracking efficiency, increasing diversity, evaluating tools or programming languages, and other day-to-day applications of the theories discussed in this paper.
As a short aside- I really wasn't expecting to learn about programming languages as it applies to crochet patterns today. This was an excellent paper precisely because it didn't fit the very mold it spends much of it's length criticizing. It's not rare for me to stumble upon an academically satisfying paper, but it is quite a bit more rare for me to stumble upon a paper which inspires creativity and expands my thinking. This paper managed to thread both of those needles, and for that I'm grateful.
A perceived outsider has come into a group of insiders and offered perceived criticism against the thing that unites the insiders, thus earning their ire. A tale as old as time, a limitation...
A perceived outsider has come into a group of insiders and offered perceived criticism against the thing that unites the insiders, thus earning their ire. A tale as old as time, a limitation humanity is unlikely to overcome.
Tildes is a tech-focused site, despite its forages into other topics, most folks here have a software development background. Layered onto that are a few things:
Developers are, ultimately, practical people. If you want to impress developers, you do it by developing something cool. If you want to make a programming language with a focus on being inclusive, you have to do it, or developers won't care.
Software development is a male dominated space, so on top of the outsider coming in to critique what unites the group spiritually, they come in and look different too! (Shocker, whoah :OOOO how can people just do that?? /s)
I agree with you that people are approaching this a bit too harshly. It's clearly not directed at developers (evident by the huge paragraph titled What is a programming language?), however whenever a non-expert in a specific topic attempts to do some intersectionality, the experts are going to gather and watch with nervous curiosity like monkeys watching tourists in tropical countries, especially because Feminism:tm: is cool now and (western) companies want to be feminist so what if this non-expert's opinion suddenly induces change that we don't like???
I will offer one critique to your comment though: It is very useful to think about how to make programming more inclusive. It's not very useful to center the design of a programming language around non-programmers reading it, because non-programmers tend not to read code. The result of such an exercise is a language, that at best, programmers don't want to touch because it sucks to actually use. Don't design the scalpel after the needs of the painter, design it after the needs of a surgeon.
Mind you, I totally agree with you with the overt focus on maths. It's too much, and has less to do with actual programming than the maths-heavy comp sci curricula of most universities would let you think. However, maths has two very big advantages:
The way solving maths forces you to think is a great precursor on how you need to think to solve programming tasks
Comp Sci is an extremely broad field. I honestly expect it to shatter into multiple fields with time, it's not been around for too long yet. To some extent, this has already happened. The current issue with that is that Comp Sci thus needs to teach you a lot of shit, and unfortunately, maths is the basis for a lot of famous algorithms that are used to teach the basics of programming and algorithm design at uni.
The best people to practically do stuff like this are always those that start off with a background in programming and then branch out into the humanities and return to their original craft to examine it under a new light and with new knowledge. Or the other way around. But like you said, people here aren't really engaging with the posted article on that level. We're the monkeys, sitting on a tree, watching the tourists and bickering about how they didn't bring any nuts or fruits this time around.
I don't really know whether this person is an expert or not, but I completely understand - this post happened more or less exactly how I expected it to go from the moment I saw the topic. I think...
whenever a non-expert in a specific topic attempts to do some intersectionality, the experts are going to gather and watch with nervous curiosity
I don't really know whether this person is an expert or not, but I completely understand - this post happened more or less exactly how I expected it to go from the moment I saw the topic. I think it's important for all the different kinds of conversation that have happened in these comments to happen, but wanted to draw attention to something that was missing on Tildes (but not on lobsters as another commenter pointed out).
It's not very useful to center the design of a programming language around non-programmers reading it, because non-programmers tend not to read code. The result of such an exercise is a language, that at best, programmers don't want to touch because it sucks to actually use. Don't design the scalpel after the needs of the painter, design it after the needs of a surgeon.
I don't really think anyone was truly arguing that, but rather that we should be including more people in the design process to ensure the end product has appropriately weighed all possible designs before committing to one. We have to keep in mind that there will be people who don't program in this language who are then exposed to it, and think about how they interact with the code. We also have to consider that machines might try to parse this (such as LLMs or interfaces), people without coding knowledge or without the same expertise may try to parse this (interns troubleshooting, managers browsing, etc.), and just in general that not everything should be designed through the lens of a single individual programming in isolation. But you are absolutely right that the surgeon's input on a scalpel's initial design is rightfully the center of attention. We should not, however, discount other important individuals such as epidemiologists or chemists or kinesiologists or materials experts. These experts, and countless others can enhance a tool by examining it through a different lens (reducing infections, increasing ergonomics, reducing cost, and so on).
The best people to practically do stuff like this are always those that start off with a background in programming and then branch out into the humanities and return to their original craft to examine it under a new light and with new knowledge. Or the other way around.
Certainly these are the individuals who will help to shift the field, write new instruction manuals, and so forth- but do not underestimate how simply engaging with an article like this and thinking about it can help to make the field, as a whole, more welcoming of people with different opinions. The very folks you're lauding as the best to do this have likely experienced a lot of push-back from people over their career. Rather than adding to the stack by offering criticism and negative thoughts, perhaps instead consider engaging with the content, think about what gems can be gleaned from it, what you might apply to your own day-to-day and leave a positive remark on what works so that we can inspire these folks to continue their pursuit of better and more inclusive design.
Correct. People are arguing that the people who have worked their entire lives on exactly this have never thought of it before. This happens all the time, and it happens a ton with coding. On the...
I don't really think anyone was truly arguing that, but rather that we should be including more people in the design process to ensure the end product has appropriately weighed all possible designs before committing to one.
Correct. People are arguing that the people who have worked their entire lives on exactly this have never thought of it before.
This happens all the time, and it happens a ton with coding.
On the one hand, coding is FULL of elitism and snobbery that makes it miserably hard to get new things adopted and good ideas get passed over for a dogma.
On the other hand coding is probably one of the largest surface area tools ever created and is constantly dealing with a million different competing advantages and disadvantages and no idea which problems are ephemeral and which we'll still be dealing with in 10 years.
The entire stance boils down to "hey you people who've dedicated your lives to this, probably never thought of....." which is basically the realm of conspiracy theory nonsense, especially on such a simple level.
Hell just in the last 4-5 years we've had TONS of talk about what terminology is even acceptable in coding, and it arguably cost an insane amount of hours and time, and yet I doubt many people could even list the "changes" that were made.
She's a programming language designer and PL academic. I don't think she's arguing that no one has thought about the issues before. She's arguing that the feminist critical lens is helpful to...
She's a programming language designer and PL academic. I don't think she's arguing that no one has thought about the issues before. She's arguing that the feminist critical lens is helpful to approach those problems. Yes it's annoying when people talk out of school about a different field of expertise, but I don't see it happening here.
And mind you, I'm very happy you did. Engaging with a new perspective can yield positive results; the real only problem is your own energy and willingness to do so and your time. I do think that...
I don't really know whether this person is an expert or not, but I completely understand - this post happened more or less exactly how I expected it to go from the moment I saw the topic. I think it's important for all the different kinds of conversation that have happened in these comments to happen, but wanted to draw attention to something that was missing on Tildes (but not on lobsters as another commenter pointed out).
And mind you, I'm very happy you did. Engaging with a new perspective can yield positive results; the real only problem is your own energy and willingness to do so and your time. I do think that people here in the comments can definitely fall into group thinking because our backgrounds tend to be similar. It's why someone going out of their way to read the entire 16 pages of the report and approaching it with a different mindset is so valuable.
Exactly. "You should do things differently." "Source is available, go fork and have fun with that." COBOL (by reputation) and SQL (by experience) come to mind. SQL is actually nice for easy cases...
If you want to make a programming language with a focus on being inclusive, you have to do it, or developers won't care.
Exactly.
"You should do things differently."
"Source is available, go fork and have fun with that."
The result of such an exercise is a language, that at best, programmers don't want to touch because it sucks to actually use
COBOL (by reputation) and SQL (by experience) come to mind. SQL is actually nice for easy cases but quickly makes you reach for a different tool when things get tough.
The current issue with that is that Comp Sci thus needs to teach you a lot of shit, and unfortunately, maths is the basis for a lot of famous algorithms that are used to teach the basics of programming and algorithm design at uni
I've been saying for years now that CS at the undergrad level ought to make a formal split into Comp Sci and Software Engineering. Most algorithm questions in job interviews are more like quizzing an 1800s university graduate their knowledge of Latin and Greek than testing their suitability for the job.
watching the tourists and bickering about how they didn't bring any nuts or fruits this time around
Those are hella rude tourists!
Feminism™ is cool now and (western) companies want to be feminist so what if this non-expert's opinion suddenly induces change that we don't like???
Thank you for including this line. If this weren't the case, a paper like this would've been ignored. Perhaps mocked a bit in the chuddier corners of the internet, but not incited flame wars. Humanities academia does humanities nonsense, news at 11.
However, if this article (or similar ones) catches the ear of company decision-makers, prepare for pointless changes. That's how you get DEI training that ignores the actual DEI problems in the company in favor of those popular among external training organizations that year. "Let's implement a people-centered tech stack" is the kind of thing an executive who spends too much time with HR bosses would mandate
See, something that gets ignored about this approach though is that people who try to do things differently even in a practical way like that will still experience pushback because they are going...
"Source is available, go fork and have fun with that."
See, something that gets ignored about this approach though is that people who try to do things differently even in a practical way like that will still experience pushback because they are going against the grain.
Programmers, even with their inherent practical background, are still people, and people are mostly fallible. We cannot hide about some notion of peak objectivity that only programmers have, because it's just not true. Think back on the master/main brach discussion for git. It's a harmless change, fixed within one line of the config and for repo users it's no change at all. There was tremendous debate around it.
If the person who wrote this paper decided to go about it in a practical way, I can still see wave of barely concealed hatred be sent their way about "What's even the point of this" and "They way we are doing things right now is great already, this is useless".
Yes, folks from the humanities viewing things from through a certain lens can get a tad silly. But it's also a different perspective and why it's important to remain skeptical, one should be careful to not let that skepticism border into cynicism.
Just because we're "the experts" does not mean that we'll be right. There is a bigger chance that we might be, but it's absolutely not a guarantee, and people are very very very prone to group-think. If you ever want a cautionary tale of experts ruining a good chance, read up on the life of the venerable doctor Ignaz Philipp Semmelweis. He did, and tried to introduce an objectively good thing. The people of the medical field rewarded him with so much hatred that he ended up dying in an asylum at an early age.
And it is annoying because they’ve clearly done no research. They are not the first to think of this and as others have pointed out it has been done. It is honestly annoying in any field to have...
What would a programming language which consciously focuses effort and energy at it's ability to be understood by non-programmers, to be accessible to those with disabilities, to center the programmer/designer, or to maximally allow collaboration look like?
And it is annoying because they’ve clearly done no research. They are not the first to think of this and as others have pointed out it has been done.
It is honestly annoying in any field to have someone with a minimal understanding of your field to come in and then explain why what you’re doing is wrong because you haven’t considered trying it this way, when it’s a well documented and known thing
Yeah. For what it's worth it's worth investigating new ways to code, and to visualize it, but at the same time the core issue is that it's just more layers between you and what you want to do....
Yeah.
For what it's worth it's worth investigating new ways to code, and to visualize it, but at the same time the core issue is that it's just more layers between you and what you want to do.
They're nice learning tools, but it's also inherently kinda doomed because as things like COBOL have shown, doing more complex processes in verbose syntax just leads to coders wishing desperately they could do it faster.
There are TONS of valid tools, like the insane improvements that have been made to IDE's(intellisense, debugging, hell there's even tools for the blind), but that's a layer higher than the language level.
This bit here...is just wrong: Emphasis mine. I can make a reasonable argument about why AWK and SQL are programming languages....but HTML is not executable any more than UML is. That's as far as...
This bit here...is just wrong:
[...] it can be argued they are not a programming language, such as UML, AWK or SQL. UML is not executable, so could easily be disregarded as a programming language, but is not. HTML, which is executable however, is not seen as a programming language in regular PL discourse.
Emphasis mine. I can make a reasonable argument about why AWK and SQL are programming languages....but HTML is not executable any more than UML is.
That's as far as I got for now (out of time) but that line set me off so bad I can't think rationally about the paper, and I think it's better if I step back and try to continue with a clearer head.
Edit: Ok, finished after that visceral reaction cooled off. Here's the thing.... I feel like this paper would have been much more useful if they had done at least one of the following things:
Provided specific examples about non-inclusive design choices in programming languages. The lack of an example makes it difficult for me to ground the ideas presented in reality.
Provided a simplified psuedo-code example of what a more inclusive language might look like. It's kind of the inverse of the first, but I can understand that there is a seperate problem space of identifying problem and providing solution.
As it stands...it kind of feels a shallow paper with hollow arguments. Kind of like accusing math proofs about being privileged. There's only so far you can map societal problems into other domains, so in this case, the proof is in the pudding, so to speak.
The Turing-completeness of HTML+CSS is actually quite controversial, since it requires user input. Repetition, whether its through recursion, loops, jumps, etc. is usually considered to be key to...
The Turing-completeness of HTML+CSS is actually quite controversial, since it requires user input. Repetition, whether its through recursion, loops, jumps, etc. is usually considered to be key to Turing machines.
SQL was in a similar boat until SQL-99, which added CTEs and thus a form of recursion.
That said, there's a recent response buried in the thread you linked that operates through hover events, such that the user can leave their cursor and go hands-off during execution, which seems like a more convincing proof to me.
I have never seen a conversation about whether a language "counts" as a programming language that wasn't intended to denigrate people who write code in that language and generally foster an...
I have never seen a conversation about whether a language "counts" as a programming language that wasn't intended to denigrate people who write code in that language and generally foster an exclusive "we're better and smarter than you" environment that is extremely hostile to newcomers or anyone perceived as an outsider (which still today is heavily influenced by one's gender and race). Criticizing the author for not specifically distinguishing HTML+CSS from HTML is doing the exact same thing she's criticizing in that very section -- much less getting "set off" by it so bad that it made you unable to rationally engage with the rest of the paper.
It's true that "$lang is not a real programming language" is often used as elitism, but some people legitimately do care about the semantics. HTML especially is a common pet peeve, since its name...
It's true that "$lang is not a real programming language" is often used as elitism, but some people legitimately do care about the semantics. HTML especially is a common pet peeve, since its name specifies that it is a markup language.
The complete web stack includes HTML, CSS and JavaScript, which is definitely a programming language, so a) I don't think it's necessarily a dig at web developers, and b) their interpretation of it as HTML in isolation makes sense to me.
I don't think their interpretation was wrong, but being so upset over someone saying HTML is executable without remotely considering the author may have meant HTML+CSS to the point that you are...
I don't think their interpretation was wrong, but being so upset over someone saying HTML is executable without remotely considering the author may have meant HTML+CSS to the point that you are unable to read the rest of the article without taking a break? That goes beyond just "caring about the semantics".
Perhaps there's some conversation out there where people discuss what counts as a programming language without being disgusting and exclusive, and they actually really care about the semantics rather than trying to signal insidership. I have yet to encounter it.
HTML + CSS is executable in the same sense that Minecraft is executable - technically it's true, but it wasn't designed for that and nobody will choose it to do useful work. It seems clear to me...
HTML + CSS is executable in the same sense that Minecraft is executable - technically it's true, but it wasn't designed for that and nobody will choose it to do useful work. It seems clear to me that the author's claim that HTML is executable was an oversight or misunderstanding. And, honestly, a pretty severe one - if your position is that you can speak authoritatively on programming language design, then you shouldn't make rookie mistakes like that.
I doubt that the author's position is to "speak authoritatively", as this article seems to be very clearly dedicated to critically examining programming languages from a feminist perspective. Not...
I doubt that the author's position is to "speak authoritatively", as this article seems to be very clearly dedicated to critically examining programming languages from a feminist perspective. Not every paper is trying to take an authoritative stance, especially from within the humanities, which is very clearly the author's background.
And again, I have yet to encounter a practical context in which litigating what counts as a programming language isn't used to be dismissive of someone who isn't considered part of the in group. I immediately distrust people who gripe about whether HTML+CSS (or anything similar) "counts" because I have never seen this come from someone who wasn't trying to flex on someone they saw as beneath them.
Also, people absolutely use HTML+CSS to do useful work every day. They're a substantial portion of a front-end developer's toolset, even though they are fundamentally different in their design from something like JavaScript.
This is the big sticking point in my experience. Idk why but STEM folk almost seem allergic to the idea that there can be multiple equally-valid way to analyze something, or that there is value in...
Not every paper is trying to take an authoritative stance, especially from within the humanities
This is the big sticking point in my experience. Idk why but STEM folk almost seem allergic to the idea that there can be multiple equally-valid way to analyze something, or that there is value in analyzing problems from different baseline assumptions inherent to the act of doing the analysis itself and not just what the conclusion is.
Yeah, as someone who came into STEM from a humanities background I've unfortunately encountered this a lot, especially from men in computer science, and seeing it here on Tildes is particularly...
Yeah, as someone who came into STEM from a humanities background I've unfortunately encountered this a lot, especially from men in computer science, and seeing it here on Tildes is particularly frustrating.
STEM, especially at the undergraduate levels, has an emphasis that the universe is fundamentally knowable with correct answers. There may be multiple ways to arrive at such answers, but often only...
STEM, especially at the undergraduate levels, has an emphasis that the universe is fundamentally knowable with correct answers. There may be multiple ways to arrive at such answers, but often only one or two of those are useful: the rest are parlor tricks.
Doing research and validating the methods themselves isn’t often relevant until grad school.
I just want to mention I did ponder that possibility of it being a pedantic oversite, but then discarded it as I don't consider HTML+CSS to be any more executable than UML. I pondered if they...
much less getting "set off" by it so bad
I just want to mention I did ponder that possibility of it being a pedantic oversite, but then discarded it as I don't consider HTML+CSS to be any more executable than UML. I pondered if they meant because it included JavaScript, but that would completely negate the point. LaTeX isn't executable. Nor is Markdown. Nor is XML+XSS. They are useful skills, but they fall under a different category of work: Design.
The point, as I read it, was because HTML was executable, yet not discussed in normal discourse of programming, it was a problem.
So I was hung up on that mistake, because I couldn't stop thinking about it as I continued on, and I noticed I wasn't reading the paper anymore, but trying to justify its wrongness based on them leading with that early error. So I stopped, and returned after a break (and partially because I had other things to do anyway). Which I'm betting a lot of people don't do, and then don't realize their bias is clouding their judgement.
The idea that writing something in LaTeX is more like design than coding is more laughably wrong than anything written in the linked paper. It absolutely is executable, for one. Design tends to...
The idea that writing something in LaTeX is more like design than coding is more laughably wrong than anything written in the linked paper. It absolutely is executable, for one.
Design tends to also be a useful skill to have when performing the tasks in the domain LaTeX is designed for, but there is almost zero overlap between design as a skill and one's ability to actually write code in LaTeX, fwiw. I'm rather proficient in LaTeX code, but I've got almost no design skills to speak of. And this isn't to denigrate design either -- imo it's the far more difficult aspect of laying out a good document and it's almost certainly harder to teach than LaTeX coding is.
TeX (and thus LaTeX) is Turing-complete and skilled programmers have written things like a BASIC interpreter entirely in TeX. Is it a great option for things outside its domain like this? Obviously not. But there is no coherent definition of a programming language that excludes TeX, and the only justification for denying it that "status" is lack of respect for its domain and a desire to gatekeep people whose experience is primarily in that domain.
This more or less seems to be how you're using this technical terminology in your comments. It doesn't matter whether the author makes good points elsewhere in the paper, which is plainly not a technical one, because she failed the shibboleth. In the section where she points out exactly how things like this are used for toxic exclusionism and gatekeeping.
Firstly, LaTeX is definitely executable — it's a fascinating tool that, as I understand it, can only really be parsed by executing it, due to how it's built up out of commands and macros and other...
Firstly, LaTeX is definitely executable — it's a fascinating tool that, as I understand it, can only really be parsed by executing it, due to how it's built up out of commands and macros and other weird bits and pieces.
Tbh, I think your framing of "X is executable and Y isn't" is kind of what the author is getting at in their essay. This is a binary that is rarely helpful, and often hides a deeper understanding of what's going on. For example, YAML is essentially a data notation language, but it can be executed by CI engines, build tools, or deployment systems to create quite complicated effects. To manage those effects fully, you need to be familiar with software development. So yes, YAML by itself may come in a category of non-executable languages, but the people working with it are generally trained developers who are using it in a complex way.
Similarly, you mention HTML as falling under the "design" category of work, but I'm a web developer by trade (and definitely not a designer) and understanding HTML is a key part of my work. I would argue even that designers generally don't understand HTML enough — it is largely a technical tool used for development, and most design systems abstract over it to the level where designers are able to use it. If you are a web developer, you must learn HTML, CSS, and JS to be able to do your job — it doesn't matter if some of these languages are executable, and some aren't!
I'm not trying to argue here that HTML is executable on some technicality of Turing-completeness. There is clearly a category difference between languages like Javascript and languages like HTML in terms of what they were made for and how they are used. However, these categories are only useful insofar as they provide us with useful language to discuss the tools we're working with. That is, it is important to remember that the categories are made by humans and used by humans. This brings us back to the one of the key points of the essay, which is that a lot of key human-centered aspects of PL design are missing from academic discussion of the topic.
So when you say "HTML isn't executable", and stop reading the paper because that's too much of an inaccuracy to deal with, I question whether you are using your categories of "executable" and "non-executable" in a way that is productive for discussion, or if you're using those categories to gatekeep and produce a kind of categorical shibboleth around the subject you're interested in.
That's in essence why the article left me wanting a tangible example. Something to help me wrap my head around the concept and put a bow on it. I'm just saying it felt a little bit like there was...
That's in essence why the article left me wanting a tangible example. Something to help me wrap my head around the concept and put a bow on it.
I'm just saying it felt a little bit like there was an intro to a thesis paper, and then missing the body. And that might just be my own failing.
At the end of the day, with all that in mind, exploring feminism in programming design feels to be putting the cart before the horse, if you will. I think it's a problem that will resolve itself by respecting women in the workplace.
I agree that the article is a bit disappointing in terms of its depth — like you say, it feels like an introduction or a blog post about the actual article, rather than an article worth discussing...
I agree that the article is a bit disappointing in terms of its depth — like you say, it feels like an introduction or a blog post about the actual article, rather than an article worth discussing in-depth in its own right.
That said, I think you're missing the point by saying that we just need more respect of women in the workplace. That's not what the article is trying to argue. The article is saying that the way we analyse programming languages is limited, and could be improved by applying the lens of academic feminism to the subject. Importantly, this is less about solving gender equality issues, and more about looking at one academic subject with the tools of a different academic subject. An essay could equally be written by a English literature academic asking how the tools of English literature studies could be applied to PL design.
As to some specific examples, the author brings up how PL design is incredibly monolingual. The vast majority of code is written in a programming language with keywords and syntax designed around English words and patterns of speech. Academic feminism would prompt us to question that: why do children learning to program in Germany or France, say, need to use these English keywords? Would it be easier for them if programming languages could be more localised? How would this affect the world: whose lives would be made easier, and whose lives would be made more difficult?
Another good example is precisely what we've been talking about just now. There is definitely a distinction between "real" programming languages and DSLs that are more limited. But that distinction is often associated with differences in prestige amongst different programming languages. Why? Why do you distinguish HTML — a DSL that forms a vital part of the infrastructure of modern web apps, but lacks the full power of, say, Javascript — from, say, SQL — a DSL that forms a vital part of the infrastructure of modern web apps, but lacks the full power of, say, Javascript? How does prestige impact how we choose different languages, and how languages are perceived amongst academic (and non-academic) PL designers and users?
For what it's worth, I think that a lot of these questions are asked in modern PL discourse, and I don't think the addition of an academic feminist lens necessarily contributes as much as the author is suggesting. We have experimented with multilingual programming languages (see, e.g. Excel), and while it seems to make things easier for beginners to use, it also becomes harder to manage at larger scales. And the discussion about making error messages easier to understand feels a bit dated given the direction a lot of modern languages are taking.
But I think the act of exploring one academic discipline through the lens of another is still a useful exercise, even if this article isn't necessarily the best exemplar of that.
Because HTML can't do a lot of the things classically considered programming. You can't use HTML to instruct the computer to calculate 1+1, or to sort a list of numbers or to generally get from...
Why do you distinguish HTML from, say, SQL.
Because HTML can't do a lot of the things classically considered programming. You can't use HTML to instruct the computer to calculate 1+1, or to sort a list of numbers or to generally get from state A to state B. You can't implement algorithms, you can't compute a result from input data.1 That makes it different from a language like SQL.
A language like HTML describes a state, it doesn't describe how to do anything with that state. But programming is, at least from a computer science point of view, precisely that "do anything with the state" part. It's describing a path that gets you from one state to another.
So languages like HTML are often not seen as programming languages because they don't allow you to program. There are different names for languages like that and HTML would usually be described as a markup language. That doesn't mean that its not useful, just that it does a different thing.
1: Maybe you can do some of those things via some technicality like interactions with CSS, but it's definitely not what HTML is made for or what it would be practically be used for.
I find it disappointing that you've not responded to the comment - or even paragraph - as a whole, which provides the context for that quote, and instead are focusing on what counts as a "real"...
I find it disappointing that you've not responded to the comment - or even paragraph - as a whole, which provides the context for that quote, and instead are focusing on what counts as a "real" programming language.
The point of that paragraph was that neither SQL nor HTML are general purpose programming languages. I cannot build a CLI, or a web server, or a desktop application using HTML or SQL alone. They are both DSLs with limits to their capabilities.
Now you are correct that SQL can do calculations. But you are incorrect that only SQL manages state. HTML includes plenty of stateful aspects, from how forms and iframes behave, to how code can be executed on various event handlers embedded into the HTML code.
The other important property that many people like bringing up is Turing completeness, but in practice I think this is more of a distraction. Turing completeness has nothing to do with the qualities that we actually need in a general purpose programming language (i.e. whether or not we can command the full range of operating system resources). Instead, it's a very precise mathematical property that tells us something about the classes of computation that exist. But it doesn't really give us a sense of anything outside that. For example, the previous poster referenced TeX as a markup language, and distinguished it from executable programming languages, but TeX is actually Turing complete, and you can do some very complex things with it, including writing interpreters for other languages. But again, it's a very specific DSL for a very specific purpose, and it is absolutely not a general purpose programming language that you could use for more everyday tasks. The poster was not wrong to call it a markup language, I think they were just wrong about what that implies.
Which again leads to the question: if both HTML and SQL are tools designed for specific niches, with only limited ability to interact with the world outside their custom-designed engines, why is it so important that we distinguish one of them as a "programming language" and the other as, well, not that?
It isn't about Turing completeness, otherwise we'd be using that specific phrase and making more precise, mathematical claims.
It isn't about whether we can use them for general purpose programming, because we can't - neither is suitable for most programming purposes, as they are both run in very limited environments.
I would argue that the answer is primarily about status. "HTML is not a programming language" has become such a meme that as soon as the claim is made, people rush in to demonstrate that they're a real programmer because they know the difference. But as a real programmer, who works with HTML on a daily basis, I think this is missing the point. HTML is absolutely a language that I use to program with. It is not a general purpose programming language, but it is one of a number of DSLs that I use to precisely define UIs and how they should behave. SQL is also a language that I use to program with, and is equally not a general purpose programming language, but I still use it to define which data should get loaded from the database. In most of the ways that are relevant to my work, there is little meaningful difference between them other than that they were built for different purposes.
We can see that here in the comments. There is a whole article to discuss, and in my last comment I even tried to unpack the key ideas a bit more and open them up to more discussion. And yet the thing that most people are focusing on is whether or not HTML is a programming language (which, FWIW, wasn't even the terminology used in the original article). Why? Why is it so important to get this right, when it's not even the point of the article?
Like I said at the start of this comment, I'm disappointed that you have focused on this one aspect as well, especially when I made it clear in my comment what the point of the article was. If you want to discuss the article, I'm happy to do that, because there's some interesting ideas in there - even if I don't agree with all of it. But if you just want to discuss whether it not HTML is a programming language, I encourage you to instead reflect on why that claim is so important to you and others in this thread that it's overshadowing actual discussion of the article's points.
I think any paper that features a basic factual error about the topic it discusses would be met with similar scepticism, no? If I was to write a paper on English and mentioned that its direct...
Why is it so important to get this right, when it's not even the point of the article?
I think any paper that features a basic factual error about the topic it discusses would be met with similar scepticism, no?
If I was to write a paper on English and mentioned that its direct roots are believed to be in Vedic Sanscrit, linguists and many other people would point this out to be not correct.
Similarly many programmers care about the distinction between markup languages and programming languages. For me it's basically a reflex to correct the idea that HTML is executable. It is a very basic thing to get wrong, and understanding the difference can help to gain insight into the basics of programming.
Ultimately I think it connects us when we can agree on a shared factual truth. That is why it's important.
And secondly, when I encounter a basic error in a paper like this, it will lower my motivation to engage with it at all. If it's that badly researched, I don't expect to gain anything of value from it. That holds true for any media, but especially for programming related articles.
I interpreted your paragraph about HTML and SQL as implying that the both languages are not seen as equal. On the surface this is obvious, since both act in completely different domains doing...
I interpreted your paragraph about HTML and SQL as implying that the both languages are not seen as equal. On the surface this is obvious, since both act in completely different domains doing different things. They are very different. This didn't seem to be your point. Instead, the point seemed to be that people think lower of it, evidenced by them not calling it a programming language. A lack of prestige causes people to not accept the language as a programming language.
The point of my comment was that there is an established meaning of "programming language" that is not based on prestige, but on the languages properties. A language to write program code in. Many people use the term with that meaning and that explains why they apply it to some languages and not others.
I don't think SQL has especially high prestige and I assume not many people actually like the language a lot or think it's a great success of language design. It's ok for what it is, but that's it. I doubt it would qualify for a honorary "programming language" label, I think it gets that label through its properties. I also assume if you leave out all the "advanced" functionality for stored procedures and restrict it to just classical "SELECT/INSERT/UPDATE" clauses you can easily start a big discussion if that would really still be a proper programming language. Not because that would lessen its prestige, but because it would reduce its functionality.
To a certain extend, being a programming language (and especially a general purpose language) comes with higher prestige. But the reason for the higher status is not that somebody called it a programming language. The reason is that a general purpose programming language is very powerful and you can do a lot of interesting things with it. The narrower the language the less you can do with it and the less amazing people think the language is.
Of course this is just a rule of thumb. Writing shell scripts would generally be considered a form of programming, and shell scripting languages are programming languages, even though I feel like that has very low prestige associated to it.
So I don't see it as higher status leading to more acceptance as as programming language, rather the other way around: Higher general capabilities in the language lead to higher status. HTML only has mediocre status because there are a lot of parts where it has outgrown it's initial design and where it doesn't seem quite the best fit for many of the use cases it is used today. It works and works well in places, but also has its wired parts. So much like most other languages, not stellar, not horrible. I don't think it really has lower status than SQL, but of course that's completely subjective.
Does higher prestige in a language cause people to more likely want to learn it. Of course. In this example though it will hardly be relevant to the decision to HTML or SQL. The deciding point will be what you want to do with it, since they do completely different things.
Is it necessary to have the term "programming language" limited to just languages for writing program code? It's not necessary per se, but lots of people use it with that meaning and applying the term with a differing definition leads to confusion and, evidently, lots of unnecessary discussion.
There are thousands of computer languages and trying to have a few categories for them according to their properties makes life easier. Those language labels transport information about what that language is used for. HTML has a different use case than Javascript or SQL, so it makes sense to have a word for that. SQL also does something special, so there are labels like "query language" or "database language" to describe that. As you mention, its a "domain specific language" as opposed to a "general purpose programming language", another two categorizations that give the reader information about the capabilities and targets of a specific language. All those labels are given to languages based on their capabilities and use cases, and I claim that it's the same for the term "programming language".
Of course there are gray areas at the boundaries of these definitions, but that's always the case. With a more general definition of programming language, the problems just move. Is Markdown a programming language? It can be used to instruct the computer to render fancy formatted text. It can even be used to generate HTML. Is writing a plain text file programming? It can be used to instruct the computer to render non-fancy unformatted text. While I'm getting silly here the point is simply: there will always be corner cases where one can argue how something should be classified. That HTML is kind of on the border of some of the existing definitions is not a disparagement of HTML, it's just the nature of classifying things into different categories.
You are completely right that going into Turing completeness doesn't really help to capture what is commonly seen or used as a programming language and is therefore often not useful expect on a very technical/theoretical level. People tend to fall back on that because has not gray area. Its the one clearly defined and objective concept in that area. Something is either Turing complete or not. So that sounds nice, but is practically not as useful as one might hope. It's also a very theoretical concept, in practice nothing is Turing complete because all our programs operate on limited memory.
So why is it so important if HTML is a programming language? It isn't generally, but it seems central to your argument about it's low prestige. You argue how HTML is used in programming all the time and how not calling it a programming language therefore shows the low respect it gets. So that invites discussion if low respect really is the main reasons for not calling it a programming language and what otherwise makes a programming language.
Of course this is all tangential to the article and even the start of the comment thread, but I feel that is in the nature of long comment threads.
One analogy that one might use to illustrate the difference between a markup language and programming language is the difference between the frame of a car and its power train. The frame is a...
One analogy that one might use to illustrate the difference between a markup language and programming language is the difference between the frame of a car and its power train. The frame is a critical component, but it's in an entirely different category than the powertrain is — it provides structure for the rest of the car to bolt to, whereas the powertrain is responsible for making the car move. A car with the powertrain substituted out for another strangely shaped frame would not be functional.
It's true that the software development community has a bad habit of drawing this distinction for the purpose of denigration (which is unnacceptable and shouldn't be tolerated), but that doesn't mean that the distinction is without legitimate purpose.
The multilingual language mentioned, inexplicably referred to as Arabic-based immediately after it was introduced*, was kind of an attempted gesture in that direction, but I agree that I would...
The multilingual language mentioned, inexplicably referred to as Arabic-based immediately after it was introduced*, was kind of an attempted gesture in that direction, but I agree that I would have liked to see more of that and less of all the other things going on in this paper.
* I had a whole second paragraph here about how replacing one language not everyone speaks with a different language not everyone speaks is a non-solution. Upon rereading, I realized the mentions of Arabic in section 1.1 had led me to conflate Hedy with the Arabic-based Lisp mentioned in 6.2. I still think that one is a bad idea.
I would say the paper has overloaded the word “feminism” to the point of no longer being useful. We already have a perfectly good word for what the paper is actually talking about: inclusivity....
I would say the paper has overloaded the word “feminism” to the point of no longer being useful. We already have a perfectly good word for what the paper is actually talking about: inclusivity.
Which is not to say the paper doesn’t have good points, but it’s really struggling to coerce the terminology.
It is difficult to know what someone mean by "feminism" because feminism is incredibly broad. It's a similar situation to the word "socialism". When employing these terms it is useful to present a...
It is difficult to know what someone mean by "feminism" because feminism is incredibly broad. It's a similar situation to the word "socialism". When employing these terms it is useful to present a brief explanation on how they should be interpreted in the context of the article. I don't believe this article does that. Without it each reader will just default to their own personal bias.
In any case, this post gives me the impression of something that is meant for a very specific context which is not available to me. I don't think this was meant for the general public. Maybe it's not a bad article it's just not really an article.
Charitably, I might just assume that is a piece of a conversation I didn't follow from the beginning.
Most articles are pieces of a conversation we didn't follow from the beginning. Some try to bring everyone up to speed, but others don't, and they really don't need to. My take: It's a programming...
Most articles are pieces of a conversation we didn't follow from the beginning. Some try to bring everyone up to speed, but others don't, and they really don't need to.
My take: It's a programming language theory article intending to point out that there is another useful theoretical lens to apply. I expect that anyone without an interest in both sociocritical methods and formal system design would not grok this one off the bat, and that someone with an interest in either sociocritical methods or programming language design may be tempted by the article to go read more on the other.
I'm seeing a lot of comments that seem to think the two topics can't be worthwhile to combine, and that just sounds like preference or prejudice to me. Not speaking of you, just in general. I'm more baffled by the arguments I'm seeing set out in the comments than those in the article, personally.
But do you have an example for how feminism (or the lack of it) does influence language design? I have absolutely no idea what this even means. In the past years I followed the design of the Zig...
But do you have an example for how feminism (or the lack of it) does influence language design? I have absolutely no idea what this even means.
In the past years I followed the design of the Zig language, and it all revolves around logic, readability, language concepts, etc., but never around men/women/non-binary people/gender, patriarchy and feminism, or other societal topics. And why should it? It's a programming language. Everybody can use it to express ideas in code.
I'm probably super ignorant, but usually I have a vague idea what I don't understand.
For me it would be much easier to reason about this with concrete examples of what this is actually about.
I certainly don't have any examples or firm opinions on the matter, as I'm in neither area. But my thoughts go to: We should actively consider cons along with the obvious pros of writing...
I certainly don't have any examples or firm opinions on the matter, as I'm in neither area. But my thoughts go to:
We should actively consider cons along with the obvious pros of writing anglocentric PLs
The governing bodies, development structure, etc are absolutely worth examining for unthought-of power issues
And the ones that stick out from the article are user-centric error messaging, accessibility considerations, etc. These are all things that have improved general web design, informatics, and other technical practices, but somehow pointing out that the feminist lens and intellectual tradition helped drive those changes is treated as aversive or nonsensical.
The argument I keep seeing that inclusivity !== feminist is misplaced in that feminists actively developed theory and analytic approaches to identify unacknowledged decisions and practices affected by unacknowledged power structures.
None of this is to criticize folks for not readily understanding what she's suggesting. It's one thing to not get it, another to get it and disagree on the merits, and a whole other more intellectually lazy thing to disagree because of not getting it and then getting into weird meta discussions of the merit of the exercise. Normal people socializing problems. That's all.
I would be wary of reading too much into it, this post is extremely specific and not very concerned in educating a random reader. It is probably a good idea to be just as charitable to the...
I would be wary of reading too much into it, this post is extremely specific and not very concerned in educating a random reader. It is probably a good idea to be just as charitable to the reactions as I tried to be charitable with the post.
Oh sure. I wouldn't single someone out to rake them over the coals. I'm just surprised at the forms of argument taking shape about this one and wanted to reframe it a little.
Oh sure. I wouldn't single someone out to rake them over the coals. I'm just surprised at the forms of argument taking shape about this one and wanted to reframe it a little.
For people getting hung up on what "feminism" should and shouldn't denote: There are analytic and theoretical approaches that examine power structures through a critical lens. Those approaches are...
Exemplary
For people getting hung up on what "feminism" should and shouldn't denote:
There are analytic and theoretical approaches that examine power structures through a critical lens. Those approaches are considered feminist approaches because that is where they historically developed, specifically for the purpose of the advancement of women (NOT the diminution of men).
Saying "oh that's fine for the humanities/philosophy, etc, but not for application to formal systems" as though a feminist critique of computational practices were a category error...is mistaken. All human endeavors take place in a social context that involves power structures, which could affect those endeavors in important ways.
Feminist legal theory, for example, was driven by concern for women and has been pivotal in bringing into question invisible power concerns, such as the ways power has affected how the law was formed over time, how it is administered, how it is enforced, unacknowledged social side effects, etc. The author is doing that with programming language design.
Please try to get over your semantic hangups. We are all newcomers to endless topics and should keep some humility there rather than assume that reasons for nomenclature should be immediately, obviously justified to outsiders. There's no reason for her to give a full history of the development of feminism and it's applications. Instead she did the appropriate thing, which is to identify and briefly define the lens she's using. You can criticize the lens and the definition, but please read up on it first.
I'm still reading the paper itself but I found this preface and the discussion around it on lobsters to be fascinating. My initial impression of the title was this piece would be about a gender...
I'm still reading the paper itself but I found this preface and the discussion around it on lobsters to be fascinating. My initial impression of the title was this piece would be about a gender imbalance in some PL maintainer councils, however defining feminism as an examination and force of change in systems of power made me reflect on why gender imbalances exist and how feminism isn't just about gender.
For tildes readers who felt skeptical or guarded when you read the title: Can you reflect on why you had that reaction? Does feminism have a negative connotation in your mind? Why is that? Some of the commenters on lobsters exhibited this reaction, and I'd love to hear a reflection on it in real time. When I was younger I think I would have had a negative first impression of the title, I'm not sure when that changed for me, but I'm glad I no longer think or feel that way.
I wouldn’t say feminism has a negative connotation for me. I would say that I’m highly skeptical that programming language design is male biased, based on my pretty extensive experience with a...
I wouldn’t say feminism has a negative connotation for me. I would say that I’m highly skeptical that programming language design is male biased, based on my pretty extensive experience with a wide range of programming languages. This is akin to saying that, for example, mathematics or physics notation has a male bias.
So that’s my initial reaction and why I was skeptical going into it. I think from the lens of feminism as a meaningful word in a shared vocabulary, my skepticism is justified — they do not make a case that there is any male bias in programming language design.
After reading the paper, I could see that the author has conflated feminism with the larger concept of inclusivity. From this new, and in my mind unreasonable, definition, I can sort of see where they are going with it.
I do agree with the author that programming language design does, in some cases, have some linguistic inclusivity issues. I still reject the idea that Anglocentrism also falls under the purview of feminism though.
Interestingly enough, I think this sentiment matches what the author is talking about in PL design. It seems like people are more focused on what is or isn’t feminism, like the author being told...
Interestingly enough, I think this sentiment matches what the author is talking about in PL design. It seems like people are more focused on what is or isn’t feminism, like the author being told what is or isn’t a programming language. I think there’s more room for thinking critically about why people are focused on attacking the semantics of the paper when they admittedly agree with the overall sentiment.
It goes hand in hand with the “masculine” quantitative analysis when studying PL design, where the community is more focused on rigid and formal structure than a “feminine” qualitative evaluation.
Admittedly I still haven’t finished the paper itself but what I’ve read so far isn’t reasonably thrown out because it uses the lens of feminism. I don’t think that feminism in this paper means inclusivity, but thinking critically about what assumptions or biases led to inclusivity not being appreciated or considered in PL design. I think example of presenting an Arabic programming language being met with questions about its difficulty or if it’s useful, then asking why does the community think this way, falls within the bounds of feminism.
There’s a sentiment in the paper I understand but I don’t think I’m smart enough to properly express or articulate. I think most people are missing the point and I wish I knew how to explain it.
As an aside, I think it's actively harmful to talk about quantitative and qualitative reasoning as being masculine and feminine. My daughter's computer science teacher is constantly going off on...
It goes hand in hand with the “masculine” quantitative analysis when studying PL design, where the community is more focused on rigid and formal structure than a “feminine” qualitative evaluation.
As an aside, I think it's actively harmful to talk about quantitative and qualitative reasoning as being masculine and feminine. My daughter's computer science teacher is constantly going off on this and it's not just very irritating to her, but I think that sort of thing is part of why the class has only two girls in it.
I don’t think that feminism in this paper means inclusivity, but thinking critically about what assumptions or biases led to inclusivity not being appreciated or considered in PL design.
Alright, I don't think that's really feminism either. What this paper reads like is, someone has a really strong interest in feminism, and has come to the not unsurprising realization that there are parallels in feminist thought that resonate with inequality and disparity in other areas of life.
However, one could do this from any other critique of society and do the same thing and it would read identically, but be identically wrong. This could equally have been written as "decolonization in programming language design" or "class consciousness in programming language design" or any other similar angle, and they'd be equally shallow.
What you are describing here is the act of analyzing something through a feminist lens, which is what the author states they are doing throughout the paper. Feminism isn't just a socio-political...
Alright, I don't think that's really feminism either. What this paper reads like is, someone has a really strong interest in feminism, and has come to the not unsurprising realization that there are parallels in feminist thought that resonate with inequality and disparity in other areas of life.
What you are describing here is the act of analyzing something through a feminist lens, which is what the author states they are doing throughout the paper. Feminism isn't just a socio-political movement, it is also a philosophical framework.
However, one could do this from any other critique of society and do the same thing and it would read identically, but be identically wrong. This could equally have been written as "decolonization in programming language design" or "class consciousness in programming language design" or any other similar angle, and they'd be equally shallow.
I don't think they are wrong. You can think that a feminist lens isn't a useful perspective for this subject, but from my reading of the paper they are correctly applying a feminist lens to PL design. What do you see in the paper that is an inaccurate assessment when thinking from a feminist framework?
Honestly, analyzing PL design from a lens of decolonization or class consciousness would be a great thing to do! We should be analyzing everything from multiple frameworks/lenses. Some of those analyses might be summed up as "this basically aligns with the status quo" or "this framework wasn't particularly applicable or useful for analysis", and those would be good, worthwhile things to do. I don't know if this applies to you, but this is something I encounter A LOT when talking to people who have more traditional-STEM backgrounds: there is not one "correct" lens to analyze something from; there are infinitely many. It seems like the STEM people I talk to view a paper like this as something that is either "correct" or "incorrect" based on if they personally agree with the conclusions the author makes, and that just isn't how the humanities would approach a paper like this. The questions of "Is this a correct application of a feminist lens to PL design" and "How much value do I think this lens has with respect to PL design" are independent questions, neither of which is guaranteed to have a binary result.
To jump on this aside, think that talking about this like it's a fact (and especially like it's a biologically-determined fact) is indeed harmful. But I also think that, because this stereotype is...
As an aside, I think it's actively harmful to talk about quantitative and qualitative reasoning as being masculine and feminine. My daughter's computer science teacher is constantly going off on this and it's not just very irritating to her, but I think that sort of thing is part of why the class has only two girls in it.
To jump on this aside, think that talking about this like it's a fact (and especially like it's a biologically-determined fact) is indeed harmful. But I also think that, because this stereotype is so pervasive in our society, there is still merit in discussion of not unduly privileging the quantitative or denigrating the qualitative, because I think that can still interact with sexism in ways that can harm people, especially if you aren't aware of the possibility.
I’d bet the discussion on Lobsters would’ve had a chance at being productive if the title matched the contents. At very least, it would’ve been an on-topic unproductive conversation.
I’d bet the discussion on Lobsters would’ve had a chance at being productive if the title matched the contents. At very least, it would’ve been an on-topic unproductive conversation.
There are interesting feminist arguments about philosophy's obsession with a particular approach to logic and rigorousness that failed to give space for alternative ways of thinking that are...
There are interesting feminist arguments about philosophy's obsession with a particular approach to logic and rigorousness that failed to give space for alternative ways of thinking that are equally valid, and which are sometimes considered inherently feminine. Similar observations have been made for how philosophy is markedly white and European, excluding African and Asian schools of thought.
I unfortunately don't have any references to show, I just remember reading about it but I don't remember from. That's something /r/askphilosophy might help with.
I've heard this arguement, and I do think it holds merit within the context of philosophy and many other areas. However, computers are just overgrown calculators. You're not going to stray too far...
I've heard this arguement, and I do think it holds merit within the context of philosophy and many other areas.
However, computers are just overgrown calculators. You're not going to stray too far from mathematics and logic at the end of the day.
That said, the most interesting thing to me is that most of the 'human computers' that worked for NASA were women. They were also some of the first computer programmers. These were mathemeticians back when humans could do much of this math faster than computers.
A computer is a tool that humans interact with in order to accomplish a task. The baseline assumptions the creator of a tool makes are reflected in that design. The method and language for...
However, computers are just overgrown calculators. You're not going to stray too far from mathematics and logic at the end of the day.
A computer is a tool that humans interact with in order to accomplish a task. The baseline assumptions the creator of a tool makes are reflected in that design. The method and language for interacting with that tool influences how users approach completing that task. You move beyond mathematics and logic the second a human gets involved in the process.
It's baffling because we'll see fierce discussion of how important design features of various programming languages are when the thread is about static vs dynamic typing, but when it comes to a...
It's baffling because we'll see fierce discussion of how important design features of various programming languages are when the thread is about static vs dynamic typing, but when it comes to a thread like this, all programming languages are just pure math and their design is irrelevant.
I don't have much dog in the hunt on this paper, because I see it more as an exploratory call to action. The premise I certainly accept, that design choices can channel thought. Pulling out one of...
I don't have much dog in the hunt on this paper, because I see it more as an exploratory call to action. The premise I certainly accept, that design choices can channel thought. Pulling out one of the oldies:
The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense. - Edsger W. Dijkstra
I think where I am a little unsatisfied is what I see as a lack of preliminary analysis on something more concrete. But I do appreciate a call for more research for what it is.
That said I did get a chuckle at the line about the "mathematicification" of programming, simply because computer science departments and in some cases IT departments started as clusters in math departments.
But it seems obvious to me that design choices could have all sorts of effects, which is why cobol is evil. It's the quantification and the analysis I really want to see.
I'll start by saying that I am way out of my depth on this, being a self-taught programmer without much in the way of college-level schooling in humanities, but I think lack of concrete-ness is...
I think where I am a little unsatisfied is what I see as a lack of preliminary analysis on something more concrete.
I'll start by saying that I am way out of my depth on this, being a self-taught programmer without much in the way of college-level schooling in humanities, but I think lack of concrete-ness is one of the easiest ways to make something grating on STEM-oriented individuals.
As much as that crowd could probably stand to adopt some flexibility, if the audience is intended to be STEM-oriented (not saying that this paper is or isn't), it's probably a good idea to keep this in mind.
I think the timing here explains things. Cobol first was developed in 1959 and that quote is from 1975. Cobol has been continuously updated since it was released, but by 1975 different patterns...
I think the timing here explains things. Cobol first was developed in 1959 and that quote is from 1975. Cobol has been continuously updated since it was released, but by 1975 different patterns had emerged that shows the limitations of cobol.
I used to be an IBM systems programmer and I regularly coded in COBOL, C, natural, assembly, and of course JCL to being things together. Cobol definitely felt limiting even compared to those other old languages, except assembler.
(Old man voice) "Back in my day we wrote server side code in assembler to dynamically generate HTML that we passed to CICS region calls with a natural interface to C subsystems. And we liked it that way."
My main intent was to disprove the whole 'masculinity of rationality/logic'. And broadly, that's why I needed a concrete example of how this actually plays out. Because the first step to running...
My main intent was to disprove the whole 'masculinity of rationality/logic'.
And broadly, that's why I needed a concrete example of how this actually plays out. Because the first step to running the program is to strip away all of the human elements to something the computer can run. It makes it hard for me to fathom the concept of a langauge that would be able to remove itself so entirely from this core.
Sorry, I want to make sure I answer the right question: are you asking how human assumptions and biases impact programming language design and by extension how problems are approached and solved?
Sorry, I want to make sure I answer the right question: are you asking how human assumptions and biases impact programming language design and by extension how problems are approached and solved?
I'll preface this by saying I'm sick, so odds are my usual foot-in-mouth is probably worse than usual. But I want to give it a go so you don't wait around forver. The computer itself is a purely...
I'll preface this by saying I'm sick, so odds are my usual foot-in-mouth is probably worse than usual. But I want to give it a go so you don't wait around forver.
The computer itself is a purely rational, algorithmic device. I do not think there exists legitimate arguement that it isn't.
To interact with it at the lower levels, you must speak its languange, as it cannot learn yours. As such, any langauge that builds upon that is still bounded by needing to be translated. The constructs available will reflect what the machine is capable of, as you are instructing a machine what to do.
The paths that stem from that will be diverse, some leaning harder into the math and others abstracting farther.
But that's just it, they're all just divergent paths that all lead to the same end point.
No programming language is directly communicating "in the computer's language" though, so even under the premise that the binary machine code itself is pure rationality, that doesn't mean the...
No programming language is directly communicating "in the computer's language" though, so even under the premise that the binary machine code itself is pure rationality, that doesn't mean the human-designed systems for interfacing with them are inherently purely rational and algorithmic, nor that they are without flaws and biases. Even people who code in Assembly aren't writing pure binary, and even the programming languages we consider low-level these days are still full of human-designed syntax and abstraction. That's arguably the point of programming languages, after all -- they're for making it easier for us humans to write something human readable that can still get translated into binary eventually.
I too wish the author had included more concrete examples and delved into this with more depth. That said, I think it should be easy to see, at least from studying the most extreme examples, that programming languages can absolutely be designed in ways that hinder human users' ability to write code even if the ultimate result is identically rational to the computer running the binary. Look at Brainfuck or INTERCAL. It's also not hard to find examples where the design of a language can impede certain people from being able to use it as effectively as others -- Piet would be extremely frustrating for a colorblind person to use, for instance. These examples are deliberately extreme, but their extremeness should at least make the fact that this is something that is at least theoretically possible more obvious.
I was reading "On Lisp" by Paul Graham (free download of the book can be found here) and something he said made me think of your comment. Sorry for the wall of text but I wanted to include as much...
I was reading "On Lisp" by Paul Graham (free download of the book can be found here) and something he said made me think of your comment. Sorry for the wall of text but I wanted to include as much context for the quote as possible. The quote starts at the bottom of page vi of the preface and runs onto most of page vii. Emphasis is mine:
Understandably, introductory Lisp books do not emphasize the differences between Lisp and other languages. They have to get their message across to students who have, for the most part, been schooled to think of programs in Pascal terms. It would only confuse matters to explain that, while defun looks like a
procedure definition, it is actually a program-writing program that generates code which builds a functional object and indexes it under the symbol given as the first argument.
One of the purposes of this book is to explain what makes Lisp different from other languages. When I began, I knew that, all other things being equal, I would much rather write programs in Lisp than in C or Pascal or Fortran. I knew also that this was not merely a question of taste. But I realized that if I was actually going to claim that Lisp was in some ways a better language, I had better be prepared to explain why.
When someone asked Louis Armstrong what jazz was, he replied “If you have to ask what jazz is, you’ll never know.” But he did answer the question in a way: he showed people what jazz was. That’s one way to explain the power of Lisp—to demonstrate techniques that would be difficult or impossible in other languages. Most books on programming—even books on Lisp programming—deal with the kinds of programs you could write in any language. On Lisp deals mostly with the kinds of programs you could only write in Lisp. Extensibility, bottom-up programming, interactive development, source code transformation, embedded languages—this is where Lisp shows to advantage. In principle, of course, any Turing-equivalent programming language can do the same things as any other. But that kind of power is not what programming languages are about. In principle, anything you can do with a programming language you can do with a Turing machine; in practice, programming a Turing machine is not worth the trouble. So when I say that this book is about how to do things that are impossible in other languages, I don’t mean “impossible” in the mathematical sense, but in the sense that matters for programming languages. That is, if you had to write some of the programs in this book in C, you might as well do it by writing a Lisp compiler in C first. Embedding Prolog in C, for example—can you imagine the amount of work that would take? Chapter 24 shows how to do it in 180 lines of Lisp.
I hoped to do more than simply demonstrate the power of Lisp, though. I also wanted to explain why Lisp is different. This turns out to be a subtle question—too subtle to be answered with phrases like “symbolic computation.” What I have learned so far, I have tried to explain as clearly as I can.
Yeah, women then weren't accepted into schools to be engineers, but could get into math degrees. Black women too, in a world that offered many fewer opportunities for their academic success. And...
That said, the most interesting thing to me is that most of the 'human computers' that worked for NASA were women. They were also some of the first computer programmers. These were mathemeticians back when humans could do much of this math faster than computers.
Yeah, women then weren't accepted into schools to be engineers, but could get into math degrees. Black women too, in a world that offered many fewer opportunities for their academic success. And they were all pushed out of computer programming by men once it became perceived as more prestigious. And then this was all worse once personal computers were seen as "for boys"
It made me feel very skeptical because programming a computer really doesn't have any obvious, direct connection to ones sex or gender. "Feminism in Programming Language Design" reads like the...
It made me feel very skeptical because programming a computer really doesn't have any obvious, direct connection to ones sex or gender. "Feminism in Programming Language Design" reads like the premise would be that current programming languages are male-focused and not really suited for women, that women are somehow disadvantaged by the current programming languages.
Knowing that computer programming is all about abstract thinking, this seems really far fetched, unless the author somehow, at least implicitly, starts from the premise that women are less capable of abstract thinking than men. I don't see any reason to believe such a difference exists, and therefore a paper discussing the consequences of that seems sexist and like a waste of time.
I think the paper's biggest problem is that its way to broad and shallow. It mentions a lot of things, like pretty much all programming languages being in English and the "hard is good" mentality,...
I think the paper's biggest problem is that its way to broad and shallow. It mentions a lot of things, like pretty much all programming languages being in English and the "hard is good" mentality, that I think are solid points, but just kinda mentions them and breezes on to other topics. Also, the preamble about feminism takes up a big chunk of the paper; I'd have preferred that they just assume a basic level of knowledge and/or provide references for those who need it.
I do want to nit-pick the origin of the quote 'No one is free until everyone is free'. The authors quote a speech by Fannie Lou Hamer in the 1970s, but I'm pretty much certain it's a paraphrasing of a much older quote by the anarchist Mikhail Bakunin in the 1870s. Honestly, a lot of modern, 4th-wave feminism feels like watered-down and appropriated anarchism to me.
I am truly free only when all human beings, men and women, are equally free. The freedom of other men, far from negating or limiting my freedom, is, on the contrary, its necessary premise and confirmation.
I'd argue that from how many people in the lobsters and this comment thread seem to be unwilling or unable to understand the difference between "feminism" and a "feminist lens", that the preamble...
Also, the preamble about feminism takes up a big chunk of the paper; I'd have preferred that they just assume a basic level of knowledge and/or provide references for those who need it.
I'd argue that from how many people in the lobsters and this comment thread seem to be unwilling or unable to understand the difference between "feminism" and a "feminist lens", that the preamble was very necessary. Honestly, it has reaffirmed my belief that every STEM major should be required to take two humanities courses, if not more. The stuff people are getting stuck on are concepts tackled in an advanced 100-level or 200-level English course at University.
I'm doubtful such a requirement would move the needle at all. No one questions that there will be some students who discover unexpected passions because of the humanities requirement. However, in...
Honestly, it has reaffirmed my belief that every STEM major should be required to take two humanities courses, if not more. The stuff people are getting stuck on are concepts tackled in an advanced 100-level or 200-level English course at University.
I'm doubtful such a requirement would move the needle at all. No one questions that there will be some students who discover unexpected passions because of the humanities requirement. However, in much the same way that 100 & 200 level STEM breadth courses are considered "asshole profs gatekeeping my path out of poverty" by pre-meds and engineers, humanities courses are often "filler that you do because it's supposed to be done" by the STEM kids. They optimize for whatever grade they need and let the knowledge flow right out the other side once the course concludes.
I don't disagree with you that a lot of STEM kids wouldn't take the courses seriously. I double majored in math and cs at a liberal arts school; I saw and heard how my peers talked about the...
I don't disagree with you that a lot of STEM kids wouldn't take the courses seriously. I double majored in math and cs at a liberal arts school; I saw and heard how my peers talked about the required non-STEM courses. However, I also took a Native American Religion and Culture class freshman year to satisfy some of my graduation requirements and decided to minor in Religious Studies. I had 0 interest in religious studies prior to walking into that class. The requirement to take that course drastically changed my life. If I am purely trying to appeal to STEM kids and focusing on the things they value: the skills I learned from my humanities classes have helped me stand out in job interviews, I am better at communicating my ideas and explaining things, especially to non-technical people like managers which has let me advance in my career at a faster rate than the other people I know in similar fields. Personally, I think it is worth it to make them required. A bunch of people wont learn anything, but plenty of people will and that is enough for me. Especially given the current consequences of the bulk of the tech field having a lack of understanding and/or respect for the humanities.
I agree, for the reason you gave earlier. Especially at the undergrad level, they can be exposed to meaningful contact with subjects in a way that high school level requirements will not. Uni...
it is worth it to make them required
I agree, for the reason you gave earlier. Especially at the undergrad level, they can be exposed to meaningful contact with subjects in a way that high school level requirements will not. Uni should be to provide opportunities to discover new interests, not merely focus on refining your existing talents.
Especially given the current consequences of the bulk of the tech field having a lack of understanding and/or respect for the humanities.
However, I doubt such requirements will move the needle as far as this is concerned. Even for the students who fondly remember discovering a new passion from a humanities requirement, they may not have connected with the larger goal of the humanities distribution requirement. Think of the student who realized "feudal Japan is hella interesting" in an East Asian History 213 course without internalizing the generalizable historical research methods.
skills I learned from my humanities classes have helped me stand out in job interviews; I am better at communicating my ideas and explaining things
Those certainly are true. However, I don't think this specific phrasing would be convincing to a college freshman who is resistant to putting in effort outside his niche interests. What specific things did you learn about interviewing that you don't think you would've picked up elsewhere?
Specifically about interviews, since we're discussing STEMlord boys (this attitude has a notable gender divide), I've found them to be divided between the arrogant and the nihilistic. The arrogant ones think they know it all—perhaps because they've "aced" practice interviews that have no relation to the real grind. If only to game the system, the nihilistic ones will pay closer attention. They disrespect the entire job-hunting process, often (correctly) diagnosing it as a means to screen out autists, but aren't above trying to trick interviewers into hiring them anyway.
It doesn't help that many supporters of distribution requirements do a piss-poor job of explaining the benefits of humanities courses when arguing online. Instead of listing concrete examples like the ones you gave, they give vague hogwash, such as "It helps you become a better person." How exactly would an English class help clarity in writing in a way that a technical writing course would not? This may be my personal bad experience with freshman comp classes, but I learned much more about structured extended argumentation from my history essays than writing fluff about literature. Perhaps the freshman comp stuff would've been better if I had instead had my history class essays cross-graded by comp prof. The history prof grades as they always have, then the comp prof grades for form & structure. Polish something I cared about instead of "I'll just take the B"—even when I got As in that class, I didn't know what I did differently from when I earned Cs, only that the results were different (often correctly labeled as such).
Looking back, I wish I could've filled the analytical writing requirements with my history & sociology classes, then took creative writing to fill the literature & composition distribution. I got into writing short stories (ok, fanfiction) after graduation and sometimes I wish I could've gotten better feedback during my "learning" years.
I couldn't agree more. Thank you for saying that. Technical professions NEED non-technical commentary in addition to the abundant technical commentary in order to improve as fields.
I couldn't agree more. Thank you for saying that. Technical professions NEED non-technical commentary in addition to the abundant technical commentary in order to improve as fields.
I definitely agree, but I was under the impression that every Bachelor's required at least a few. Maybe that's a US only thing? Or perhaps just a California thing?
Honestly, it has reaffirmed my belief that every STEM major should be required to take two humanities courses, if not more.
I definitely agree, but I was under the impression that every Bachelor's required at least a few. Maybe that's a US only thing? Or perhaps just a California thing?
The requirements for a bachelor's degree in a given subject is university-dependent, at least in the US. Gen Ed requirements can vary wildly between institutions as a result, and theoretically...
The requirements for a bachelor's degree in a given subject is university-dependent, at least in the US. Gen Ed requirements can vary wildly between institutions as a result, and theoretically there's no need for them to exist at all (iirc Brown made a big deal of not having them when I went to an info session as a high schooler). Most US schools have some such requirements, but their nature and degree can differ even between different programs at the same university.
I don't disagree, but I was more talking about what would have made the paper better for me. I am by no means an expert on all the main branches of feminist theory, but I know enough to not need...
I don't disagree, but I was more talking about what would have made the paper better for me. I am by no means an expert on all the main branches of feminist theory, but I know enough to not need the intro. I'd just have preferred they went into more depth with that time and space.
I can definitely see the argument for 4th-wave feminism being watered-down anarchism (I'd need to do more reading on both to have a strong opinion there), but I'm not really clear how 4th-wave...
I can definitely see the argument for 4th-wave feminism being watered-down anarchism (I'd need to do more reading on both to have a strong opinion there), but I'm not really clear how 4th-wave feminism could possibly be "appropriating" anarchism by incorporating a lot of its ideas and principles. Isn't that a pretty big goal for philosophies like anarchism? It's not like anarchism is some sort of closed practice, after all.
Yes, but only if the ideas actually retain the core values and aren't white-washed to oblivion. Anarchism has few core concepts, but they are all necessary, they are interwoven into the whole. One...
Yes, but only if the ideas actually retain the core values and aren't white-washed to oblivion. Anarchism has few core concepts, but they are all necessary, they are interwoven into the whole. One is anti-capitalism; of course some feminists and some feminisms are anti-capitalist, but I don't believe feminism is as a whole can be described that way. The other core tenet is an absolute rejection of hierarchies, not a thinking there in bad taste, but fundamentally wrong. Again not a necessary tenet of feminism.
I used the a word appropriating because that's the feeling I get from this paper and similar works. Now, I will note that is feeling that I've had for a while, so I do believe that colored my interpretation of the paper. And I admit its mostly a feeling, but I also can't think of a better word or way to describe it. I really tried here, but nothing else worked. It simply feels like appropriation to me.
I think incorporating anarchist ideas is a big thing that sets fourth-wave feminism apart from the previous waves, so it seems odd to reject them for lacking tenets of anarchism because they're...
I think incorporating anarchist ideas is a big thing that sets fourth-wave feminism apart from the previous waves, so it seems odd to reject them for lacking tenets of anarchism because they're not "core tenets of feminism" while simultaneously criticizing them for trying to incorporate them. It is extremely common for philosophical approaches to borrow ideas from one another -- this is arguably one of the points of reading papers from a given philosophical approach. I'm sure there are varying degrees to how well different individual fourth-wave feminists incorporate anarchist ideas, but I'd challenge you to really ponder why you feel the way you do about them doing so, and whether or not there's an implicit hierarchy involved that you're not fully conscious of.
Okay, I will. I'd appreciate you doing the same. I dislike the biggest-tent feminism that the paper pretty explicitly argues for, because I don't believe I am actual welcome as a fully equal...
Okay, I will. I'd appreciate you doing the same. I dislike the biggest-tent feminism that the paper pretty explicitly argues for, because I don't believe I am actual welcome as a fully equal member. Maybe that's because I have unexamined biases around feminism, but it might also be that I am not welcome. I'll try to spend sometime considering it.
There are strains of feminism that I too am not included in. I am trans masc and most of my friends are trans fem, so trust me I have seen plenty of bad feminist takes. The gender studies course I...
There are strains of feminism that I too am not included in. I am trans masc and most of my friends are trans fem, so trust me I have seen plenty of bad feminist takes. The gender studies course I took in undergrad unfortunately didn't touch on fourth-wave feminism, and I don't know what specifically makes you feel like you cannot be included in any feminism, so I can't give any specific recommendations. I've really only got some passing familiarity with academic feminism, so I'm not the best person to advocate for it, even if many people on Tildes are even less experienced with it. What I will say is that I think it's very likely that a school of feminists that incorporates ideas from anarchism and is deliberately seeking to address societal inequality outside of gender is almost certainly going to be more inclusive of you than a more "traditional" school of feminism like second-wave that explicitly views everything through the lens of sexism and gender-based oppression.
I feel like we are talking across each other a bit. I am not saying I can't identify with any particular feminism or feminist, but that I don't feel included in an abstract and unspecific...
I feel like we are talking across each other a bit. I am not saying I can't identify with any particular feminism or feminist, but that I don't feel included in an abstract and unspecific Feminism™ or in many feminist dialogues. I agree that 4th-wave feminism is MORE inclusive then earlier iterations, but not that its inclusive enough for me to feel actually safe and welcome.
It still minimizes the harm and extent of both female perpetrators and male victims, which is a lot of my personal experience. I think my main point is that 4th-wave feminism uses a lot of anarchist language, while not adopting the underlying principles, or at least that is my concern. I will try to critical engage with this opinion and not take it as fact.
I think this is more or less what I took from your comment, and I honestly can agree there -- our reasons are probably not the same, but particularly when it comes to mainstream pop feminism...
I am not saying I can't identify with any particular feminism or feminist, but that I don't feel included in an abstract and unspecific Feminism™ or in many feminist dialogues
I think this is more or less what I took from your comment, and I honestly can agree there -- our reasons are probably not the same, but particularly when it comes to mainstream pop feminism there's often a lot of poorly-founded junk. I just think it's worth looking into differences in these respects among different feminist authors and movements just as you would with other philosophies -- there are a lot of different points of view and approaches that fall under the big umbrella here. I've heard bell hooks, for instance, addresses the harms men are subjected to and their negative experiences with far more empathy and nuance than your stereotypical pop feminist.
Ultimately I think the abstract and unspecific Feminism™ you're struggling with is similar to the abstract and unspecific anarchism I struggle with due to principally being exposed to anarchists making very bad arguments against eloquent marxist-leninists on Tumblr. The emotional reaction to the shittier, more watered-down version of the movement is justified, but it doesn't necessarily reflect actual Theory or even some consensus within that school of philosophy.
I don't blame you for being put off by pop feminism's approach to men and the "men are perpetrators and women are victims" framework that is common in pop feminism, as much of the same stuff also puts me off -- especially as a trans masc person. But it's worthwhile to engage with individual feminists' work without assuming that it will necessarily reflect that weird pop feminist amalgamation of vibes, because different authors and approaches really can be very different (though I can't speak to whether any of them really incorporate anarchist principles as thoroughly as you want; that's probably something you'd have to decide for yourself on reading a given feminist's work).
I think you've acknowledged most of this yourself, fwiw, so I'm not so much criticising you here as I am just rambling on the topic.
There appear to be a lot of folks in the comments, who came into the thread quickly to offer a negative reaction or critical review of the article. I think it's rather telling, to pay attention to the focus they are bringing to this discussion and where that focus may have come from. Absent a single, currently collapsed comment, I don't think anyone who came here is coming with bad faith, but it is rather telling that the way they have chosen to approach and interact here is more or less entirely in alignment with the author's premise in both their article and their paper. There is a strong focus on "facts" as examined through the lens of logic and mathematics, and notably a particularly negative one. While there are discussions present about what the author does well, the statements are often hedged with qualifiers, such as "we already have a word for this". Yes, we do, and that word is a concept which exists today because it was built on the shoulders of feminism. But perhaps more importantly, why spend an entire comment's focus on the choice of words and close to none of a comment's focus on the material it addresses? Perhaps ironically, the author already addresses this very behavior in the paper under the section titled "Systems of Scientific Domination".
I don't mean to be excessively negative about the response I'm seeing, but it is rather surprising how consistently this kind of behavior can be observed whenever anyone offers a criticism aimed at institutions designed by men, even when they do not directly criticize any men directly. I personally found this article and paper well thought out, providing a lot of critical thinking points about the institutions we've built and what we lose by focusing too tightly on certain areas/specifics. For example, I've often thought that some programming languages are unnecessarily complex, using symbols in ways that are not easily readable in order to collapse a complex idea into a tidy bundle, but I never had good words to reason why we shouldn't be doing that other than "this is difficult to read". The author brings up a good point about how screen readers would struggle with this unnecessarily complex notation, which is a point I had never considered. Similarly, calling out that programming languages are often obsessed with mathematics, she helps to frame the concept of starting on different footing. What would a programming language which consciously focuses effort and energy at it's ability to be understood by non-programmers, to be accessible to those with disabilities, to center the programmer/designer, or to maximally allow collaboration look like? What other ways could the very idea of a programming language expand to, if we are to consider the far-reaching outcomes of some lines of code?
In a similar vein, there's a lot of criticism of this paper for being too broad and not offering enough meat to it's suggestions. I agree that it would have been quite nice if this paper was actually 100 pages long instead of 18 and really dove into the nitty gritty for each of the short subjects it touches on. But I don't think that was the purpose of this paper. Does it not surprise you that there is so much to talk about? That someone can write a coherent paper at a high level that touches on so many problems? This is, ultimately, a paper about design, not a paper about specifics. We don't live in a world where these design practices have been followed to fruition so it would be very difficult to provide specific examples because they either do not exist, or one would need a near-prophetic knowledge of the field to pull out examples where one of the use-cases was employed, but not starting from a design methodology as outlined by the author. Instead, each section of this paper could be a paper on it's own. This paper is meant to inspire people working in the field, to speak to feminists who are interested or already doing research on language diversity in programming (for example) and to provide them a rough framework on how to tie this back to other concepts. It's also meant to speak to people who are not feminists in these areas of expertise and remind or inform them of the merits of diverse thinking. Importantly, at least for me, it's here to speak to people interested in equity and inclusion and to give them talking points and thoughts to bring up when we're involved in processes such as hiring new employees, tracking efficiency, increasing diversity, evaluating tools or programming languages, and other day-to-day applications of the theories discussed in this paper.
As a short aside- I really wasn't expecting to learn about programming languages as it applies to crochet patterns today. This was an excellent paper precisely because it didn't fit the very mold it spends much of it's length criticizing. It's not rare for me to stumble upon an academically satisfying paper, but it is quite a bit more rare for me to stumble upon a paper which inspires creativity and expands my thinking. This paper managed to thread both of those needles, and for that I'm grateful.
A perceived outsider has come into a group of insiders and offered perceived criticism against the thing that unites the insiders, thus earning their ire. A tale as old as time, a limitation humanity is unlikely to overcome.
Tildes is a tech-focused site, despite its forages into other topics, most folks here have a software development background. Layered onto that are a few things:
Developers are, ultimately, practical people. If you want to impress developers, you do it by developing something cool. If you want to make a programming language with a focus on being inclusive, you have to do it, or developers won't care.
Software development is a male dominated space, so on top of the outsider coming in to critique what unites the group spiritually, they come in and look different too! (Shocker, whoah :OOOO how can people just do that?? /s)
I agree with you that people are approaching this a bit too harshly. It's clearly not directed at developers (evident by the huge paragraph titled What is a programming language?), however whenever a non-expert in a specific topic attempts to do some intersectionality, the experts are going to gather and watch with nervous curiosity like monkeys watching tourists in tropical countries, especially because Feminism:tm: is cool now and (western) companies want to be feminist so what if this non-expert's opinion suddenly induces change that we don't like???
I will offer one critique to your comment though: It is very useful to think about how to make programming more inclusive. It's not very useful to center the design of a programming language around non-programmers reading it, because non-programmers tend not to read code. The result of such an exercise is a language, that at best, programmers don't want to touch because it sucks to actually use. Don't design the scalpel after the needs of the painter, design it after the needs of a surgeon.
Mind you, I totally agree with you with the overt focus on maths. It's too much, and has less to do with actual programming than the maths-heavy comp sci curricula of most universities would let you think. However, maths has two very big advantages:
The way solving maths forces you to think is a great precursor on how you need to think to solve programming tasks
Comp Sci is an extremely broad field. I honestly expect it to shatter into multiple fields with time, it's not been around for too long yet. To some extent, this has already happened. The current issue with that is that Comp Sci thus needs to teach you a lot of shit, and unfortunately, maths is the basis for a lot of famous algorithms that are used to teach the basics of programming and algorithm design at uni.
The best people to practically do stuff like this are always those that start off with a background in programming and then branch out into the humanities and return to their original craft to examine it under a new light and with new knowledge. Or the other way around. But like you said, people here aren't really engaging with the posted article on that level. We're the monkeys, sitting on a tree, watching the tourists and bickering about how they didn't bring any nuts or fruits this time around.
I don't really know whether this person is an expert or not, but I completely understand - this post happened more or less exactly how I expected it to go from the moment I saw the topic. I think it's important for all the different kinds of conversation that have happened in these comments to happen, but wanted to draw attention to something that was missing on Tildes (but not on lobsters as another commenter pointed out).
I don't really think anyone was truly arguing that, but rather that we should be including more people in the design process to ensure the end product has appropriately weighed all possible designs before committing to one. We have to keep in mind that there will be people who don't program in this language who are then exposed to it, and think about how they interact with the code. We also have to consider that machines might try to parse this (such as LLMs or interfaces), people without coding knowledge or without the same expertise may try to parse this (interns troubleshooting, managers browsing, etc.), and just in general that not everything should be designed through the lens of a single individual programming in isolation. But you are absolutely right that the surgeon's input on a scalpel's initial design is rightfully the center of attention. We should not, however, discount other important individuals such as epidemiologists or chemists or kinesiologists or materials experts. These experts, and countless others can enhance a tool by examining it through a different lens (reducing infections, increasing ergonomics, reducing cost, and so on).
Certainly these are the individuals who will help to shift the field, write new instruction manuals, and so forth- but do not underestimate how simply engaging with an article like this and thinking about it can help to make the field, as a whole, more welcoming of people with different opinions. The very folks you're lauding as the best to do this have likely experienced a lot of push-back from people over their career. Rather than adding to the stack by offering criticism and negative thoughts, perhaps instead consider engaging with the content, think about what gems can be gleaned from it, what you might apply to your own day-to-day and leave a positive remark on what works so that we can inspire these folks to continue their pursuit of better and more inclusive design.
Correct. People are arguing that the people who have worked their entire lives on exactly this have never thought of it before.
This happens all the time, and it happens a ton with coding.
On the one hand, coding is FULL of elitism and snobbery that makes it miserably hard to get new things adopted and good ideas get passed over for a dogma.
On the other hand coding is probably one of the largest surface area tools ever created and is constantly dealing with a million different competing advantages and disadvantages and no idea which problems are ephemeral and which we'll still be dealing with in 10 years.
The entire stance boils down to "hey you people who've dedicated your lives to this, probably never thought of....." which is basically the realm of conspiracy theory nonsense, especially on such a simple level.
Hell just in the last 4-5 years we've had TONS of talk about what terminology is even acceptable in coding, and it arguably cost an insane amount of hours and time, and yet I doubt many people could even list the "changes" that were made.
She's a programming language designer and PL academic. I don't think she's arguing that no one has thought about the issues before. She's arguing that the feminist critical lens is helpful to approach those problems. Yes it's annoying when people talk out of school about a different field of expertise, but I don't see it happening here.
And mind you, I'm very happy you did. Engaging with a new perspective can yield positive results; the real only problem is your own energy and willingness to do so and your time. I do think that people here in the comments can definitely fall into group thinking because our backgrounds tend to be similar. It's why someone going out of their way to read the entire 16 pages of the report and approaching it with a different mindset is so valuable.
Exactly.
"You should do things differently."
"Source is available, go fork and have fun with that."
COBOL (by reputation) and SQL (by experience) come to mind. SQL is actually nice for easy cases but quickly makes you reach for a different tool when things get tough.
I've been saying for years now that CS at the undergrad level ought to make a formal split into Comp Sci and Software Engineering. Most algorithm questions in job interviews are more like quizzing an 1800s university graduate their knowledge of Latin and Greek than testing their suitability for the job.
Those are hella rude tourists!
Thank you for including this line. If this weren't the case, a paper like this would've been ignored. Perhaps mocked a bit in the chuddier corners of the internet, but not incited flame wars. Humanities academia does humanities nonsense, news at 11.
However, if this article (or similar ones) catches the ear of company decision-makers, prepare for pointless changes. That's how you get DEI training that ignores the actual DEI problems in the company in favor of those popular among external training organizations that year. "Let's implement a people-centered tech stack" is the kind of thing an executive who spends too much time with HR bosses would mandate
See, something that gets ignored about this approach though is that people who try to do things differently even in a practical way like that will still experience pushback because they are going against the grain.
Programmers, even with their inherent practical background, are still people, and people are mostly fallible. We cannot hide about some notion of peak objectivity that only programmers have, because it's just not true. Think back on the master/main brach discussion for git. It's a harmless change, fixed within one line of the config and for repo users it's no change at all. There was tremendous debate around it.
If the person who wrote this paper decided to go about it in a practical way, I can still see wave of barely concealed hatred be sent their way about "What's even the point of this" and "They way we are doing things right now is great already, this is useless".
Yes, folks from the humanities viewing things from through a certain lens can get a tad silly. But it's also a different perspective and why it's important to remain skeptical, one should be careful to not let that skepticism border into cynicism.
Just because we're "the experts" does not mean that we'll be right. There is a bigger chance that we might be, but it's absolutely not a guarantee, and people are very very very prone to group-think. If you ever want a cautionary tale of experts ruining a good chance, read up on the life of the venerable doctor Ignaz Philipp Semmelweis. He did, and tried to introduce an objectively good thing. The people of the medical field rewarded him with so much hatred that he ended up dying in an asylum at an early age.
And it is annoying because they’ve clearly done no research. They are not the first to think of this and as others have pointed out it has been done.
It is honestly annoying in any field to have someone with a minimal understanding of your field to come in and then explain why what you’re doing is wrong because you haven’t considered trying it this way, when it’s a well documented and known thing
Visual programming comes to mind. If I ever have to use LabVIEW again, it will be too soon.
Yeah.
For what it's worth it's worth investigating new ways to code, and to visualize it, but at the same time the core issue is that it's just more layers between you and what you want to do.
They're nice learning tools, but it's also inherently kinda doomed because as things like COBOL have shown, doing more complex processes in verbose syntax just leads to coders wishing desperately they could do it faster.
There are TONS of valid tools, like the insane improvements that have been made to IDE's(intellisense, debugging, hell there's even tools for the blind), but that's a layer higher than the language level.
This bit here...is just wrong:
Emphasis mine. I can make a reasonable argument about why AWK and SQL are programming languages....but HTML is not executable any more than UML is.
That's as far as I got for now (out of time) but that line set me off so bad I can't think rationally about the paper, and I think it's better if I step back and try to continue with a clearer head.
Edit: Ok, finished after that visceral reaction cooled off. Here's the thing.... I feel like this paper would have been much more useful if they had done at least one of the following things:
As it stands...it kind of feels a shallow paper with hollow arguments. Kind of like accusing math proofs about being privileged. There's only so far you can map societal problems into other domains, so in this case, the proof is in the pudding, so to speak.
AWK is absolutely a programming language.
https://github.com/TheMozg/awk-raycaster
SQL is Turing-complete as well. HTML and CSS are Turing-complete in combination.
The Turing-completeness of HTML+CSS is actually quite controversial, since it requires user input. Repetition, whether its through recursion, loops, jumps, etc. is usually considered to be key to Turing machines.
SQL was in a similar boat until SQL-99, which added CTEs and thus a form of recursion.
That said, there's a recent response buried in the thread you linked that operates through hover events, such that the user can leave their cursor and go hands-off during execution, which seems like a more convincing proof to me.
I have never seen a conversation about whether a language "counts" as a programming language that wasn't intended to denigrate people who write code in that language and generally foster an exclusive "we're better and smarter than you" environment that is extremely hostile to newcomers or anyone perceived as an outsider (which still today is heavily influenced by one's gender and race). Criticizing the author for not specifically distinguishing HTML+CSS from HTML is doing the exact same thing she's criticizing in that very section -- much less getting "set off" by it so bad that it made you unable to rationally engage with the rest of the paper.
It's true that "$lang is not a real programming language" is often used as elitism, but some people legitimately do care about the semantics. HTML especially is a common pet peeve, since its name specifies that it is a markup language.
The complete web stack includes HTML, CSS and JavaScript, which is definitely a programming language, so a) I don't think it's necessarily a dig at web developers, and b) their interpretation of it as HTML in isolation makes sense to me.
I don't think their interpretation was wrong, but being so upset over someone saying HTML is executable without remotely considering the author may have meant HTML+CSS to the point that you are unable to read the rest of the article without taking a break? That goes beyond just "caring about the semantics".
Perhaps there's some conversation out there where people discuss what counts as a programming language without being disgusting and exclusive, and they actually really care about the semantics rather than trying to signal insidership. I have yet to encounter it.
HTML + CSS is executable in the same sense that Minecraft is executable - technically it's true, but it wasn't designed for that and nobody will choose it to do useful work. It seems clear to me that the author's claim that HTML is executable was an oversight or misunderstanding. And, honestly, a pretty severe one - if your position is that you can speak authoritatively on programming language design, then you shouldn't make rookie mistakes like that.
I doubt that the author's position is to "speak authoritatively", as this article seems to be very clearly dedicated to critically examining programming languages from a feminist perspective. Not every paper is trying to take an authoritative stance, especially from within the humanities, which is very clearly the author's background.
And again, I have yet to encounter a practical context in which litigating what counts as a programming language isn't used to be dismissive of someone who isn't considered part of the in group. I immediately distrust people who gripe about whether HTML+CSS (or anything similar) "counts" because I have never seen this come from someone who wasn't trying to flex on someone they saw as beneath them.
Also, people absolutely use HTML+CSS to do useful work every day. They're a substantial portion of a front-end developer's toolset, even though they are fundamentally different in their design from something like JavaScript.
This is the big sticking point in my experience. Idk why but STEM folk almost seem allergic to the idea that there can be multiple equally-valid way to analyze something, or that there is value in analyzing problems from different baseline assumptions inherent to the act of doing the analysis itself and not just what the conclusion is.
Yeah, as someone who came into STEM from a humanities background I've unfortunately encountered this a lot, especially from men in computer science, and seeing it here on Tildes is particularly frustrating.
STEM, especially at the undergraduate levels, has an emphasis that the universe is fundamentally knowable with correct answers. There may be multiple ways to arrive at such answers, but often only one or two of those are useful: the rest are parlor tricks.
Doing research and validating the methods themselves isn’t often relevant until grad school.
I think that is a massive flaw in how we teach STEM at undergraduate levels and does a massive disservice to students.
I just want to mention I did ponder that possibility of it being a pedantic oversite, but then discarded it as I don't consider HTML+CSS to be any more executable than UML. I pondered if they meant because it included JavaScript, but that would completely negate the point. LaTeX isn't executable. Nor is Markdown. Nor is XML+XSS. They are useful skills, but they fall under a different category of work: Design.
The point, as I read it, was because HTML was executable, yet not discussed in normal discourse of programming, it was a problem.
So I was hung up on that mistake, because I couldn't stop thinking about it as I continued on, and I noticed I wasn't reading the paper anymore, but trying to justify its wrongness based on them leading with that early error. So I stopped, and returned after a break (and partially because I had other things to do anyway). Which I'm betting a lot of people don't do, and then don't realize their bias is clouding their judgement.
The idea that writing something in LaTeX is more like design than coding is more laughably wrong than anything written in the linked paper. It absolutely is executable, for one.
Design tends to also be a useful skill to have when performing the tasks in the domain LaTeX is designed for, but there is almost zero overlap between design as a skill and one's ability to actually write code in LaTeX, fwiw. I'm rather proficient in LaTeX code, but I've got almost no design skills to speak of. And this isn't to denigrate design either -- imo it's the far more difficult aspect of laying out a good document and it's almost certainly harder to teach than LaTeX coding is.
TeX (and thus LaTeX) is Turing-complete and skilled programmers have written things like a BASIC interpreter entirely in TeX. Is it a great option for things outside its domain like this? Obviously not. But there is no coherent definition of a programming language that excludes TeX, and the only justification for denying it that "status" is lack of respect for its domain and a desire to gatekeep people whose experience is primarily in that domain.
This more or less seems to be how you're using this technical terminology in your comments. It doesn't matter whether the author makes good points elsewhere in the paper, which is plainly not a technical one, because she failed the shibboleth. In the section where she points out exactly how things like this are used for toxic exclusionism and gatekeeping.
Firstly, LaTeX is definitely executable — it's a fascinating tool that, as I understand it, can only really be parsed by executing it, due to how it's built up out of commands and macros and other weird bits and pieces.
Tbh, I think your framing of "X is executable and Y isn't" is kind of what the author is getting at in their essay. This is a binary that is rarely helpful, and often hides a deeper understanding of what's going on. For example, YAML is essentially a data notation language, but it can be executed by CI engines, build tools, or deployment systems to create quite complicated effects. To manage those effects fully, you need to be familiar with software development. So yes, YAML by itself may come in a category of non-executable languages, but the people working with it are generally trained developers who are using it in a complex way.
Similarly, you mention HTML as falling under the "design" category of work, but I'm a web developer by trade (and definitely not a designer) and understanding HTML is a key part of my work. I would argue even that designers generally don't understand HTML enough — it is largely a technical tool used for development, and most design systems abstract over it to the level where designers are able to use it. If you are a web developer, you must learn HTML, CSS, and JS to be able to do your job — it doesn't matter if some of these languages are executable, and some aren't!
I'm not trying to argue here that HTML is executable on some technicality of Turing-completeness. There is clearly a category difference between languages like Javascript and languages like HTML in terms of what they were made for and how they are used. However, these categories are only useful insofar as they provide us with useful language to discuss the tools we're working with. That is, it is important to remember that the categories are made by humans and used by humans. This brings us back to the one of the key points of the essay, which is that a lot of key human-centered aspects of PL design are missing from academic discussion of the topic.
So when you say "HTML isn't executable", and stop reading the paper because that's too much of an inaccuracy to deal with, I question whether you are using your categories of "executable" and "non-executable" in a way that is productive for discussion, or if you're using those categories to gatekeep and produce a kind of categorical shibboleth around the subject you're interested in.
That's in essence why the article left me wanting a tangible example. Something to help me wrap my head around the concept and put a bow on it.
I'm just saying it felt a little bit like there was an intro to a thesis paper, and then missing the body. And that might just be my own failing.
At the end of the day, with all that in mind, exploring feminism in programming design feels to be putting the cart before the horse, if you will. I think it's a problem that will resolve itself by respecting women in the workplace.
I agree that the article is a bit disappointing in terms of its depth — like you say, it feels like an introduction or a blog post about the actual article, rather than an article worth discussing in-depth in its own right.
That said, I think you're missing the point by saying that we just need more respect of women in the workplace. That's not what the article is trying to argue. The article is saying that the way we analyse programming languages is limited, and could be improved by applying the lens of academic feminism to the subject. Importantly, this is less about solving gender equality issues, and more about looking at one academic subject with the tools of a different academic subject. An essay could equally be written by a English literature academic asking how the tools of English literature studies could be applied to PL design.
As to some specific examples, the author brings up how PL design is incredibly monolingual. The vast majority of code is written in a programming language with keywords and syntax designed around English words and patterns of speech. Academic feminism would prompt us to question that: why do children learning to program in Germany or France, say, need to use these English keywords? Would it be easier for them if programming languages could be more localised? How would this affect the world: whose lives would be made easier, and whose lives would be made more difficult?
Another good example is precisely what we've been talking about just now. There is definitely a distinction between "real" programming languages and DSLs that are more limited. But that distinction is often associated with differences in prestige amongst different programming languages. Why? Why do you distinguish HTML — a DSL that forms a vital part of the infrastructure of modern web apps, but lacks the full power of, say, Javascript — from, say, SQL — a DSL that forms a vital part of the infrastructure of modern web apps, but lacks the full power of, say, Javascript? How does prestige impact how we choose different languages, and how languages are perceived amongst academic (and non-academic) PL designers and users?
For what it's worth, I think that a lot of these questions are asked in modern PL discourse, and I don't think the addition of an academic feminist lens necessarily contributes as much as the author is suggesting. We have experimented with multilingual programming languages (see, e.g. Excel), and while it seems to make things easier for beginners to use, it also becomes harder to manage at larger scales. And the discussion about making error messages easier to understand feels a bit dated given the direction a lot of modern languages are taking.
But I think the act of exploring one academic discipline through the lens of another is still a useful exercise, even if this article isn't necessarily the best exemplar of that.
Because HTML can't do a lot of the things classically considered programming. You can't use HTML to instruct the computer to calculate 1+1, or to sort a list of numbers or to generally get from state A to state B. You can't implement algorithms, you can't compute a result from input data.1 That makes it different from a language like SQL.
A language like HTML describes a state, it doesn't describe how to do anything with that state. But programming is, at least from a computer science point of view, precisely that "do anything with the state" part. It's describing a path that gets you from one state to another.
So languages like HTML are often not seen as programming languages because they don't allow you to program. There are different names for languages like that and HTML would usually be described as a markup language. That doesn't mean that its not useful, just that it does a different thing.
1: Maybe you can do some of those things via some technicality like interactions with CSS, but it's definitely not what HTML is made for or what it would be practically be used for.
I find it disappointing that you've not responded to the comment - or even paragraph - as a whole, which provides the context for that quote, and instead are focusing on what counts as a "real" programming language.
The point of that paragraph was that neither SQL nor HTML are general purpose programming languages. I cannot build a CLI, or a web server, or a desktop application using HTML or SQL alone. They are both DSLs with limits to their capabilities.
Now you are correct that SQL can do calculations. But you are incorrect that only SQL manages state. HTML includes plenty of stateful aspects, from how forms and iframes behave, to how code can be executed on various event handlers embedded into the HTML code.
The other important property that many people like bringing up is Turing completeness, but in practice I think this is more of a distraction. Turing completeness has nothing to do with the qualities that we actually need in a general purpose programming language (i.e. whether or not we can command the full range of operating system resources). Instead, it's a very precise mathematical property that tells us something about the classes of computation that exist. But it doesn't really give us a sense of anything outside that. For example, the previous poster referenced TeX as a markup language, and distinguished it from executable programming languages, but TeX is actually Turing complete, and you can do some very complex things with it, including writing interpreters for other languages. But again, it's a very specific DSL for a very specific purpose, and it is absolutely not a general purpose programming language that you could use for more everyday tasks. The poster was not wrong to call it a markup language, I think they were just wrong about what that implies.
Which again leads to the question: if both HTML and SQL are tools designed for specific niches, with only limited ability to interact with the world outside their custom-designed engines, why is it so important that we distinguish one of them as a "programming language" and the other as, well, not that?
I would argue that the answer is primarily about status. "HTML is not a programming language" has become such a meme that as soon as the claim is made, people rush in to demonstrate that they're a real programmer because they know the difference. But as a real programmer, who works with HTML on a daily basis, I think this is missing the point. HTML is absolutely a language that I use to program with. It is not a general purpose programming language, but it is one of a number of DSLs that I use to precisely define UIs and how they should behave. SQL is also a language that I use to program with, and is equally not a general purpose programming language, but I still use it to define which data should get loaded from the database. In most of the ways that are relevant to my work, there is little meaningful difference between them other than that they were built for different purposes.
We can see that here in the comments. There is a whole article to discuss, and in my last comment I even tried to unpack the key ideas a bit more and open them up to more discussion. And yet the thing that most people are focusing on is whether or not HTML is a programming language (which, FWIW, wasn't even the terminology used in the original article). Why? Why is it so important to get this right, when it's not even the point of the article?
Like I said at the start of this comment, I'm disappointed that you have focused on this one aspect as well, especially when I made it clear in my comment what the point of the article was. If you want to discuss the article, I'm happy to do that, because there's some interesting ideas in there - even if I don't agree with all of it. But if you just want to discuss whether it not HTML is a programming language, I encourage you to instead reflect on why that claim is so important to you and others in this thread that it's overshadowing actual discussion of the article's points.
I think any paper that features a basic factual error about the topic it discusses would be met with similar scepticism, no?
If I was to write a paper on English and mentioned that its direct roots are believed to be in Vedic Sanscrit, linguists and many other people would point this out to be not correct.
Similarly many programmers care about the distinction between markup languages and programming languages. For me it's basically a reflex to correct the idea that HTML is executable. It is a very basic thing to get wrong, and understanding the difference can help to gain insight into the basics of programming.
Ultimately I think it connects us when we can agree on a shared factual truth. That is why it's important.
And secondly, when I encounter a basic error in a paper like this, it will lower my motivation to engage with it at all. If it's that badly researched, I don't expect to gain anything of value from it. That holds true for any media, but especially for programming related articles.
I interpreted your paragraph about HTML and SQL as implying that the both languages are not seen as equal. On the surface this is obvious, since both act in completely different domains doing different things. They are very different. This didn't seem to be your point. Instead, the point seemed to be that people think lower of it, evidenced by them not calling it a programming language. A lack of prestige causes people to not accept the language as a programming language.
The point of my comment was that there is an established meaning of "programming language" that is not based on prestige, but on the languages properties. A language to write program code in. Many people use the term with that meaning and that explains why they apply it to some languages and not others.
I don't think SQL has especially high prestige and I assume not many people actually like the language a lot or think it's a great success of language design. It's ok for what it is, but that's it. I doubt it would qualify for a honorary "programming language" label, I think it gets that label through its properties. I also assume if you leave out all the "advanced" functionality for stored procedures and restrict it to just classical "SELECT/INSERT/UPDATE" clauses you can easily start a big discussion if that would really still be a proper programming language. Not because that would lessen its prestige, but because it would reduce its functionality.
To a certain extend, being a programming language (and especially a general purpose language) comes with higher prestige. But the reason for the higher status is not that somebody called it a programming language. The reason is that a general purpose programming language is very powerful and you can do a lot of interesting things with it. The narrower the language the less you can do with it and the less amazing people think the language is.
Of course this is just a rule of thumb. Writing shell scripts would generally be considered a form of programming, and shell scripting languages are programming languages, even though I feel like that has very low prestige associated to it.
So I don't see it as higher status leading to more acceptance as as programming language, rather the other way around: Higher general capabilities in the language lead to higher status. HTML only has mediocre status because there are a lot of parts where it has outgrown it's initial design and where it doesn't seem quite the best fit for many of the use cases it is used today. It works and works well in places, but also has its wired parts. So much like most other languages, not stellar, not horrible. I don't think it really has lower status than SQL, but of course that's completely subjective.
Does higher prestige in a language cause people to more likely want to learn it. Of course. In this example though it will hardly be relevant to the decision to HTML or SQL. The deciding point will be what you want to do with it, since they do completely different things.
Is it necessary to have the term "programming language" limited to just languages for writing program code? It's not necessary per se, but lots of people use it with that meaning and applying the term with a differing definition leads to confusion and, evidently, lots of unnecessary discussion.
There are thousands of computer languages and trying to have a few categories for them according to their properties makes life easier. Those language labels transport information about what that language is used for. HTML has a different use case than Javascript or SQL, so it makes sense to have a word for that. SQL also does something special, so there are labels like "query language" or "database language" to describe that. As you mention, its a "domain specific language" as opposed to a "general purpose programming language", another two categorizations that give the reader information about the capabilities and targets of a specific language. All those labels are given to languages based on their capabilities and use cases, and I claim that it's the same for the term "programming language".
Of course there are gray areas at the boundaries of these definitions, but that's always the case. With a more general definition of programming language, the problems just move. Is Markdown a programming language? It can be used to instruct the computer to render fancy formatted text. It can even be used to generate HTML. Is writing a plain text file programming? It can be used to instruct the computer to render non-fancy unformatted text. While I'm getting silly here the point is simply: there will always be corner cases where one can argue how something should be classified. That HTML is kind of on the border of some of the existing definitions is not a disparagement of HTML, it's just the nature of classifying things into different categories.
You are completely right that going into Turing completeness doesn't really help to capture what is commonly seen or used as a programming language and is therefore often not useful expect on a very technical/theoretical level. People tend to fall back on that because has not gray area. Its the one clearly defined and objective concept in that area. Something is either Turing complete or not. So that sounds nice, but is practically not as useful as one might hope. It's also a very theoretical concept, in practice nothing is Turing complete because all our programs operate on limited memory.
So why is it so important if HTML is a programming language? It isn't generally, but it seems central to your argument about it's low prestige. You argue how HTML is used in programming all the time and how not calling it a programming language therefore shows the low respect it gets. So that invites discussion if low respect really is the main reasons for not calling it a programming language and what otherwise makes a programming language.
Of course this is all tangential to the article and even the start of the comment thread, but I feel that is in the nature of long comment threads.
One analogy that one might use to illustrate the difference between a markup language and programming language is the difference between the frame of a car and its power train. The frame is a critical component, but it's in an entirely different category than the powertrain is — it provides structure for the rest of the car to bolt to, whereas the powertrain is responsible for making the car move. A car with the powertrain substituted out for another strangely shaped frame would not be functional.
It's true that the software development community has a bad habit of drawing this distinction for the purpose of denigration (which is unnacceptable and shouldn't be tolerated), but that doesn't mean that the distinction is without legitimate purpose.
The multilingual language mentioned, inexplicably referred to as Arabic-based immediately after it was introduced*, was kind of an attempted gesture in that direction, but I agree that I would have liked to see more of that and less of all the other things going on in this paper.
* I had a whole second paragraph here about how replacing one language not everyone speaks with a different language not everyone speaks is a non-solution. Upon rereading, I realized the mentions of Arabic in section 1.1 had led me to conflate Hedy with the Arabic-based Lisp mentioned in 6.2. I still think that one is a bad idea.
I would say the paper has overloaded the word “feminism” to the point of no longer being useful. We already have a perfectly good word for what the paper is actually talking about: inclusivity.
Which is not to say the paper doesn’t have good points, but it’s really struggling to coerce the terminology.
It is difficult to know what someone mean by "feminism" because feminism is incredibly broad. It's a similar situation to the word "socialism". When employing these terms it is useful to present a brief explanation on how they should be interpreted in the context of the article. I don't believe this article does that. Without it each reader will just default to their own personal bias.
In any case, this post gives me the impression of something that is meant for a very specific context which is not available to me. I don't think this was meant for the general public. Maybe it's not a bad article it's just not really an article.
Charitably, I might just assume that is a piece of a conversation I didn't follow from the beginning.
Most articles are pieces of a conversation we didn't follow from the beginning. Some try to bring everyone up to speed, but others don't, and they really don't need to.
My take: It's a programming language theory article intending to point out that there is another useful theoretical lens to apply. I expect that anyone without an interest in both sociocritical methods and formal system design would not grok this one off the bat, and that someone with an interest in either sociocritical methods or programming language design may be tempted by the article to go read more on the other.
I'm seeing a lot of comments that seem to think the two topics can't be worthwhile to combine, and that just sounds like preference or prejudice to me. Not speaking of you, just in general. I'm more baffled by the arguments I'm seeing set out in the comments than those in the article, personally.
But do you have an example for how feminism (or the lack of it) does influence language design? I have absolutely no idea what this even means.
In the past years I followed the design of the Zig language, and it all revolves around logic, readability, language concepts, etc., but never around men/women/non-binary people/gender, patriarchy and feminism, or other societal topics. And why should it? It's a programming language. Everybody can use it to express ideas in code.
I'm probably super ignorant, but usually I have a vague idea what I don't understand.
For me it would be much easier to reason about this with concrete examples of what this is actually about.
e: english hard
I certainly don't have any examples or firm opinions on the matter, as I'm in neither area. But my thoughts go to:
We should actively consider cons along with the obvious pros of writing anglocentric PLs
The governing bodies, development structure, etc are absolutely worth examining for unthought-of power issues
And the ones that stick out from the article are user-centric error messaging, accessibility considerations, etc. These are all things that have improved general web design, informatics, and other technical practices, but somehow pointing out that the feminist lens and intellectual tradition helped drive those changes is treated as aversive or nonsensical.
The argument I keep seeing that inclusivity !== feminist is misplaced in that feminists actively developed theory and analytic approaches to identify unacknowledged decisions and practices affected by unacknowledged power structures.
None of this is to criticize folks for not readily understanding what she's suggesting. It's one thing to not get it, another to get it and disagree on the merits, and a whole other more intellectually lazy thing to disagree because of not getting it and then getting into weird meta discussions of the merit of the exercise. Normal people socializing problems. That's all.
I would be wary of reading too much into it, this post is extremely specific and not very concerned in educating a random reader. It is probably a good idea to be just as charitable to the reactions as I tried to be charitable with the post.
Oh sure. I wouldn't single someone out to rake them over the coals. I'm just surprised at the forms of argument taking shape about this one and wanted to reframe it a little.
For people getting hung up on what "feminism" should and shouldn't denote:
There are analytic and theoretical approaches that examine power structures through a critical lens. Those approaches are considered feminist approaches because that is where they historically developed, specifically for the purpose of the advancement of women (NOT the diminution of men).
Saying "oh that's fine for the humanities/philosophy, etc, but not for application to formal systems" as though a feminist critique of computational practices were a category error...is mistaken. All human endeavors take place in a social context that involves power structures, which could affect those endeavors in important ways.
Feminist legal theory, for example, was driven by concern for women and has been pivotal in bringing into question invisible power concerns, such as the ways power has affected how the law was formed over time, how it is administered, how it is enforced, unacknowledged social side effects, etc. The author is doing that with programming language design.
Please try to get over your semantic hangups. We are all newcomers to endless topics and should keep some humility there rather than assume that reasons for nomenclature should be immediately, obviously justified to outsiders. There's no reason for her to give a full history of the development of feminism and it's applications. Instead she did the appropriate thing, which is to identify and briefly define the lens she's using. You can criticize the lens and the definition, but please read up on it first.
I'm still reading the paper itself but I found this preface and the discussion around it on lobsters to be fascinating. My initial impression of the title was this piece would be about a gender imbalance in some PL maintainer councils, however defining feminism as an examination and force of change in systems of power made me reflect on why gender imbalances exist and how feminism isn't just about gender.
For tildes readers who felt skeptical or guarded when you read the title: Can you reflect on why you had that reaction? Does feminism have a negative connotation in your mind? Why is that? Some of the commenters on lobsters exhibited this reaction, and I'd love to hear a reflection on it in real time. When I was younger I think I would have had a negative first impression of the title, I'm not sure when that changed for me, but I'm glad I no longer think or feel that way.
I wouldn’t say feminism has a negative connotation for me. I would say that I’m highly skeptical that programming language design is male biased, based on my pretty extensive experience with a wide range of programming languages. This is akin to saying that, for example, mathematics or physics notation has a male bias.
So that’s my initial reaction and why I was skeptical going into it. I think from the lens of feminism as a meaningful word in a shared vocabulary, my skepticism is justified — they do not make a case that there is any male bias in programming language design.
After reading the paper, I could see that the author has conflated feminism with the larger concept of inclusivity. From this new, and in my mind unreasonable, definition, I can sort of see where they are going with it.
I do agree with the author that programming language design does, in some cases, have some linguistic inclusivity issues. I still reject the idea that Anglocentrism also falls under the purview of feminism though.
Interestingly enough, I think this sentiment matches what the author is talking about in PL design. It seems like people are more focused on what is or isn’t feminism, like the author being told what is or isn’t a programming language. I think there’s more room for thinking critically about why people are focused on attacking the semantics of the paper when they admittedly agree with the overall sentiment.
It goes hand in hand with the “masculine” quantitative analysis when studying PL design, where the community is more focused on rigid and formal structure than a “feminine” qualitative evaluation.
Admittedly I still haven’t finished the paper itself but what I’ve read so far isn’t reasonably thrown out because it uses the lens of feminism. I don’t think that feminism in this paper means inclusivity, but thinking critically about what assumptions or biases led to inclusivity not being appreciated or considered in PL design. I think example of presenting an Arabic programming language being met with questions about its difficulty or if it’s useful, then asking why does the community think this way, falls within the bounds of feminism.
There’s a sentiment in the paper I understand but I don’t think I’m smart enough to properly express or articulate. I think most people are missing the point and I wish I knew how to explain it.
As an aside, I think it's actively harmful to talk about quantitative and qualitative reasoning as being masculine and feminine. My daughter's computer science teacher is constantly going off on this and it's not just very irritating to her, but I think that sort of thing is part of why the class has only two girls in it.
Alright, I don't think that's really feminism either. What this paper reads like is, someone has a really strong interest in feminism, and has come to the not unsurprising realization that there are parallels in feminist thought that resonate with inequality and disparity in other areas of life.
However, one could do this from any other critique of society and do the same thing and it would read identically, but be identically wrong. This could equally have been written as "decolonization in programming language design" or "class consciousness in programming language design" or any other similar angle, and they'd be equally shallow.
What you are describing here is the act of analyzing something through a feminist lens, which is what the author states they are doing throughout the paper. Feminism isn't just a socio-political movement, it is also a philosophical framework.
I don't think they are wrong. You can think that a feminist lens isn't a useful perspective for this subject, but from my reading of the paper they are correctly applying a feminist lens to PL design. What do you see in the paper that is an inaccurate assessment when thinking from a feminist framework?
Honestly, analyzing PL design from a lens of decolonization or class consciousness would be a great thing to do! We should be analyzing everything from multiple frameworks/lenses. Some of those analyses might be summed up as "this basically aligns with the status quo" or "this framework wasn't particularly applicable or useful for analysis", and those would be good, worthwhile things to do. I don't know if this applies to you, but this is something I encounter A LOT when talking to people who have more traditional-STEM backgrounds: there is not one "correct" lens to analyze something from; there are infinitely many. It seems like the STEM people I talk to view a paper like this as something that is either "correct" or "incorrect" based on if they personally agree with the conclusions the author makes, and that just isn't how the humanities would approach a paper like this. The questions of "Is this a correct application of a feminist lens to PL design" and "How much value do I think this lens has with respect to PL design" are independent questions, neither of which is guaranteed to have a binary result.
To jump on this aside, think that talking about this like it's a fact (and especially like it's a biologically-determined fact) is indeed harmful. But I also think that, because this stereotype is so pervasive in our society, there is still merit in discussion of not unduly privileging the quantitative or denigrating the qualitative, because I think that can still interact with sexism in ways that can harm people, especially if you aren't aware of the possibility.
I’d bet the discussion on Lobsters would’ve had a chance at being productive if the title matched the contents. At very least, it would’ve been an on-topic unproductive conversation.
There are interesting feminist arguments about philosophy's obsession with a particular approach to logic and rigorousness that failed to give space for alternative ways of thinking that are equally valid, and which are sometimes considered inherently feminine. Similar observations have been made for how philosophy is markedly white and European, excluding African and Asian schools of thought.
I unfortunately don't have any references to show, I just remember reading about it but I don't remember from. That's something /r/askphilosophy might help with.
I've heard this arguement, and I do think it holds merit within the context of philosophy and many other areas.
However, computers are just overgrown calculators. You're not going to stray too far from mathematics and logic at the end of the day.
That said, the most interesting thing to me is that most of the 'human computers' that worked for NASA were women. They were also some of the first computer programmers. These were mathemeticians back when humans could do much of this math faster than computers.
A computer is a tool that humans interact with in order to accomplish a task. The baseline assumptions the creator of a tool makes are reflected in that design. The method and language for interacting with that tool influences how users approach completing that task. You move beyond mathematics and logic the second a human gets involved in the process.
It's baffling because we'll see fierce discussion of how important design features of various programming languages are when the thread is about static vs dynamic typing, but when it comes to a thread like this, all programming languages are just pure math and their design is irrelevant.
I don't have much dog in the hunt on this paper, because I see it more as an exploratory call to action. The premise I certainly accept, that design choices can channel thought. Pulling out one of the oldies:
I think where I am a little unsatisfied is what I see as a lack of preliminary analysis on something more concrete. But I do appreciate a call for more research for what it is.
That said I did get a chuckle at the line about the "mathematicification" of programming, simply because computer science departments and in some cases IT departments started as clusters in math departments.
But it seems obvious to me that design choices could have all sorts of effects, which is why cobol is evil. It's the quantification and the analysis I really want to see.
I'll start by saying that I am way out of my depth on this, being a self-taught programmer without much in the way of college-level schooling in humanities, but I think lack of concrete-ness is one of the easiest ways to make something grating on STEM-oriented individuals.
As much as that crowd could probably stand to adopt some flexibility, if the audience is intended to be STEM-oriented (not saying that this paper is or isn't), it's probably a good idea to keep this in mind.
That being said, COBOL is a fine language for its problem domain, no less than SQL is.
Also was designed by a woman, fwiw.
I think the timing here explains things. Cobol first was developed in 1959 and that quote is from 1975. Cobol has been continuously updated since it was released, but by 1975 different patterns had emerged that shows the limitations of cobol.
I used to be an IBM systems programmer and I regularly coded in COBOL, C, natural, assembly, and of course JCL to being things together. Cobol definitely felt limiting even compared to those other old languages, except assembler.
(Old man voice) "Back in my day we wrote server side code in assembler to dynamically generate HTML that we passed to CICS region calls with a natural interface to C subsystems. And we liked it that way."
I think I would change the tense of the verb there, tbh. No one in that domain would choose COBOL nowadays without existing technical debt involved.
Yeah, I generally agree, I think this paper could've stood to do deeper analysis of fewer subjects.
My main intent was to disprove the whole 'masculinity of rationality/logic'.
And broadly, that's why I needed a concrete example of how this actually plays out. Because the first step to running the program is to strip away all of the human elements to something the computer can run. It makes it hard for me to fathom the concept of a langauge that would be able to remove itself so entirely from this core.
Sorry, I want to make sure I answer the right question: are you asking how human assumptions and biases impact programming language design and by extension how problems are approached and solved?
I'll preface this by saying I'm sick, so odds are my usual foot-in-mouth is probably worse than usual. But I want to give it a go so you don't wait around forver.
The computer itself is a purely rational, algorithmic device. I do not think there exists legitimate arguement that it isn't.
To interact with it at the lower levels, you must speak its languange, as it cannot learn yours. As such, any langauge that builds upon that is still bounded by needing to be translated. The constructs available will reflect what the machine is capable of, as you are instructing a machine what to do.
The paths that stem from that will be diverse, some leaning harder into the math and others abstracting farther.
But that's just it, they're all just divergent paths that all lead to the same end point.
No programming language is directly communicating "in the computer's language" though, so even under the premise that the binary machine code itself is pure rationality, that doesn't mean the human-designed systems for interfacing with them are inherently purely rational and algorithmic, nor that they are without flaws and biases. Even people who code in Assembly aren't writing pure binary, and even the programming languages we consider low-level these days are still full of human-designed syntax and abstraction. That's arguably the point of programming languages, after all -- they're for making it easier for us humans to write something human readable that can still get translated into binary eventually.
I too wish the author had included more concrete examples and delved into this with more depth. That said, I think it should be easy to see, at least from studying the most extreme examples, that programming languages can absolutely be designed in ways that hinder human users' ability to write code even if the ultimate result is identically rational to the computer running the binary. Look at Brainfuck or INTERCAL. It's also not hard to find examples where the design of a language can impede certain people from being able to use it as effectively as others -- Piet would be extremely frustrating for a colorblind person to use, for instance. These examples are deliberately extreme, but their extremeness should at least make the fact that this is something that is at least theoretically possible more obvious.
I was reading "On Lisp" by Paul Graham (free download of the book can be found here) and something he said made me think of your comment. Sorry for the wall of text but I wanted to include as much context for the quote as possible. The quote starts at the bottom of page
viof the preface and runs onto most of pagevii. Emphasis is mine:Yeah, whitespace in Python is both the devil and simultaneously completely irrelevant. Schrodingers indentation.
Yeah, women then weren't accepted into schools to be engineers, but could get into math degrees. Black women too, in a world that offered many fewer opportunities for their academic success. And they were all pushed out of computer programming by men once it became perceived as more prestigious. And then this was all worse once personal computers were seen as "for boys"
/Historical aside
It made me feel very skeptical because programming a computer really doesn't have any obvious, direct connection to ones sex or gender. "Feminism in Programming Language Design" reads like the premise would be that current programming languages are male-focused and not really suited for women, that women are somehow disadvantaged by the current programming languages.
Knowing that computer programming is all about abstract thinking, this seems really far fetched, unless the author somehow, at least implicitly, starts from the premise that women are less capable of abstract thinking than men. I don't see any reason to believe such a difference exists, and therefore a paper discussing the consequences of that seems sexist and like a waste of time.
I think the paper's biggest problem is that its way to broad and shallow. It mentions a lot of things, like pretty much all programming languages being in English and the "hard is good" mentality, that I think are solid points, but just kinda mentions them and breezes on to other topics. Also, the preamble about feminism takes up a big chunk of the paper; I'd have preferred that they just assume a basic level of knowledge and/or provide references for those who need it.
I do want to nit-pick the origin of the quote 'No one is free until everyone is free'. The authors quote a speech by Fannie Lou Hamer in the 1970s, but I'm pretty much certain it's a paraphrasing of a much older quote by the anarchist Mikhail Bakunin in the 1870s. Honestly, a lot of modern, 4th-wave feminism feels like watered-down and appropriated anarchism to me.
I'd argue that from how many people in the lobsters and this comment thread seem to be unwilling or unable to understand the difference between "feminism" and a "feminist lens", that the preamble was very necessary. Honestly, it has reaffirmed my belief that every STEM major should be required to take two humanities courses, if not more. The stuff people are getting stuck on are concepts tackled in an advanced 100-level or 200-level English course at University.
I'm doubtful such a requirement would move the needle at all. No one questions that there will be some students who discover unexpected passions because of the humanities requirement. However, in much the same way that 100 & 200 level STEM breadth courses are considered "asshole profs gatekeeping my path out of poverty" by pre-meds and engineers, humanities courses are often "filler that you do because it's supposed to be done" by the STEM kids. They optimize for whatever grade they need and let the knowledge flow right out the other side once the course concludes.
I don't disagree with you that a lot of STEM kids wouldn't take the courses seriously. I double majored in math and cs at a liberal arts school; I saw and heard how my peers talked about the required non-STEM courses. However, I also took a Native American Religion and Culture class freshman year to satisfy some of my graduation requirements and decided to minor in Religious Studies. I had 0 interest in religious studies prior to walking into that class. The requirement to take that course drastically changed my life. If I am purely trying to appeal to STEM kids and focusing on the things they value: the skills I learned from my humanities classes have helped me stand out in job interviews, I am better at communicating my ideas and explaining things, especially to non-technical people like managers which has let me advance in my career at a faster rate than the other people I know in similar fields. Personally, I think it is worth it to make them required. A bunch of people wont learn anything, but plenty of people will and that is enough for me. Especially given the current consequences of the bulk of the tech field having a lack of understanding and/or respect for the humanities.
I agree, for the reason you gave earlier. Especially at the undergrad level, they can be exposed to meaningful contact with subjects in a way that high school level requirements will not. Uni should be to provide opportunities to discover new interests, not merely focus on refining your existing talents.
However, I doubt such requirements will move the needle as far as this is concerned. Even for the students who fondly remember discovering a new passion from a humanities requirement, they may not have connected with the larger goal of the humanities distribution requirement. Think of the student who realized "feudal Japan is hella interesting" in an East Asian History 213 course without internalizing the generalizable historical research methods.
Those certainly are true. However, I don't think this specific phrasing would be convincing to a college freshman who is resistant to putting in effort outside his niche interests. What specific things did you learn about interviewing that you don't think you would've picked up elsewhere?
Specifically about interviews, since we're discussing STEMlord boys (this attitude has a notable gender divide), I've found them to be divided between the arrogant and the nihilistic. The arrogant ones think they know it all—perhaps because they've "aced" practice interviews that have no relation to the real grind. If only to game the system, the nihilistic ones will pay closer attention. They disrespect the entire job-hunting process, often (correctly) diagnosing it as a means to screen out autists, but aren't above trying to trick interviewers into hiring them anyway.
It doesn't help that many supporters of distribution requirements do a piss-poor job of explaining the benefits of humanities courses when arguing online. Instead of listing concrete examples like the ones you gave, they give vague hogwash, such as "It helps you become a better person." How exactly would an English class help clarity in writing in a way that a technical writing course would not? This may be my personal bad experience with freshman comp classes, but I learned much more about structured extended argumentation from my history essays than writing fluff about literature. Perhaps the freshman comp stuff would've been better if I had instead had my history class essays cross-graded by comp prof. The history prof grades as they always have, then the comp prof grades for form & structure. Polish something I cared about instead of "I'll just take the B"—even when I got As in that class, I didn't know what I did differently from when I earned Cs, only that the results were different (often correctly labeled as such).
Looking back, I wish I could've filled the analytical writing requirements with my history & sociology classes, then took creative writing to fill the literature & composition distribution. I got into writing short stories (ok, fanfiction) after graduation and sometimes I wish I could've gotten better feedback during my "learning" years.
I couldn't agree more. Thank you for saying that. Technical professions NEED non-technical commentary in addition to the abundant technical commentary in order to improve as fields.
I definitely agree, but I was under the impression that every Bachelor's required at least a few. Maybe that's a US only thing? Or perhaps just a California thing?
The requirements for a bachelor's degree in a given subject is university-dependent, at least in the US. Gen Ed requirements can vary wildly between institutions as a result, and theoretically there's no need for them to exist at all (iirc Brown made a big deal of not having them when I went to an info session as a high schooler). Most US schools have some such requirements, but their nature and degree can differ even between different programs at the same university.
I don't disagree, but I was more talking about what would have made the paper better for me. I am by no means an expert on all the main branches of feminist theory, but I know enough to not need the intro. I'd just have preferred they went into more depth with that time and space.
I can definitely see the argument for 4th-wave feminism being watered-down anarchism (I'd need to do more reading on both to have a strong opinion there), but I'm not really clear how 4th-wave feminism could possibly be "appropriating" anarchism by incorporating a lot of its ideas and principles. Isn't that a pretty big goal for philosophies like anarchism? It's not like anarchism is some sort of closed practice, after all.
Yes, but only if the ideas actually retain the core values and aren't white-washed to oblivion. Anarchism has few core concepts, but they are all necessary, they are interwoven into the whole. One is anti-capitalism; of course some feminists and some feminisms are anti-capitalist, but I don't believe feminism is as a whole can be described that way. The other core tenet is an absolute rejection of hierarchies, not a thinking there in bad taste, but fundamentally wrong. Again not a necessary tenet of feminism.
I used the a word appropriating because that's the feeling I get from this paper and similar works. Now, I will note that is feeling that I've had for a while, so I do believe that colored my interpretation of the paper. And I admit its mostly a feeling, but I also can't think of a better word or way to describe it. I really tried here, but nothing else worked. It simply feels like appropriation to me.
I think incorporating anarchist ideas is a big thing that sets fourth-wave feminism apart from the previous waves, so it seems odd to reject them for lacking tenets of anarchism because they're not "core tenets of feminism" while simultaneously criticizing them for trying to incorporate them. It is extremely common for philosophical approaches to borrow ideas from one another -- this is arguably one of the points of reading papers from a given philosophical approach. I'm sure there are varying degrees to how well different individual fourth-wave feminists incorporate anarchist ideas, but I'd challenge you to really ponder why you feel the way you do about them doing so, and whether or not there's an implicit hierarchy involved that you're not fully conscious of.
Okay, I will. I'd appreciate you doing the same. I dislike the biggest-tent feminism that the paper pretty explicitly argues for, because I don't believe I am actual welcome as a fully equal member. Maybe that's because I have unexamined biases around feminism, but it might also be that I am not welcome. I'll try to spend sometime considering it.
There are strains of feminism that I too am not included in. I am trans masc and most of my friends are trans fem, so trust me I have seen plenty of bad feminist takes. The gender studies course I took in undergrad unfortunately didn't touch on fourth-wave feminism, and I don't know what specifically makes you feel like you cannot be included in any feminism, so I can't give any specific recommendations. I've really only got some passing familiarity with academic feminism, so I'm not the best person to advocate for it, even if many people on Tildes are even less experienced with it. What I will say is that I think it's very likely that a school of feminists that incorporates ideas from anarchism and is deliberately seeking to address societal inequality outside of gender is almost certainly going to be more inclusive of you than a more "traditional" school of feminism like second-wave that explicitly views everything through the lens of sexism and gender-based oppression.
I feel like we are talking across each other a bit. I am not saying I can't identify with any particular feminism or feminist, but that I don't feel included in an abstract and unspecific Feminism™ or in many feminist dialogues. I agree that 4th-wave feminism is MORE inclusive then earlier iterations, but not that its inclusive enough for me to feel actually safe and welcome.
It still minimizes the harm and extent of both female perpetrators and male victims, which is a lot of my personal experience. I think my main point is that 4th-wave feminism uses a lot of anarchist language, while not adopting the underlying principles, or at least that is my concern. I will try to critical engage with this opinion and not take it as fact.
I think this is more or less what I took from your comment, and I honestly can agree there -- our reasons are probably not the same, but particularly when it comes to mainstream pop feminism there's often a lot of poorly-founded junk. I just think it's worth looking into differences in these respects among different feminist authors and movements just as you would with other philosophies -- there are a lot of different points of view and approaches that fall under the big umbrella here. I've heard bell hooks, for instance, addresses the harms men are subjected to and their negative experiences with far more empathy and nuance than your stereotypical pop feminist.
Ultimately I think the abstract and unspecific Feminism™ you're struggling with is similar to the abstract and unspecific anarchism I struggle with due to principally being exposed to anarchists making very bad arguments against eloquent marxist-leninists on Tumblr. The emotional reaction to the shittier, more watered-down version of the movement is justified, but it doesn't necessarily reflect actual Theory or even some consensus within that school of philosophy.
I don't blame you for being put off by pop feminism's approach to men and the "men are perpetrators and women are victims" framework that is common in pop feminism, as much of the same stuff also puts me off -- especially as a trans masc person. But it's worthwhile to engage with individual feminists' work without assuming that it will necessarily reflect that weird pop feminist amalgamation of vibes, because different authors and approaches really can be very different (though I can't speak to whether any of them really incorporate anarchist principles as thoroughly as you want; that's probably something you'd have to decide for yourself on reading a given feminist's work).
I think you've acknowledged most of this yourself, fwiw, so I'm not so much criticising you here as I am just rambling on the topic.
This is not how the non-fascists will win the culture wars.