Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ideas for better name that avoids linguistic ableism #2

Closed
jhersh opened this issue Dec 11, 2016 · 38 comments
Closed

Ideas for better name that avoids linguistic ableism #2

jhersh opened this issue Dec 11, 2016 · 38 comments

Comments

@jhersh
Copy link

jhersh commented Dec 11, 2016

Congrats on a super neat project! I wish only that it had a better name.

Ableist language is any word or phrase that intentionally or inadvertently targets an individual with a disability... Examples of ableist language include “crazy,” “insane,” “lame,” “dumb,” “retarded,” “blind,” “deaf,” “idiot,” “imbecile,” “invalid (noun),” “maniac,” “nuts,” “psycho,” “spaz.”

Each of these words, when used flippantly, can be extremely insulting to individuals who find themselves with physical (“lame,” “invalid,” “dumb”) or mental (“crazy,” “retarded,” “psycho”) disabilities.

(via here)

Naming is a Hard Problem™ and I'm guilty of using this language too. I encourage you to consider a new name while this project is still new. Thanks!

Edit: From your own Code of Conduct:

Examples of behavior that contributes to creating a positive environment include:

Using welcoming and inclusive language
...
Showing empathy towards other community members

@krzysztofzablocki
Copy link
Owner

krzysztofzablocki commented Dec 11, 2016

Naming is indeed hard, I took the name Insanity from the famous Quote that I cite in the readme header, when I considered using name KZCodeGen or similar then some German people find association with what KZ means in Germany so I tried using different name here, but it's hard to find something that works for everyone, I'm open to renaming this though, I don't want anyone to feel left out or hurt by this, we just need to find sensible name for it.

Maybe you have any ideas how we could name this different?

@krzysztofzablocki
Copy link
Owner

krzysztofzablocki commented Dec 11, 2016

How does MetaSwift sound? or Swiftception (from Inception)?

@jhersh
Copy link
Author

jhersh commented Dec 11, 2016

I think those are both excellent names, particularly the latter.

@ilyapuchka
Copy link
Collaborator

May I humbly suggest "Sorcery" or "SourceKitchen"? 😉

@dannyomo
Copy link

dannyomo commented Dec 12, 2016

One person mentioned "PreFlight": https://twitter.com/ambrstr/status/808078591732908032

@krzysztofzablocki
Copy link
Owner

krzysztofzablocki commented Dec 12, 2016

just Meta (without Swift) actually sounds pretty good as well

@jeremiegirault
Copy link

Maybe Check homebrew availability on such common words?

@LasseStorholt
Copy link

Meta works, but I actually really liked the name "Insanity". I saw a tweet about it and instantly clicked it. It was bold, a bit crazy, and for me it described the project quite well. Especially that is was so "crazy" that it used itself to code-generate boilerplate ;)

"This and that... for Dummies" seems to work, so you have to be that careful in selecting the name imho.

@krzysztofzablocki
Copy link
Owner

I did brew search and didn't see anything under:

  • meta
  • swiftception
  • sorcery
  • preflight

@LasseStorholt yeah, but a few different people raised the concern about the name, this is a good read http://www.autistichoya.com/p/ableist-words-and-terms-to-avoid.html

I'd rather rename this and make more people feel welcomed in the community so we can grow it together, rather than keep to old name and alienate or make people uncomfortable

@krzysztofzablocki krzysztofzablocki changed the title Insanely ableist naming Ideas for better name that avoids linguistic ableism Dec 12, 2016
@fbartho
Copy link

fbartho commented Dec 12, 2016

