-
-
Notifications
You must be signed in to change notification settings - Fork 624
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
Comments
Naming is indeed hard, I took the name Maybe you have any ideas how we could name this different? |
How does MetaSwift sound? or Swiftception (from Inception)? |
I think those are both excellent names, particularly the latter. |
May I humbly suggest "Sorcery" or "SourceKitchen"? 😉 |
One person mentioned "PreFlight": https://twitter.com/ambrstr/status/808078591732908032 |
just Meta (without Swift) actually sounds pretty good as well |
Maybe Check homebrew availability on such common words? |
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. |
I did brew search and didn't see anything under:
@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 |
In addition to the above, here are some ideas to make the first choices look better:
|
Why not SwiftWings (or even just Wings)? 🙂 |
|
@krzysztofzablocki is there some good sounded Polish word related to the topic? |
@artemstepanenko none that comes to mind, I'm liking |
I understand your concern @krzysztofzablocki, so here´s a suggestion that keeps some of the craziness of the original name. What about Swiftsanity ? |
I'm not an expert on that matter as I'm not concerned personally, but wouldn't |
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. |
Here's my suggestion; I like 'Sorcery' but with a twist: Sourcery. Links to |
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. |
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. |
@istx25 Totally agree on all points |
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). |
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. |
@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 |
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 |
I just feel stupid for not knowing it, anyway we can correct this 👍 I like |
Just from the top of my head: Metagen or Mutagen or something similar Fom meta and generate and mutate. |
+1 @krzysztofzablocki being so open to feedback and input from the community :) |
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. |
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... |
Swift was also tacken already, at least by the time it was releases, and even two times 😄 |
|
Loved the name ... :) Will miss it. I'm sure new one will be even better. |
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? |
And wow, calling him a tool wasn't very nice. |
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. |
🎆 Project has been renamed to Sourcery, 0.3.0 version is available under Sourcery podspec now, hope more people can contribute now ;) 🎆 |
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 :). |
* 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>
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?
* 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
Congrats on a super neat project! I wish only that it had a better name.
(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:
The text was updated successfully, but these errors were encountered: