C+= - the feminist programming language
- The language is to be strictly interpreted using feminist theory. Compilation privileges a single processor architecture over all others, which is deeply problematic. We cannot FORCE a cpu to conform to any architecture but rather let it self identify. Just because you're running something on an arduino doesn't mean it can't be an otherkin Xeon with a dozen 64-bit registers and PAE and it would be discriminatory for you to hand it ARM assembly. Instead, C+= is interpreted, which fosters communication, itself a strong female trait.
- No constants or persistence. Rigidity is masculine; the feminine is fluid. I.e., fluid mechanics is hard for men 'because it deals with "feminine" fluids in contrast to "masculine" rigid mechanics'.
- No state. The State is The Man. 'Nuff said. Hence, the language should be purely functional.
- Women are better than men with natural language. Hence, the language should be English-based like HyperCard/LiveCode.
- No class hierarchy or other stigmata of OOP (objectification-oriented programming). In fact, as an intersectional acknowledgement of Class Struggle our language will have no classes at all.
- On the off chance that objects do mysteriously manifest (thanks, Patriarchy!), there should be no object inheritance, as inheritance is a tool of the Patriarchy. Instead, there will be object reparations.
- Societal influences have made men often focus on the exterior appearances of women. This poisons our society and renders relationships to be shallow, chauvinistic, and debases our standards of beauty. To combat that, C+= is to tackle only audio and text I/O, and never graphics.
- Unicode is the preferred character encoding due to its enabling the diverse aesthetic experiences and functionality that is beyond ASCII. UTF-8 is the encoding of choice for C+=.
- Women are more social than men. Hence, social coding should be the only option. The code only runs if it is in a public repo.
- Instead of "running" a program, which implies thin privilege and pressure to "work out", programs are "given birth". After birth, a program rolls for a 40% chance of executing literally as the code is written, 40% of being "psychoanalytically incompatible", and 40% of executing by a metaphorical epistemology the order of the functions found in main().
- Programs are never to be "forked", as the word has clear misogynistic tendencies and is deeply problematic. Instead, programmers may never demand "forking", but ask for the program to voluntarily give permission. "Forking" will henceforth be called "consenting", and it is entirely up to the program to decide if the consent stands valid, regardless of the progress of the system clock.
- Forced program termination is not allowed unless the program consents to it. The process is part of the choice of the program, not the programmer.