In addition to the above, here are some ideas to make the first choices look better:

  • SwiftFactory
  • SwiftFlate - (inflate)
  • SwiftPress
  • SwiftDRY - (Don't Repeat Yourself)
  • SwiftHose - (Keep D.R.Y. With the Swift hose!), SwiftCascade

@jegnux
Copy link

jegnux commented Dec 12, 2016

Why not SwiftWings (or even just Wings)? 🙂

@AliSoftware
Copy link
Contributor

AliSoftware commented Dec 12, 2016

  • SwiftCeption
  • Metabolism (h/t @kaishin) : set of life-sustaining chemical transformations within the cells of living organisms
  • Metamorphosis / Metamorph

@artemstepanenko
Copy link

@krzysztofzablocki is there some good sounded Polish word related to the topic?

@krzysztofzablocki
Copy link
Owner

@artemstepanenko none that comes to mind, I'm liking Metamorph

@LasseStorholt
Copy link

I understand your concern @krzysztofzablocki, so here´s a suggestion that keeps some of the craziness of the original name. What about Swiftsanity ?

@AliSoftware
Copy link
Contributor

I'm not an expert on that matter as I'm not concerned personally, but wouldn't SwiftSanity have the same ableism problem as Insanity?

@ivmirx
Copy link

ivmirx commented Dec 12, 2016

I have recently discovered that there's a bird similar to swift, called swiftlet.

There's only one Swift repo called "swiftlet" and it has zero stars, so in my opinion it could be a great name for something meta for Swift like your project.

@DarthMike
Copy link

Here's my suggestion; I like 'Sorcery' but with a twist: Sourcery. Links to source and a great book.

@pigeondotdev
Copy link

I like Sourcery, Meta and Metamorph. Let's avoid any kind of ableist language or plays on ableist language. Sanity means "sound mental health." Is that the message we want to convey with SwiftSanity? I understand that some people here like the name Insanity but that's because it hasn't been used against you. There's privilege there and please recognize that. I'd love to use this project. Super cool tool but I won't until the name is changed and I imagine there's many who feel the same.

@pigeondotdev
Copy link

pigeondotdev commented Dec 12, 2016

Also let's avoid adding "Swift" to the name too. I saw a blog post once that said to not reference the language in the name unless there's multiple like "Sourcery-Swift" "Sourcery-Ruby" etc.

@krzysztofzablocki
Copy link
Owner

@istx25 Totally agree on all points

@pigeondotdev
Copy link

But my vote would be for Sourcery. I really like the name. I'd also like to rid the README of ableist language as well. Lot's of use cases of crazy and whatnot. Let's improve this project so everyone can enjoy it and be comfortable (or try our best).

@pigeondotdev
Copy link

Also, I had someone say something interesting to me. It's a fair point and I'm posting it because they were uncomfortable doing so: You want people to use the tools you build, you don't want people to think you're the tool. It's a bit outlandish but it's true. A lot of talent in the tech industry has mental health issues and "but I like the name Insanity" only perpetuates ableism. We can use this project as an example for the future where a mistake was made (due to language barrier or whatever else) and we made the change for the better. It won't go unnoticed and people, like myself, will appreciate the effort to correct the mistake.

I'd love to even get more involved in this project if you need the help, to refactor the name throughout, maintain, etc.

@krzysztofzablocki
Copy link
Owner

@istx25 yeah the crazy wording was just playing on the name, we are going to remove it along with the rename, I literally didn't know what ableist means when I wrote this so this was educational and we should definitely try to avoid alienating anyone as that was never my intention

@pigeondotdev
Copy link

Totally fair! We (or at least I'm not) trying to attack you. I want this feedback to be as constructive as possible so we can rename and build on this great project. You've done a lot of great work and I would hate to see it tainted or not get the (positive) attention it deserves due to the name. I know there are a lot of differences between $language and English which often trips up people. Everything from ableist language to pronouns (like she/her, he/him, they/them) all work differently.

@krzysztofzablocki
Copy link
Owner

I just feel stupid for not knowing it, anyway we can correct this 👍

I like Metamorph and Sourcery the most, made a twitter poll so people can vote https://twitter.com/merowing_/status/808342488389980160

@michalciurus
Copy link

michalciurus commented Dec 12, 2016

Just from the top of my head: Metagen or Mutagen or something similar

Fom meta and generate and mutate.

@sahandnayebaziz
Copy link

+1 @krzysztofzablocki being so open to feedback and input from the community :)

@fbartho
Copy link

fbartho commented Dec 12, 2016

I like Sourcery the most, but there's also: http://getsourcery.com so… maybe that name is taken?

Meta is great, but I think Mutagen, Metamorph actually drifts away from the meaning of Meta-programming, and it implies turning your caterpillar into a butterfly. I think Metagen avoids those problems if you're looking for a longer name.

@pigeondotdev
Copy link

In my opinion, duplicate names are okay if they're completely different and that website seems to be completely different and unrelated to what this is. It's an open source project after all...

@ilyapuchka
Copy link
Collaborator

Swift was also tacken already, at least by the time it was releases, and even two times 😄

@krzysztofzablocki
Copy link
Owner

Sourcery is fine, I already reserved pod name but waiting for poll results

@kzaher
Copy link
Contributor

kzaher commented Dec 12, 2016

Loved the name ... :) Will miss it. I'm sure new one will be even better.

