4 ms·
Total nitpick, but: Why would you name an option "disable_ai" with a default value of false instead of calling it "enable_ai" with a default value of true? Ar
by senbrow 1y ago
Total nitpick, but:
Why would you name an option "disable_ai" with a default value of false instead of calling it "enable_ai" with a default value of true?
Are there some mechanical semantics I'm missing here that make this beneficial?
Negative booleans (ie that remove or suppress something when true) are generally a source of confusion and bugs and should be avoided like the plague in my experience.
- wanderingstan 1y agoI concur. Same thing in many UI frameworks where you’ll have a Boolean “isHidden” to control visibility. Makes it so hard to reason about.
- Rexxar 1y agoIMHO, in this case it should not even be a boolean but an enum {Visible, Hidden}.
- roguecoder 1y agoEven with working with an existing framework, we can define a constant `HIDDEN=true`
- vouaobrasil 1y agoTechnically, "enable_ai" doesn't imply that all AI features are really turned off. Without context, it might imply that some basic AI features exist and "enable_ai" just enables further features. "disable_ai" is unambiguous.
- whilenot-dev 1y agoEnable/disable are the only two dichotomies in the whole of all possible states regarding this AI feature, so I'll have to bite: What's your "Technically," referring to here?
- vouaobrasil 1y agoFirst of all, enable/disable is a dichotomy, and is not a set of two dichotomies. Second, imagine an editor that has AI running in the background, scanning your files. "Enable_AI" could just mean enable the visibility of the feature to actually use the results. On the other hand, it would sound more suspicious if there were some background AI tasks running, even for training purposes, if "disable_AI" were "True" as compared to "Enable_AI" to be false. In other words, Enable_AI COULD have the connotation (to some) of just enabling the visibility of the feature, whereas Disable_AI gives more of a sense of shutting it off. Imagine for example you're in a court of law. Which one sounds more damning? ======= Prosecutor: You still have AI tasks running in the background but AI_Enable is set to false? Defendent: But Enable_AI just means enabling the use of the output! ==== ==== Prosecutor: You still have AI tasks running in the background, but AI_Disable is TRUE? Defendent: Uh.... ====
- criddell 1y agoI don't buy your argument. > ==== Prosecutor: You still have AI tasks running in the background, but AI_Disable is TRUE? Defendent: But Disable_AI just means disabling the use of the output
- vouaobrasil 1y agoWell, I guess we'll see then. Or not.
- bheadmaster 1y ago> Enable_AI COULD have the connotation (to some) of just enabling the visibility of the feature, whereas Disable_AI gives more of a sense of shutting it off. Personally, I don't feel much difference between the two. I doubt that an average reasonable person would either.
- vouaobrasil 1y agoWell, I do feel a distinct connotational difference, but then again, I could be the only one I suppose. And if the average person doesn't care, then why argue about it at all? And how many average people will be using Zed anyway?
- anttiharju 1y agoMy pet peeve is CGO_ENABLED compiler option in Go. It's set to 0 or 1 to enable/disable (can never remember which mapa to which) If it was just CGO=true or CGO=false I think so much confusion could have been avoided. I think similar thinking applies here. It's convoluted to disable something by setting ai_disable=true because I read it like: setting false true instead of just setting boolean.
- scbrg 1y agoThis follows a convention that was well established and felt pretty ancient when I learned about environment variables in the nineties (i.e. 30 years ago). Variables that are flags enabling/disabling something use 1 to enable, and 0 to disable. I'd not be surprised if this has been pretty much standard behavior since the seventies. This is not unique to Go.
- whilenot-dev 1y agoI always thought that an unset boolean env var should define the default behavior for a production environment and any of these set with a value of length>0 will flip it (AUTH_DISABLED, MOCK_ENABLED, etc.). I thought env vars are always considered optional by convention.
- anttiharju 1y agoAt least in the case of cgo_enabled it does define the default behaviour
- anttiharju 1y agoI don't doubt any of that but why stick to such old conventions when there are explicit and immediately clear options? I don't think me writing an if condition if boolean != true instead of if boolean == false should pass code review. I don't think my pet peeve is necessarily different from that. I understand there's a historical convention but I don't think there's any real reason for having to stick to it. Hell, some of the other compiler options are flags with no 0 or 1, why could this not have been --static or any flag? I'm genuinely curious. Moreover, 0 here maps to false but in program exit codes it maps to success which in my mind maps to true but then we have this discrepancy so it does not appear to be the right mental model.
- elicash 1y agoThey are trying to communicate that disabling AI is a product feature to some customers. I think it's reasonable to, for example, have a field that is labeled "Do Not Track".
- kjksf 1y agoIt makes sense, historically. They had AI features that were always on. Some people complained so they introduced a flag to, wait for it, disable the ai features. So they didn't think too deeply about it and named the flag "disable_ai" because it mapped into how they were thinking about it. You overstate the problem with negative booleans. It's trivial for them to add a function: fn isAiEnabled() { return !disable_ai } and just use that.
- andoando 1y agoI mean you may equally want if(disable_ai) { //disable shit }
- echelon 1y agoI think AI-enabled is going to be the default for all future code development. Autocomplete is just so good, and I never want to go back. I spent 20 years without it. That's enough for one lifetime.
- cardanome 1y agoHow long did it take for you to get used to the autocomplete? I completely hated it when I tried it out. It breaks my flow. Those weird pauses are so painful. Feels like someone grabbing the steering wheel while I am driving. I heavily use the agent mode but I don't understand the appeal of the autocomplete feature but maybe I am missing something.
- roguecoder 1y agoYou spent 20 years without autocomplete? I started using Eclipse's autocomplete & shortcut macros in 2002. It is fascinating to me how much of the enthusiasm around AI seems to be the result of people not knowing about/using the deterministic tools that already exist.
- echelon 1y agoThat's not at all the same. AI autocomplete can generate the entire `match` tree for a very complex Rust enum, and also generate all of the associated tests. It then takes me to the next places in the code where changes need to be made. It's wildly good at knowing exactly what I want to do next. 2002 macros and autocomplete were not that and cannot possibly be compared in the same light.
- nlitened 1y agoIt's good and predictable that all boolean settings to be false by default (when not set). And the default behavior is the one that is compatible with older version — changing the defaults is a breaking change that should usually be avoided.
- zzo38computer 1y agoYes, this is especially useful if the boolean settings are stored in a bit field, in my opinion. In the case of Zed, according to the article, it uses JSON, but if a program uses a bit field instead then it would make sense.
- comprev 1y agoThe wording implies that disabling a default feature is used by a handful of edge cases and Zed has done their best to accommodate these users. From a business perspective, investors want to hear that AI is indeed part of the shipped product. It's all about optics. "disable_user_tracking: false" vs "enable_user_tracking: true" "disable_adverts: false" vs "enable_adverts: true" Fewer people would actively _enable_ user tracking or adverts compared to those who would take extra steps to _disable_ them.
- jeffbee 1y agoIMHO flags like this should always reflect the planned steady state. If you plan for a feature to be on in general, then the flag should be a disabling flag that eventually goes away.