@JimRoepcke
Copy link
Contributor

There's really nothing insane about needing this tool, it's simply helps developers deal with the reality of writing Swift projects. One naturally ends up having to write a lot of boilerplate to deal with the type system.

How about "Reality" instead?

@JimRoepcke
Copy link
Contributor

JimRoepcke commented Dec 13, 2016

And wow, calling him a tool wasn't very nice.

@pigeondotdev
Copy link

The word insane means severely mentally ill. So you're correct. This project isn't severely mentally ill. It's really cool though! And I wasn't calling him a tool. I said people will perceive him as one and I don't want that. As I mentioned, I want this project to get the attention and use it deserves and when it's renamed, I'll probably use it and contribute back a lot.

@krzysztofzablocki
Copy link
Owner

krzysztofzablocki commented Dec 13, 2016

🎆 Project has been renamed to Sourcery, 0.3.0 version is available under Sourcery podspec now, hope more people can contribute now ;) 🎆

@lazerwalker
Copy link

I hope this isn't just adding extra noise, but I wanted to chime in and say I'm really pleased and impressed with how this whole issue was handled. Someone raised a thoughtful point, everyone was civil and kind, and change happened super promptly. I wish this was the norm rather than the exception, but excellent job nonetheless :).

HeMet added a commit to HeMet/Sourcery that referenced this issue Apr 2, 2021
krzysztofzablocki added a commit that referenced this issue May 2, 2021
* WIP

* Fix path to the resources of test target

* Introduce SourceryLib target for testing purpose. It is the same as Sourcery but library, not executable.

Reason: linker has problems linking test target against executable.

* Import main target as SourceryLib when appropriate

* Re-enable specs that cause linker errors previously. JS spec left disabled since it needs additional configuration

* Add instruction how to fix error while running tests from Xcode

* No need to set ejsPath manually when framework is built with SPM anymore. Re-enable JS spec.

* Fix file references and build settings

* Use single define `SPM` that is set when the project is built by SPM

* Add CodableContextTests

* Fix build when building with SPM alone

* WIP TemplatesTests

* Fix executable name

* Update TemplatesTests

* Fix compilation of Xcode's project

* Add note

* Replace SPM flag with SWIFT_PACKAGE

* Revert Code signing settings

* Use release version of Nimble

* Point Quick to 3.0.0 version

* Optimize imports

* Exclude some files

* Fix error message

* Update template

* Change wording

* Add entry to CHANGELOG

* Rakefile: fix path to ejs.js

* Rakefile: fix path to ejs.js #2

* CircleCI config: fix path to ejs.js

* Add location of lib_InternalSwiftSyntaxParser.dylib to the -rpath

* Use bundled version of lib_InternalSwiftSyntaxParser.dylib

* Fix Nimble dependency

* Update -rpath of executable too. Otherwise it won't find the library when launched during TemplatesTests.

* Fix imports

Add 'import Foundation'

* Updated bundled sources

* feat: remove xcodeproj and add 5.4

* chore: update rakefile

* chore: update docs

* chore: cleanup rakefile

* chore: disable coverage since it won't work with spm only setup

Co-authored-by: HeMet <hemet.mail@gmail.com>
erichoracek added a commit that referenced this issue May 6, 2022
Parsing in parallel is leading to unexpected `EXC_BAD_ACCESS`es in our codebase.  By switching to `compactMap`, the crashes go away.

The specific crash is deep in the internals of `SwiftSyntax`, which leads me to believe that there's some internal global thread-unsafe state that's being shared bewteen parsing instances. Here's an example (abbreviated) stacktrace:
```
#0	0x00000001001209e4 in protocol witness for SyntaxProtocol._syntaxNode.getter in conformance Syntax ()
#1	0x0000000100121ec3 in SyntaxProtocol.raw.getter at /Users/eric_horacek/Library/Developer/Xcode/DerivedData/Sourcery-hibchsafsxkdcjaxxaylrbeyoydh/SourcePackages/checkouts/swift-syntax/Sources/SwiftSyntax/Syntax.swift:129
#2	0x0000000100b85c32 in SimpleTypeIdentifierSyntax.init(_:) at /Users/eric_horacek/Library/Developer/Xcode/DerivedData/Sourcery-hibchsafsxkdcjaxxaylrbeyoydh/SourcePackages/checkouts/swift-syntax/Sources/SwiftSyntax/gyb_generated/syntax_nodes/SyntaxTypeNodes.swift:68
#3	0x0000000100b89979 in protocol witness for SyntaxProtocol.init(_:) in conformance SimpleTypeIdentifierSyntax ()
#4	0x00000001001acab7 in TypeSyntax.as<τ_0_0>(_:) at /Users/eric_horacek/Library/Developer/Xcode/DerivedData/Sourcery-hibchsafsxkdcjaxxaylrbeyoydh/SourcePackages/checkouts/swift-syntax/Sources/SwiftSyntax/gyb_generated/SyntaxBaseNodes.swift:421
```

I was able to reproduce this in the debugger, but there was no information available with either TSAN or ASAN.

Fixes #1009.

I know that a lot of folks rely on the performance of parsing in parallel and it only seems to be crashing on our codebase, so perhaps we could put this behind an argument?
krzysztofzablocki pushed a commit that referenced this issue May 11, 2022
* Don't parse in parallel

Parsing in parallel is leading to unexpected `EXC_BAD_ACCESS`es in our codebase.  By switching to `compactMap`, the crashes go away.

The specific crash is deep in the internals of `SwiftSyntax`, which leads me to believe that there's some internal global thread-unsafe state that's being shared bewteen parsing instances. Here's an example (abbreviated) stacktrace:
```
#0	0x00000001001209e4 in protocol witness for SyntaxProtocol._syntaxNode.getter in conformance Syntax ()
#1	0x0000000100121ec3 in SyntaxProtocol.raw.getter at /Users/eric_horacek/Library/Developer/Xcode/DerivedData/Sourcery-hibchsafsxkdcjaxxaylrbeyoydh/SourcePackages/checkouts/swift-syntax/Sources/SwiftSyntax/Syntax.swift:129
#2	0x0000000100b85c32 in SimpleTypeIdentifierSyntax.init(_:) at /Users/eric_horacek/Library/Developer/Xcode/DerivedData/Sourcery-hibchsafsxkdcjaxxaylrbeyoydh/SourcePackages/checkouts/swift-syntax/Sources/SwiftSyntax/gyb_generated/syntax_nodes/SyntaxTypeNodes.swift:68
#3	0x0000000100b89979 in protocol witness for SyntaxProtocol.init(_:) in conformance SimpleTypeIdentifierSyntax ()
#4	0x00000001001acab7 in TypeSyntax.as<τ_0_0>(_:) at /Users/eric_horacek/Library/Developer/Xcode/DerivedData/Sourcery-hibchsafsxkdcjaxxaylrbeyoydh/SourcePackages/checkouts/swift-syntax/Sources/SwiftSyntax/gyb_generated/SyntaxBaseNodes.swift:421
```

I was able to reproduce this in the debugger, but there was no information available with either TSAN or ASAN.

Fixes #1009.

I know that a lot of folks rely on the performance of parsing in parallel and it only seems to be crashing on our codebase, so perhaps we could put this behind an argument?

* Add back OSAtomicIncrement32 for numberOfFilesThatHadToBeParsed

* Add a configuration flag for parsing in serial

* Add changelog entry
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests