15 ms·

You can't do that because I hate you

226 points by nivethan 3y ago

eurleif 3y ago
>I understand that <function exit> might be confusing for newcomers, and exiting might be too destructive. But denying you the normal REPL behavior and denying you the ability to exit is just insulting. Sentence 1 provides a clear justification for the behavior. Then sentence 2 declares, by bare assertion, that it's "insulting". I find sentence 1 more persuasive than sentence 2.
- wharvle 3y ago
  1 may be more persuasive but it’s 2 that makes me wish someone a very bad day every time that message prints.
- zarzavat 3y ago
  The correct behavior is to print: Are you sure you want to exit? [y] and then you press enter again to exit.
  - eurleif 3y ago
    The correct behavior from `repr()` isn't to do anything, including reading from stdin. That would break documentation generators, along with anything else that expects to be able to call `repr()` without side effects.
    - zarzavat 3y ago
      Nobody said anything about repr()? It's the REPL's job to handle this case and provide a good UX.
      - eurleif 3y ago
        `exit` is simply a function. The text it displays at the REPL now is simply the result of calling `repr()` on that function. Adding a special case would make the REPL more complicated, and would make it inconsistent. Technically it wouldn't even be an REPL anymore, since it wouldn't be doing the "P" part for certain objects. And the special case would break tools that rely on the REPL behaving consistently.
valyagolev 3y ago
Weirdly I'm very used to this kind of stuff and take it very easily from programmers, but when a german bureaucrat does this same thing to me I'm also fuming.
mrblampo 3y ago
First example seems odd? The author acknowledges that the two proposed alternatives (printing "<function exit>" or actually exiting) aren't great. The fact that the Python REPL provides a helpful hint seems like extra effort to make your life easier. This is especially notable given that in the next example, the author's complaint is about a command _not_ providing special guidance about the thing the user is probably trying to do.
- pluc 3y ago
  Yeah. "I know it's not right, but it's not totally wrong and probably better than not doing anything" actions as maddening as the behaviour he describes. A world where that's the standard would be chaos. When you work with _precise_ systems, they sometime take _precise_ input to work. That's kinda just part of the job.
  - phs318u 3y ago
    Except in the case of the 'exit' clearly this is accepting and parsing imprecise input in order to guide the user. If the code wasn't looking for 'exit' in order to correct the user (to use 'exit()'), it would just spit out some other error for 'I don't know what you're talking about'. Instead, they actually detect the intent by specifically coding for it... and then ignore it anyway. That's bloody minded.
    - gruez 3y ago
      How do you feel about java/c++ compiler that give hints like "missing semicolon"? Clearly it knows what's wrong. Why not automagically fix that for you[1]? https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Lexical_grammar#automatic_semicolon_insertion https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
      - akoboldfrying 3y ago
        JavaScript automatic semicolon insertion does a great job most of the time, but still leads to bafflement when code like const b = 1 [1, 2, 3].forEach(console.log) (from your linked page) does the wrong thing, because both forms (with and without a semicolon) are syntactically valid. I would much rather just always use semicolons (or, like Python, never use them) than have to memorise the 5% of oddball cases where I need to add them manually to resolve ambiguity.
zem 3y ago
the trouble with "do what I mean" is that if the software guesses, and guesses wrong, the results are far worse than just not doing it. an "if you really meant to do this here is the correct incantation" error message seems like the best possible thing to do.
- burnte 3y ago
  The problem with this argument is the low hanging fruit. EXIT is pretty unambiguous. I HATE that some tools the help argument is -? and others use --? when everyone COULD just print help on both is maddening, especially when you use the "wrong" one and it just says "do the other for help". You KNEW what I wanted, and didn't do it, just like the article says. Yes, mindreading is tricky, but sometimes you don't need to read minds to just work with the user.
  - breischl 3y ago
    The problem is that all the "do what I mean" examples become part of the spec, and then have to be supported forever. Whereas "prints an extra-informative error" is much easier to change. Even for low hanging fruit. eg, `exit` in Python can be redefined as a variable - so if I do that and then type `exit`, should it print that value for me or quit the REPL? Is it better to guess, or just not encourage the user to do the wrong thing? If I make `-?` print help, what happens when I want to define `-` as "read the following text as input" and then users start getting bizarre behavior instead of the help file? You can probably come up with ever-fancier ways to work around this, but that takes effort, and more testing, and more code...
    - Hizonner 3y ago
      > If I make `-?` print help, what happens when I want to define `-` as "read the following text as input" and then users start getting bizarre behavior instead of the help file? I'm not sure what that means, but if you're saying that you would want your program to interpret "-?" as though somebody had run it with no option at all and then provided a question mark on the standard input, that's really obnoxious and grounds for torches and pitchforks from all users. Look, on a command line, a bare hyphen, given as an argument where there might otherwise be a filename, can reasonably mean "read from the standard input" or "write to the standard output", but only because it's been so common for so long. As an alternative to it, you can just use standard input/output by default, or you can just punt and make the user give you something like "/dev/stdin". In any other context, a hyphen introduces an option that modifies normal program behavior. If it's a single hyphen, then the option name is a single character. If it's a double hyphen, the option name is the rest of the argument up to any equal sign. It should consist of complete words and be in `kebab-case`, not `snake_case`. But even if you violate those rules, it's a far more basic rule that an argument starting with a hyphen is an OPTION NAME, not arbitrary data. And the options "-h", "--help", and I guess maybe "-?" and "--?" are pretty much universally used to mean "print help about how to use your program". Changing that is insane. I know that code on on Windows does horrific stuff (including pretending it's freaking RSX-11 and using slashes of all things). I know that some really old UNIX stuff written in the bad old days also breaks the rules. But even those don't just arbitrarily redefine what the hyphen means. Redefining absolutely everything under the user, to the point where they can't even guess how to ask for help, is just crazy.
avg_dev 3y ago
I feel this post. I can relate. I once said - and still maintain - that all devs need a life-long lesson in empathy. For our users and our library consumers and so on. It will be impossible to fix every conceivable issue and sometimes we will have to deprecate or break backward compatibility or features or whatever. But if maybe some more effort to understand and respect our users was made as a matter of course, then when we are users we will be more inclined to give the benefit of the doubt to the developer who created the thing. Also the post made me laugh.
et1337 3y ago
The last example is actually a great argument in favor of this “user-unfriendly” mindset. The removal of that CLI flag forced the user to actually figure out the root cause of the problem rather than paper it over with a workaround they didn’t really understand, which would inevitably metastasize and explode later in an even more frustrating way. All of these examples are devs trying to make sure users understand what’s going on. Nothing wrong with that when it is necessary complexity. The trouble I think comes when you’re making sure the user understands something that really shouldn’t matter - unnecessary complexity. Especially complexity that is just a byproduct of a disorganized group of people building a “bazaar”, like in the Node ecosystem (and apparently Rust too). Who cares if X is actually a fork of Y that was merged into Z.
- jmholla 3y ago
  > The removal of that CLI flag forced the user to actually figure out the root cause of the problem rather than paper it over with a workaround they didn’t really understand, which would inevitably metastasize and explode later in an even more frustrating way. I wish the author had written what the real issue is. It feels like they are contributing the the very problems they are complaining about with a flippant line about it being something else.
  - bvisness 3y ago
    The problem was a strange monorepo setup where multiple packages came from the same GitHub repo. Then I tried to switch one of them to my fork. The error message did not help me understand this reality at all; I only figured it out the very hard way after blowing up my project in two different ways.
    - deleted 3y ago
      [deleted]
jgilias 3y ago
Such a weird rant. Yes, some tools do some things, but not others. Making tools do everything for everyone just bloats them to unmaintainable messes. And it’s a special kind of entitlement to believe that the way _I_ imagine things must be working is the only possible correct interpretation. Reality is messy, there are trade-offs, and a lot of smart people think very hard about what the correct trade-offs should be given a particular situation. And, the last pet peeve of mine. If I got a dime every time someone says ‘why don’t you just’ without even beginning to start to realize the depth of an issue, I’d be a very rich man. That’s about this quote here: > What would it possibly take to “stabilize” such a feature? It is a completely trivial feature!
- gizmo 3y ago
  Not having a feature is fine. Kind of having a feature but hiding it behind obnoxious gatekeeping is not fine. Features that are buggy or inexplicably complex is not fine. Some open source projects get this right, and others don't. Some projects don't care about wasting the user's time. Or they berate the user for wanting to do something in the 'wrong' way. Or they break things that worked just fine in the pursuit of some abstract purity. It's not about complexity or technology at all. It's an attitude problem.
  - bryanlarsen 3y ago
    I really appreciate the way Rust feature gates unstable features. It's easy to opt into nightly if you need them, it's nice that new features are iterated until they are correct and it is nice to rely on stable being stable.
    - gizmo 3y ago
      You can just prefix features with --experimental so people can use their own judgement. Software should warn users when they do something that might harm them. But it shouldn't patronizingly refuse to run. "I'm sorry bryanlarsen, I'm afraid I can't do that." - 2023 a rustfmt Odyssey.
ambicapter 3y ago
> “Unstable features”???? How is wrapping text an unstable feature in a code formatter? Haven't finished the whole thing, but wait till you start reading about LaTeX.
TheCoreh 3y ago
The unstable warning preventing you from wrapping the comments actually seems pretty reasonable to me. It is implemented, but there are probably edge cases where the proper way to wrap and retain the best possible formatting is still disputed. Since a lot of people format on save, via commit hooks or during CI, having this feature enabled as stable and _changing the behavior later_ would cause massive annoying diffs in the future, or CI failures for a ton of projects.
- ender341341 3y ago
  other posts pointed out the issue, it breaks certain markdown formatted comments (mainly tables).
  - pdimitar 3y ago
    It would be very valuable if that was part of the tool's explanation then.
- tedunangst 3y ago
  Gating it behind nightly is just bizarre though. Today's nightly, where the feature is available, will turn into 1.76 or whatever, but then the feature will become unavailable again. That is not how normal software works.
  - deleted 3y ago
    [deleted]
  - NobodyNada 3y ago
    I don't know the intention of the Rust team, but maybe it's because of the difference in release cycles: if a bug is found in an unstable feature today, it can be fixed by tomorrow's nightly build, but it won't make it into stable until at least February. Presumably, the maintainers don't want to release code that is in flux and under active development under the same 6-week release cycle that they release stable, well-tested code.
  - cedilla 3y ago
v9v 3y ago
I like the MATLAB REPL a lot with regards to this issue. If you make a typo in a function or variable name, the REPL fixes it automatically and you press enter to send the corrected command. From the story submitted here about Medley Interlisp, I gather that its REPL also has such a feature.
0cf8612b2e1e 3y ago
Do what I mean, not what I said can be problematic for tools. That being said, the example where the devs left a link to file an issue to beg to restore functionality was maddening.
- Arnavion 3y ago
  "Beg", and "passive aggressive" from TFA, is an unnecessarily emotional interpretation of that sentence. It's perfectly neutral. When they imported `cargo-vendor` into cargo they removed a feature that was not trivial to reimplement, so they asked for an issue to be opened so that they can see if people want it and so that someone can decide to implement it. That message *could* be updated to point to https://github.com/rust-lang/cargo/issues/10310 https://github.com/rust-lang/cargo/issues/10310 instead of asking for new issues to be created or suggesting the old `cargo-vendor`. (The author of TFA already knows about that issue, since they commented on it before they published their article.) (You might say it would've been better to let cargo-vendor remain separate instead of merging it into cargo, but the reason that was done was to ensure it would continue to work with changes to cargo. Indeed that is why the original cargo-vendor does *not* work properly any more.)
- phs318u 3y ago
  Agreed, but in that case the tool shouldn't be trying to detect what I mean. Why look for 'exit' only so you can print 'no actually, it's exit() dummy'. If you're parsing for it then just bloody do it! Otherwise I'll get a syntax error and realise that 'exit' isn't the right way to exit. And I'll do a quick search myself. But explicitly looking for and detecting my intention and then ignoring it is just dumb.
  - slooonz 3y ago
    Nothing is looking for exit. The REPL is calling repr(result) to show the result of the expression to the user. repr(exit) is the string "Use exit() or Ctrl-D (i.e. EOF) to exit". You _really_ don’t want repr(builtin) to have a side-effect like terminating the program. Stop being toxic and patronizing towards open-source developers out of ignorance.
thatguysaguy 3y ago
It's so strange to me that the first example is one where the devs went out of their way to help the users. There's no world in which that's maliciousness or anything of the sort.
Arnavion 3y ago
>It wasn’t seeing my file, despite it absolutely being part of the project. It even found the lib.rs in my crate but not this particular source file. I have no idea why, Because it's not in fact part of their project, despite their assertion that it is. >But you can’t. cargo fmt doesn’t have an option for that. How is even possible for your format command to not let you format an individual file? Because cargo is a tool for working with projects, not with individual source files. >Problem is, I had never even heard of rustfmt. Putting "rust how to format a file" into a search engine returns rustfmt in the top results. But in any case, the problem they needed to fix is to make that file a part of their project so that `cargo fmt` will format it, not work around that by running rustfmt manually. But alas they've convinced themselves that's not the problem. >At this point I was just hopping mad. It knew that I wanted to wrap comments. But it refused, because this was “unstable”. It knew that I wanted to opt into experimental features, but refused again. Whatever method they used to install nightly, they're not using it here. The error is coming from the non-nightly rustfmt that they were using originally. >It would literally have been better if they had not shipped this wrap_comments feature at all. Instead they just keep dangling it in front of my face and snatching it away as soon as I try to use it. Because they hate me. I'd be amused at this trolling if I didn't know the author is completely serious.
- bvisness 3y ago
  Some of us just wander into the Rust part of the codebase every so often for our work. I cd’d into the folder with the cargo.toml, ran cargo fmt, and nothing happened. I dunno what else to tell you. Sometimes things just aren’t set up the “right way”, and yet we still have to do our jobs.
  - remexre 3y ago
    Does cargo test run unit tests in the file you're expecting to be formatted that isn't?
fifticon 3y ago
As a software developer, I am in wonder at the shape some software ships in. The last couple of days, I have toyed with Raspian bookworm together with my father. Its menu contains an 'Add-Remove Software' GUI tool, which seems to be a thin and ill-conceived wrapper around apt-get (?). It combines several horrible choices, which conflict and clash perfectly. (1) it appears to insist on retrieving and building its entire list of apt packages, EVERY TIME YOU TRY TO OPEN OR OPERATE IT. (2) it doesn't give you any choice to CACHE this data, or any choice to skip this "refresh". (3) it takes five minutes or more to refresh this list, on our raspberry 3. (4) on any excuse you give it, it will refresh the list again. (5) once it succeeds in retrieving this insane 5-minute list, it presents it to you in an unnavigable manner - no sorting, no searching, no filtering, just a scrolling list with something like 10.000 apt packages.. page up/page down doesn't seem to work. For example, I naively pressed the cursor keys, wrongly assuming it would move my selection point in the 10.000+ list.. WRONG: Instead, it navigated a category-word-list, causing it to redo the 5-minute re-init. In effect, it because a 'trial and error game from hell', where you can attempt 10 wrong ways to navigate the list, each time being punished with a 5-minute "no you can no longer view the list you just waited 5 minutes to retrieve, you must now wait 5 minutes again for your next wrong attempt!" (6) oh yeah, and you are not allowed to view the partial list during load. I really really wonder who decided to implement that window in that maddening way?? In the end, I resorted to using apt search in the command line, which of course works perfectly, but not before having wasted about an hour together with my less-tech-savvy dad, trying to make the raspian package install UI "work" in the naive idea it would be easier for him to use :-/.
- FirmwareBurner 3y ago
  Certain Linux UI stuff can be an opinionated death by a thousand papercuts. Probably because most Linux devs don't dogfood their own stuff as they just stick to the command line anyway, so there's less incentive to fix the UI issues, if nobody in the dev chain is actually using it. I remeber when Linux GUI users were asking for a "Right click -> run/open as root" feature just like in Windows, and the devs basically said something along the lines of "we're not gonna do it just because the way Windows does it means it must be wrong; if you need to run stuff as root it means you're a poweruser so you should use the comand line anyway; you're welcome". Linux Mint was the first and only to have this feature in the GUI early on, then came the other DEs who ceded defeat to sanity.
Guvante 3y ago
Empathy is hard when dealing with thousands of users. For everything you think should obviously be A there are many vocal people who think B...
froh 3y ago
interaction design for API and CLI, text based interfaces, is both hard and underdeveloped. for example argparse and similar cli argument parsers _know_ the basic structure of the command line, but they don't provide it in machine table form, to interactive shells, so these could ask CLI tools: "hey, what do you expect at this point?"
groby_b 3y ago
This assumes 100% competent and knowledgeable users. Nobody is in every field, and so the question is "do we freely hand out footguns, or should we put a safety in place" In some fields, the decision is easy. We're by now culturally aligned that shipping encryption libs with bad APIs or a default-on footgun option is a bad idea. Clearly, with less impactful tools, we still have more debate ahead of us. I'm hoping that we'll realize at some point that proper engineering is always fail-closed[1] if there are destructive consequences. Yes, it might temporarily inconvenience some, but it prevents harm to more. Ultimately, the question is "Who is more important, you, or the rest of the world". [1] fail-open if you're EE. We're so bad, we can't even decide on terminology.
smitty1e 3y ago
Writing this sort of rant in English is meta-hilarious.
shepherdjerred 3y ago
The author provides very surface-level criticism of two Rust tools , but they don't look into why those choices were made. I'm ignoring the Python complaint since it's discussed in other comments. With about five minutes of my time, I found out: wrap_comments was introduced in 2019 [0]. There are bugs in the implementation (it breaks Markdown tables), so the option hasn't been marked as stable. Progress on the issue has been spotty. --no-merge-sources is not trivial to re-implement [1]. The author has already explained why the flag no longer works -- Cargo integrated the command, but not all of the flags. This commit [2] explains why this functionality was removed in the first place. Rust is open source, so the author of this blog post could improve the state of the software they care about by championing these issues. The --no-merge-sources error message even encourages you to open an issue, presumably so that the authors of Cargo can gauge the importance of certain flags/features. You could even do something much simpler, like adding a comment to the related issues mentioning that you ran into these rough edges and that it made your life a little worse, or with a workaround that you found. Alternatively, you can continue to write about how much free software sucks. [0]: https://github.com/rust-lang/rustfmt/issues/3347 https://github.com/rust-lang/rustfmt/issues/3347 [1]: https://github.com/rust-lang/cargo/pull/10344 https://github.com/rust-lang/cargo/pull/10344 [2]: https://github.com/rust-lang/cargo/commit/3842d8e6f20067f716c99ba39f4d9f2c8abe84f2 https://github.com/rust-lang/cargo/commit/3842d8e6f20067f716...
- flimsypremise 3y ago
  5 years to get a wrap_comments feature stable? I sometime wonder if people read the things they write?
  - haileys 3y ago
    I mean... check out the issue tracker for any project, open source or commercial. It's just how it goes when things aren't a priority. Happens all the time.
  - shepherdjerred 3y ago
    The conversation was about why the feature wasn't stable. I have no idea how the Rust project organizes itself, but my guess is that this simply isn't a high enough priority for them, which would explain why it hasn't been made stable. Large backlogs with stale are a common problem that software projects have.
LoganDark 3y ago
I feel the same way about Rust unstable features. Either you can only use features that are "stabilized"—guaranteed to never change—or you can throw all guarantees out the window, and use the unstable, experimental version of the toolchain. This would be fine if "unstable" features were actually experimental messes, but all sorts of completely-benign utility functions are "unstable". You have to throw out all guarantees for your entire toolchain just to use, say, `Result::into_ok`, which was introduced in 2019, but is still unstable due to being "newly added". At best, this is misleading, at worst, this greatly compromises the developer experience, especially when writing libraries which need to work on stable or else nobody will install them. Even for application projects, I don't want to use unstable features, because it's extraordinarily stupid to make the entire project nightly-only just because I want to use a two-line utility function, and I'm petty that way. Sure, I'll use unstable for things like bare-metal programming that deserve to be unstable, but if I'm writing regular application code and the perfect utility function is "unstable", I'm not going to lock myself into nightly just for that.
- shepherdjerred 3y ago
  > but is still unstable due to being "newly added". Where did you get this from? The tracking issue says nothing of the sort: https://github.com/rust-lang/rust/issues/61695 https://github.com/rust-lang/rust/issues/61695
  - Arnavion 3y ago
    Right, it's nothing to do with it being "newly added". That issue had been filed by its OP as a feature request. It then got repurposed into a tracking issue for the feature, but it's not following the standard tracking issue template that lists any blockers, stabilization steps, etc. (Compare to https://github.com/rust-lang/rust/issues/119364 https://github.com/rust-lang/rust/issues/119364 that happens to be the newest "Tracking issue" atm.) Also since the OP didn't intend for it to be the tracking issue, it's possible they're not intending to do the rest of the bureaucracy to get it stabilized either, which is why it's stalled.
    - 3y ago
jbirer 3y ago
Rust is a great language but the developers suffer really badly from Reddit Intellectual syndrome. If they put some people with social skills at the forefront of relations with users it would definitely get more adoption.
- local_crmdgeon 3y ago
  Rust and TypeScript came onto the scene at about the same time. Microsoft manages TS more or less, Redditeurs manage Rust. Fun to see which is thriving and which is still niche!
- deleted 3y ago
  [deleted]
corytheboyd 3y ago
It’s a hard job that requires a lot of learning, failing, adapting, and growing. It’s frustrating, but getting good can only be done through endless grind. There are no cheat codes. After encountering and overcoming the roadblocks mentioned in the article, you grow keen to that class of problem, and next time, more quickly figure it out and move on. An apprentice woodworker is going to fuck up a cut and have to spend hours rebuilding. An aspiring musician is going to pour hours into mediocre music that nobody listens to. A new software engineer is going to get lost in the sea of complexity built on top of the rapid growth and death of fads and doctrines and tools (good and bad) that is decades deep. It’s fucking hard. I do think the pay reflects that, though perhaps is a biiiiit inflated. Regardless, shit ain’t easy. That being said, people generally quite enjoy sharing their knowledge, and helping the next generation of software people ramp up and kick ass, so there may be hope yet :)
starkparker 3y ago
I empathize with a lot of this. With experience and knowledge it's easy to recognize why and how these things happen, to point them out, and to call the author wrong. But I also remember being new to tools and not understanding how arbitrary they seem to be, in that they can understand what I want to do with uncanny precision but simultaneously refuse to do it. Things like exiting vim are the gold standard of this.[1] But: > Either support the feature, guide the user toward a better solution, or do nothing. The first two examples _explicitly_ guide the user toward better solutions. That's much more than many tools do. If the Python repl behavior isn't "guide the user toward a better solution" in both letter and spirit, I'd love to know why. There are much lower-hanging fruit than these examples, which makes a good point harder to agree with. 1: One of the first-page Google results for me on quitting vim is somehow this HN comment thread from 2017, in which the Python repl behavior catches strays with almost identical arguments as this article. https://news.ycombinator.com/item?id=14403297 https://news.ycombinator.com/item?id=14403297
Frummy 3y ago
>Exiting Python In early versions of COBOL exit was frequently used to go out of loops and out of sections and so on. Maybe a message is nice for someone still trying that while learning modern stuff, but I admit it’s farfetched/unlikely.
devilirium 3y ago
Change what you want and can.
prepend 3y ago
> But it does neither. It acknowledges your intent and refuses it. It’s saying “I know exactly what you want to do, but you’re doing it wrong. Do it right next time.” Programming languages follow rules and programmers should follow the rules. Just because mistake is common doesn’t mean the language should incorporate it into its functioning. That makes inconsistent behavior and is a pain in the long run because instead of learning and following logic, programmers have to guess what’s a common enough error that the language compensates. And over time the language drifts and is hard to work with. It seems easier to me to just suck it up and learn the right way to do things in a language.
- williamtrask 3y ago
  > “Just because mistake is common” A good example of why having a language that is squishy to common errors is valuable. I still understood your point even though it’s grammar wouldn’t compile.
  - prepend 3y ago
    Humans aren’t programming languages. So programming languages don’t need to do everything humans do. It’s ok for things to be different. It’s cool that I understood what you meant when you said “it’s grammar wouldn’t compile” but I would definitely expect a compiler to barf unless you entered “its grammar.”
    - shpx 3y ago
      Programmers just haven't been able to make computers as good at language as humans are at language because they're not good enough at their jobs. There's no inherent reason that programming language statements need to perfectly follow regular grammars and have exactly defined vocabularies (functions) that compile to ASTs, etc. that's just the highest level of language technology we've invented. It has essentially no error recovery mechanisms because it's hard/tedious and error is hard to model using logic. Being frustrated that this is the case is expressing an underserved need in the market. You're aware of the limitations and have grown to be okay with them because otherwise you'd probably hate programming, but that doesn't mean we should all always be okay with them forever.
IshKebab 3y ago
This rant is spot on and it's disappointing (but not surprising) that there are so many commenters here that don't get it. Honestly a few years ago I'm not sure I would have got it. It definitely seems to be specific developers/communities that suffer from this "UX doesn't exist" sort of attitude. I have also run into Rustfmt issues when trying to format single files (necessary for Phabricator's arc lint) and they have an unreleased "version 2" which we dutifully used from source... for 5 years. It turns out their plan is to never actually release this. Python also seems to fuck over its users quite a bit. Two examples: 1. Setuptools has broken editable installs so that static tooling (IDEs, linters, type checkers etc.) can't work with editable installs. Because who would want to edit Python code with an IDE, amiright? Facepalm. 2. On Windows there is no python3.exe. Say goodbye to portable instructions/scripts. Why you ask? Well there's some obscure situation if you have multiple Python installs in your PATH and by some miracle that hasn't totally trashed your system already (relevant XKCD) that it would trash your system slightly more. So we won't ever fix that. And please don't point out that if you install Python from the Microsoft store it does install python3.exe.
- sevagh 3y ago
  >This rant is spot on and it's disappointing (but not surprising) that there are so many commenters here that don't get it. Honestly a few years ago I'm not sure I would have got it. Nailed it. A few years ago, I was deep enough in the zeitgeist of Rust (or whatever project) that I would maybe even be offended by a blog post like this; bro, do you think you're better than Rust? Keep up like the rest of us! After years of doing actual things (and not meta-learning), when there's something that makes no sense that ruins my day, I hate it.
bvisness 3y ago
All this time after writing this article, I’m now realizing a better way to sum up the issue: It’s like when you ask “can I go to the bathroom” and the teacher says “I dunno, CAN you?”
- lacrimacida 3y ago
  Your rant is very valid by the way. I didn’t have these particular problems but you captured the essence of similar experiences I’ve had with other tools. Just the thougt of tinkering with something im not familiar gives me the goosebumps, maybe a little nausea, shortness of breath. Maybe it’s some form of PTSD gradually accumulated over the years. In the end it’s no big deal if you don’t expect things to work logically and things to work from the first try.
  - ryandrake 3y ago
    I think it's a totally valid rant too. We get so used to our tools laughing at us saying "Ha ha ha! You didn't say the magic word!" And then a few searches or manual lookups later, you learn the magic word and use it, the tools say "Ha ha ha! We've deprecated that function!" And slowly through our careers, we just start accepting it as an inevitable fact of programming.
deleted 3y ago
[deleted]
stavros 3y ago
https://archive.is/AYTEM https://archive.is/AYTEM
deleted 3y ago
[deleted]
avalys 3y ago
I have a similar pet peeve in software, what I refer to as ‘Don’t Suck’ Buttons. A ‘Don’t Suck’ Button is a setting, turned off by default and usually hidden in a corner of the UI or configuration file, which fixes a common issue that new users experience, and/or turns on the behavior that everyone wants from the product in the first place. The best examples of ‘Don’t Suck’ Buttons involve settings with no obvious disadvantage to turning them on. They’re just turned off by default and the software makes you go through extra effort to tell it “No, I don’t want you to suck.” Usually these originated from some kind of automation, new protocol or new feature that started out as experimental and was locked behind a setting, then became universally relied upon but somehow never enabled by default. I used to have a list of examples of these. One that comes to mind from my TV: “Allow HDMI Devices to Control this TV”. If you have an Apple TV or something, it won’t change the volume or be able to turn the TV on or off automatically unless you know enough to go into settings and tell the TV “Don’t Suck”.
- amluto 3y ago
  > “Allow HDMI Devices to Control this TV” It would IMO be nice to have a default-off option to disable CEC on a specific port. Or to disable certain CEC features.
  - lucasban 3y ago
    For example: If I leave my TV set to the input that my PS5 is on, turning the TV on will turn on the PS5. Because the PS5 takes a few seconds to turn on, if I try to switch to another app or input, the PS5 will switch the input back when it finishes waking up. Ideally, I’d allow CEC for all functions except turning the PS5 on. If I want it on, I’ll use the controller or media remote.
  - thedanbob 3y ago
    I had to disable CEC because my Chromecast would randomly turn on the TV in the middle of the night. Disabling on a single port would be great.
- johnfn 3y ago
  One common reason these exist is because a lot of people got used to the state where the "Dont Suck" button didn't exist, and for those users changing their workflow would be even more annoying. I do agree it's not a great state of affairs, though.
thrwggrdxvgf 3y ago
[flagged]
invalidator 3y ago
My personal peeve: $ git log directory --stat fatal: option '--stat' must come before non-option arguments Come on, Git, you know what I want. Just do it without making me repeatedly edit the middle of the command.
__s 3y ago
If you think these are examples of why programming is hard do I have news for you Python's error message is a compromise, they could've just printed the unknown variable error Rust has unstable features to prevent tooling running into issues like ci failing everytime there's a minor version update
naikrovek 3y ago
I agree with the authors conclusion that we make this stuff hard on ourselves. No one hates software developers more than other software developers, and no one understands usability less than a software developer. This is one of those things I thought would get better over 30 years but has just continually gotten worse.
interstice 3y ago
I have run into this with JavaScript, Shopify and numerous applications. Usually it’s because an internal ideology or future plan js incompatible with a currently working featured. It’s mildly annoying when there is no recommended replacement. It’s very annoying when there are a bunch of suggested alternatives that don’t work. The worst is when the attitude is “you shouldn’t be trying to do it this way in the first place” when there really is no good alternative.
laidoffamazon 3y ago
I like these examples, particularly in the Rust ecosystem because they mirror my frustration with Rust exactly - code examples fail in embedded documentation because of nightly channel differences, libraries that assume dependency on one stdlib or another, it's a massive cognitive load on top of the already obvious load of the borrow checker.
deleted 3y ago
[deleted]
LtWorf 3y ago
What a bad article! He wants a function to work as a keyword! He wants comments word wrapped by default, when this would break comments that contain stuff like packet fields schemes. Terrible ideas, and he complains they aren't the default. Well that's because they aren't good ideas and he hasn't thought about it long enough to figure it out.
deleted 3y ago
[deleted]
zubairq 3y ago
Haha, made me laugh out loud at how true this statement feels, even though it is probably not true: "If you don't enjoy programming, don't worry, it is not your fault. Thousands of people around the world work hard day and night to make programming as miserable for you as possible."
stgr_codes 3y ago
This is literally Typescript vibes all around... Awful dev experience, it's a fucking joke and people seem to like it...
octacat 3y ago
Yes, and rm knows that I want rm -rf. But there are rules...
octacat 3y ago
The example with experimental features is soo weird. It is like the author knows why experimental features exist but trying to play confused to fit the narrative. OK, nighty builds. So, some features could be coded, but haven't been tested for a long enough time to say "this feature is rock solid and the behaviour is good for all combinations of code". In the formatter, we probably would not wanna change the behaviour of a flag once it goes stable (and in the formatter there are always several ways to do anything, because it is just how code is). So, there are more or less two options when adding new features: only merge a feature branch when you are 100% happy (that could make releasing hard) or have a feature behind a flag and document it is an experimental. In the real world - having feature behind a flag is good. For some reason people assume that open source projects have a huge team, and all their time is free. So, adding a new feature to a formatter is "easy and trivial" (and make that feature stable is "trivial" too).
deleted 3y ago
[deleted]
garaetjjte 3y ago
I guess the author loves PHP?
kazinator 3y ago
> There are two reasonable things that Python could do here: There is a third one. Since exit is a binding to a function, it should print that function. >>> print <built-in function print> >>> exit Use exit() or Ctrl-D (i.e. EOF) to exit What? I expect <built-in function exit>
deterministic 3y ago
If you deprecate an API used by other developers, then you should not work on API’s used by other developers. It’s that simple. Yes it might save a bit of time for you, but it also potentially waste orders of magnitude more time for other developers. Developers who will positively hate you for forcing them to fix something that is not a problem for them! Instead keep the old API working and make the path to upgrade easy and smooth. Your API users will love you for it.

226 points by nivethan 3y ago

>I understand that <function exit> might be confusing for newcomers, and exiting might be too destructive. But denying you the normal REPL behavior and denying you the ability to exit is just insulting. Sentence 1 provides a clear justification for the behavior. Then sentence 2 declares, by bare assertion, that it's "insulting". I find sentence 1 more persuasive than sentence 2.

wharvle 3y ago
1 may be more persuasive but it’s 2 that makes me wish someone a very bad day every time that message prints.
zarzavat 3y ago
The correct behavior is to print: Are you sure you want to exit? [y] and then you press enter again to exit.
- eurleif 3y ago
  The correct behavior from `repr()` isn't to do anything, including reading from stdin. That would break documentation generators, along with anything else that expects to be able to call `repr()` without side effects.
  - zarzavat 3y ago
    Nobody said anything about repr()? It's the REPL's job to handle this case and provide a good UX.
    - eurleif 3y ago
      `exit` is simply a function. The text it displays at the REPL now is simply the result of calling `repr()` on that function. Adding a special case would make the REPL more complicated, and would make it inconsistent. Technically it wouldn't even be an REPL anymore, since it wouldn't be doing the "P" part for certain objects. And the special case would break tools that rely on the REPL behaving consistently.

valyagolev 3y ago

Weirdly I'm very used to this kind of stuff and take it very easily from programmers, but when a german bureaucrat does this same thing to me I'm also fuming.

mrblampo 3y ago

First example seems odd? The author acknowledges that the two proposed alternatives (printing "<function exit>" or actually exiting) aren't great. The fact that the Python REPL provides a helpful hint seems like extra effort to make your life easier. This is especially notable given that in the next example, the author's complaint is about a command _not_ providing special guidance about the thing the user is probably trying to do.

pluc 3y ago
Yeah. "I know it's not right, but it's not totally wrong and probably better than not doing anything" actions as maddening as the behaviour he describes. A world where that's the standard would be chaos. When you work with _precise_ systems, they sometime take _precise_ input to work. That's kinda just part of the job.
- phs318u 3y ago
  Except in the case of the 'exit' clearly this is accepting and parsing imprecise input in order to guide the user. If the code wasn't looking for 'exit' in order to correct the user (to use 'exit()'), it would just spit out some other error for 'I don't know what you're talking about'. Instead, they actually detect the intent by specifically coding for it... and then ignore it anyway. That's bloody minded.
  - gruez 3y ago
    How do you feel about java/c++ compiler that give hints like "missing semicolon"? Clearly it knows what's wrong. Why not automagically fix that for you[1]? https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Lexical_grammar#automatic_semicolon_insertion https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
    - akoboldfrying 3y ago
      JavaScript automatic semicolon insertion does a great job most of the time, but still leads to bafflement when code like const b = 1 [1, 2, 3].forEach(console.log) (from your linked page) does the wrong thing, because both forms (with and without a semicolon) are syntactically valid. I would much rather just always use semicolons (or, like Python, never use them) than have to memorise the 5% of oddball cases where I need to add them manually to resolve ambiguity.

zem 3y ago

the trouble with "do what I mean" is that if the software guesses, and guesses wrong, the results are far worse than just not doing it. an "if you really meant to do this here is the correct incantation" error message seems like the best possible thing to do.

burnte 3y ago
The problem with this argument is the low hanging fruit. EXIT is pretty unambiguous. I HATE that some tools the help argument is -? and others use --? when everyone COULD just print help on both is maddening, especially when you use the "wrong" one and it just says "do the other for help". You KNEW what I wanted, and didn't do it, just like the article says. Yes, mindreading is tricky, but sometimes you don't need to read minds to just work with the user.
- breischl 3y ago
  The problem is that all the "do what I mean" examples become part of the spec, and then have to be supported forever. Whereas "prints an extra-informative error" is much easier to change. Even for low hanging fruit. eg, `exit` in Python can be redefined as a variable - so if I do that and then type `exit`, should it print that value for me or quit the REPL? Is it better to guess, or just not encourage the user to do the wrong thing? If I make `-?` print help, what happens when I want to define `-` as "read the following text as input" and then users start getting bizarre behavior instead of the help file? You can probably come up with ever-fancier ways to work around this, but that takes effort, and more testing, and more code...
  - Hizonner 3y ago
    > If I make `-?` print help, what happens when I want to define `-` as "read the following text as input" and then users start getting bizarre behavior instead of the help file? I'm not sure what that means, but if you're saying that you would want your program to interpret "-?" as though somebody had run it with no option at all and then provided a question mark on the standard input, that's really obnoxious and grounds for torches and pitchforks from all users. Look, on a command line, a bare hyphen, given as an argument where there might otherwise be a filename, can reasonably mean "read from the standard input" or "write to the standard output", but only because it's been so common for so long. As an alternative to it, you can just use standard input/output by default, or you can just punt and make the user give you something like "/dev/stdin". In any other context, a hyphen introduces an option that modifies normal program behavior. If it's a single hyphen, then the option name is a single character. If it's a double hyphen, the option name is the rest of the argument up to any equal sign. It should consist of complete words and be in `kebab-case`, not `snake_case`. But even if you violate those rules, it's a far more basic rule that an argument starting with a hyphen is an OPTION NAME, not arbitrary data. And the options "-h", "--help", and I guess maybe "-?" and "--?" are pretty much universally used to mean "print help about how to use your program". Changing that is insane. I know that code on on Windows does horrific stuff (including pretending it's freaking RSX-11 and using slashes of all things). I know that some really old UNIX stuff written in the bad old days also breaks the rules. But even those don't just arbitrarily redefine what the hyphen means. Redefining absolutely everything under the user, to the point where they can't even guess how to ask for help, is just crazy.

avg_dev 3y ago

I feel this post. I can relate. I once said - and still maintain - that all devs need a life-long lesson in empathy. For our users and our library consumers and so on. It will be impossible to fix every conceivable issue and sometimes we will have to deprecate or break backward compatibility or features or whatever. But if maybe some more effort to understand and respect our users was made as a matter of course, then when we are users we will be more inclined to give the benefit of the doubt to the developer who created the thing. Also the post made me laugh.

et1337 3y ago

The last example is actually a great argument in favor of this “user-unfriendly” mindset. The removal of that CLI flag forced the user to actually figure out the root cause of the problem rather than paper it over with a workaround they didn’t really understand, which would inevitably metastasize and explode later in an even more frustrating way. All of these examples are devs trying to make sure users understand what’s going on. Nothing wrong with that when it is necessary complexity. The trouble I think comes when you’re making sure the user understands something that really shouldn’t matter - unnecessary complexity. Especially complexity that is just a byproduct of a disorganized group of people building a “bazaar”, like in the Node ecosystem (and apparently Rust too). Who cares if X is actually a fork of Y that was merged into Z.

jmholla 3y ago
> The removal of that CLI flag forced the user to actually figure out the root cause of the problem rather than paper it over with a workaround they didn’t really understand, which would inevitably metastasize and explode later in an even more frustrating way. I wish the author had written what the real issue is. It feels like they are contributing the the very problems they are complaining about with a flippant line about it being something else.
- bvisness 3y ago
  The problem was a strange monorepo setup where multiple packages came from the same GitHub repo. Then I tried to switch one of them to my fork. The error message did not help me understand this reality at all; I only figured it out the very hard way after blowing up my project in two different ways.
  - deleted 3y ago
    [deleted]

jgilias 3y ago

Such a weird rant. Yes, some tools do some things, but not others. Making tools do everything for everyone just bloats them to unmaintainable messes. And it’s a special kind of entitlement to believe that the way _I_ imagine things must be working is the only possible correct interpretation. Reality is messy, there are trade-offs, and a lot of smart people think very hard about what the correct trade-offs should be given a particular situation. And, the last pet peeve of mine. If I got a dime every time someone says ‘why don’t you just’ without even beginning to start to realize the depth of an issue, I’d be a very rich man. That’s about this quote here: > What would it possibly take to “stabilize” such a feature? It is a completely trivial feature!

gizmo 3y ago
Not having a feature is fine. Kind of having a feature but hiding it behind obnoxious gatekeeping is not fine. Features that are buggy or inexplicably complex is not fine. Some open source projects get this right, and others don't. Some projects don't care about wasting the user's time. Or they berate the user for wanting to do something in the 'wrong' way. Or they break things that worked just fine in the pursuit of some abstract purity. It's not about complexity or technology at all. It's an attitude problem.
- bryanlarsen 3y ago
  I really appreciate the way Rust feature gates unstable features. It's easy to opt into nightly if you need them, it's nice that new features are iterated until they are correct and it is nice to rely on stable being stable.
  - gizmo 3y ago
    You can just prefix features with --experimental so people can use their own judgement. Software should warn users when they do something that might harm them. But it shouldn't patronizingly refuse to run. "I'm sorry bryanlarsen, I'm afraid I can't do that." - 2023 a rustfmt Odyssey.

ambicapter 3y ago

> “Unstable features”???? How is wrapping text an unstable feature in a code formatter? Haven't finished the whole thing, but wait till you start reading about LaTeX.

TheCoreh 3y ago

The unstable warning preventing you from wrapping the comments actually seems pretty reasonable to me. It is implemented, but there are probably edge cases where the proper way to wrap and retain the best possible formatting is still disputed. Since a lot of people format on save, via commit hooks or during CI, having this feature enabled as stable and _changing the behavior later_ would cause massive annoying diffs in the future, or CI failures for a ton of projects.

ender341341 3y ago
other posts pointed out the issue, it breaks certain markdown formatted comments (mainly tables).
- pdimitar 3y ago
  It would be very valuable if that was part of the tool's explanation then.
tedunangst 3y ago
Gating it behind nightly is just bizarre though. Today's nightly, where the feature is available, will turn into 1.76 or whatever, but then the feature will become unavailable again. That is not how normal software works.
- deleted 3y ago
  [deleted]
- NobodyNada 3y ago
  I don't know the intention of the Rust team, but maybe it's because of the difference in release cycles: if a bug is found in an unstable feature today, it can be fixed by tomorrow's nightly build, but it won't make it into stable until at least February. Presumably, the maintainers don't want to release code that is in flux and under active development under the same 6-week release cycle that they release stable, well-tested code.
- cedilla 3y ago

v9v 3y ago

I like the MATLAB REPL a lot with regards to this issue. If you make a typo in a function or variable name, the REPL fixes it automatically and you press enter to send the corrected command. From the story submitted here about Medley Interlisp, I gather that its REPL also has such a feature.

0cf8612b2e1e 3y ago

Do what I mean, not what I said can be problematic for tools. That being said, the example where the devs left a link to file an issue to beg to restore functionality was maddening.

Arnavion 3y ago
"Beg", and "passive aggressive" from TFA, is an unnecessarily emotional interpretation of that sentence. It's perfectly neutral. When they imported `cargo-vendor` into cargo they removed a feature that was not trivial to reimplement, so they asked for an issue to be opened so that they can see if people want it and so that someone can decide to implement it. That message *could* be updated to point to https://github.com/rust-lang/cargo/issues/10310 https://github.com/rust-lang/cargo/issues/10310 instead of asking for new issues to be created or suggesting the old `cargo-vendor`. (The author of TFA already knows about that issue, since they commented on it before they published their article.) (You might say it would've been better to let cargo-vendor remain separate instead of merging it into cargo, but the reason that was done was to ensure it would continue to work with changes to cargo. Indeed that is why the original cargo-vendor does *not* work properly any more.)
phs318u 3y ago
Agreed, but in that case the tool shouldn't be trying to detect what I mean. Why look for 'exit' only so you can print 'no actually, it's exit() dummy'. If you're parsing for it then just bloody do it! Otherwise I'll get a syntax error and realise that 'exit' isn't the right way to exit. And I'll do a quick search myself. But explicitly looking for and detecting my intention and then ignoring it is just dumb.
- slooonz 3y ago
  Nothing is looking for exit. The REPL is calling repr(result) to show the result of the expression to the user. repr(exit) is the string "Use exit() or Ctrl-D (i.e. EOF) to exit". You _really_ don’t want repr(builtin) to have a side-effect like terminating the program. Stop being toxic and patronizing towards open-source developers out of ignorance.

thatguysaguy 3y ago

It's so strange to me that the first example is one where the devs went out of their way to help the users. There's no world in which that's maliciousness or anything of the sort.

Arnavion 3y ago

>It wasn’t seeing my file, despite it absolutely being part of the project. It even found the lib.rs in my crate but not this particular source file. I have no idea why, Because it's not in fact part of their project, despite their assertion that it is. >But you can’t. cargo fmt doesn’t have an option for that. How is even possible for your format command to not let you format an individual file? Because cargo is a tool for working with projects, not with individual source files. >Problem is, I had never even heard of rustfmt. Putting "rust how to format a file" into a search engine returns rustfmt in the top results. But in any case, the problem they needed to fix is to make that file a part of their project so that `cargo fmt` will format it, not work around that by running rustfmt manually. But alas they've convinced themselves that's not the problem. >At this point I was just hopping mad. It knew that I wanted to wrap comments. But it refused, because this was “unstable”. It knew that I wanted to opt into experimental features, but refused again. Whatever method they used to install nightly, they're not using it here. The error is coming from the non-nightly rustfmt that they were using originally. >It would literally have been better if they had not shipped this wrap_comments feature at all. Instead they just keep dangling it in front of my face and snatching it away as soon as I try to use it. Because they hate me. I'd be amused at this trolling if I didn't know the author is completely serious.

bvisness 3y ago
Some of us just wander into the Rust part of the codebase every so often for our work. I cd’d into the folder with the cargo.toml, ran cargo fmt, and nothing happened. I dunno what else to tell you. Sometimes things just aren’t set up the “right way”, and yet we still have to do our jobs.
- remexre 3y ago
  Does cargo test run unit tests in the file you're expecting to be formatted that isn't?

fifticon 3y ago

As a software developer, I am in wonder at the shape some software ships in. The last couple of days, I have toyed with Raspian bookworm together with my father. Its menu contains an 'Add-Remove Software' GUI tool, which seems to be a thin and ill-conceived wrapper around apt-get (?). It combines several horrible choices, which conflict and clash perfectly. (1) it appears to insist on retrieving and building its entire list of apt packages, EVERY TIME YOU TRY TO OPEN OR OPERATE IT. (2) it doesn't give you any choice to CACHE this data, or any choice to skip this "refresh". (3) it takes five minutes or more to refresh this list, on our raspberry 3. (4) on any excuse you give it, it will refresh the list again. (5) once it succeeds in retrieving this insane 5-minute list, it presents it to you in an unnavigable manner - no sorting, no searching, no filtering, just a scrolling list with something like 10.000 apt packages.. page up/page down doesn't seem to work. For example, I naively pressed the cursor keys, wrongly assuming it would move my selection point in the 10.000+ list.. WRONG: Instead, it navigated a category-word-list, causing it to redo the 5-minute re-init. In effect, it because a 'trial and error game from hell', where you can attempt 10 wrong ways to navigate the list, each time being punished with a 5-minute "no you can no longer view the list you just waited 5 minutes to retrieve, you must now wait 5 minutes again for your next wrong attempt!" (6) oh yeah, and you are not allowed to view the partial list during load. I really really wonder who decided to implement that window in that maddening way?? In the end, I resorted to using apt search in the command line, which of course works perfectly, but not before having wasted about an hour together with my less-tech-savvy dad, trying to make the raspian package install UI "work" in the naive idea it would be easier for him to use :-/.

FirmwareBurner 3y ago
Certain Linux UI stuff can be an opinionated death by a thousand papercuts. Probably because most Linux devs don't dogfood their own stuff as they just stick to the command line anyway, so there's less incentive to fix the UI issues, if nobody in the dev chain is actually using it. I remeber when Linux GUI users were asking for a "Right click -> run/open as root" feature just like in Windows, and the devs basically said something along the lines of "we're not gonna do it just because the way Windows does it means it must be wrong; if you need to run stuff as root it means you're a poweruser so you should use the comand line anyway; you're welcome". Linux Mint was the first and only to have this feature in the GUI early on, then came the other DEs who ceded defeat to sanity.

Guvante 3y ago

Empathy is hard when dealing with thousands of users. For everything you think should obviously be A there are many vocal people who think B...

froh 3y ago

interaction design for API and CLI, text based interfaces, is both hard and underdeveloped. for example argparse and similar cli argument parsers _know_ the basic structure of the command line, but they don't provide it in machine table form, to interactive shells, so these could ask CLI tools: "hey, what do you expect at this point?"

groby_b 3y ago

This assumes 100% competent and knowledgeable users. Nobody is in every field, and so the question is "do we freely hand out footguns, or should we put a safety in place" In some fields, the decision is easy. We're by now culturally aligned that shipping encryption libs with bad APIs or a default-on footgun option is a bad idea. Clearly, with less impactful tools, we still have more debate ahead of us. I'm hoping that we'll realize at some point that proper engineering is always fail-closed[1] if there are destructive consequences. Yes, it might temporarily inconvenience some, but it prevents harm to more. Ultimately, the question is "Who is more important, you, or the rest of the world". [1] fail-open if you're EE. We're so bad, we can't even decide on terminology.

smitty1e 3y ago

Writing this sort of rant in English is meta-hilarious.

shepherdjerred 3y ago

The author provides very surface-level criticism of two Rust tools , but they don't look into why those choices were made. I'm ignoring the Python complaint since it's discussed in other comments. With about five minutes of my time, I found out: wrap_comments was introduced in 2019 [0]. There are bugs in the implementation (it breaks Markdown tables), so the option hasn't been marked as stable. Progress on the issue has been spotty. --no-merge-sources is not trivial to re-implement [1]. The author has already explained why the flag no longer works -- Cargo integrated the command, but not all of the flags. This commit [2] explains why this functionality was removed in the first place. Rust is open source, so the author of this blog post could improve the state of the software they care about by championing these issues. The --no-merge-sources error message even encourages you to open an issue, presumably so that the authors of Cargo can gauge the importance of certain flags/features. You could even do something much simpler, like adding a comment to the related issues mentioning that you ran into these rough edges and that it made your life a little worse, or with a workaround that you found. Alternatively, you can continue to write about how much free software sucks. [0]: https://github.com/rust-lang/rustfmt/issues/3347 https://github.com/rust-lang/rustfmt/issues/3347 [1]: https://github.com/rust-lang/cargo/pull/10344 https://github.com/rust-lang/cargo/pull/10344 [2]: https://github.com/rust-lang/cargo/commit/3842d8e6f20067f716c99ba39f4d9f2c8abe84f2 https://github.com/rust-lang/cargo/commit/3842d8e6f20067f716...

flimsypremise 3y ago
5 years to get a wrap_comments feature stable? I sometime wonder if people read the things they write?
- haileys 3y ago
  I mean... check out the issue tracker for any project, open source or commercial. It's just how it goes when things aren't a priority. Happens all the time.
- shepherdjerred 3y ago
  The conversation was about why the feature wasn't stable. I have no idea how the Rust project organizes itself, but my guess is that this simply isn't a high enough priority for them, which would explain why it hasn't been made stable. Large backlogs with stale are a common problem that software projects have.

LoganDark 3y ago

I feel the same way about Rust unstable features. Either you can only use features that are "stabilized"—guaranteed to never change—or you can throw all guarantees out the window, and use the unstable, experimental version of the toolchain. This would be fine if "unstable" features were actually experimental messes, but all sorts of completely-benign utility functions are "unstable". You have to throw out all guarantees for your entire toolchain just to use, say, `Result::into_ok`, which was introduced in 2019, but is still unstable due to being "newly added". At best, this is misleading, at worst, this greatly compromises the developer experience, especially when writing libraries which need to work on stable or else nobody will install them. Even for application projects, I don't want to use unstable features, because it's extraordinarily stupid to make the entire project nightly-only just because I want to use a two-line utility function, and I'm petty that way. Sure, I'll use unstable for things like bare-metal programming that deserve to be unstable, but if I'm writing regular application code and the perfect utility function is "unstable", I'm not going to lock myself into nightly just for that.

shepherdjerred 3y ago
> but is still unstable due to being "newly added". Where did you get this from? The tracking issue says nothing of the sort: https://github.com/rust-lang/rust/issues/61695 https://github.com/rust-lang/rust/issues/61695
- Arnavion 3y ago
  Right, it's nothing to do with it being "newly added". That issue had been filed by its OP as a feature request. It then got repurposed into a tracking issue for the feature, but it's not following the standard tracking issue template that lists any blockers, stabilization steps, etc. (Compare to https://github.com/rust-lang/rust/issues/119364 https://github.com/rust-lang/rust/issues/119364 that happens to be the newest "Tracking issue" atm.) Also since the OP didn't intend for it to be the tracking issue, it's possible they're not intending to do the rest of the bureaucracy to get it stabilized either, which is why it's stalled.
  - 3y ago

jbirer 3y ago

Rust is a great language but the developers suffer really badly from Reddit Intellectual syndrome. If they put some people with social skills at the forefront of relations with users it would definitely get more adoption.

local_crmdgeon 3y ago
Rust and TypeScript came onto the scene at about the same time. Microsoft manages TS more or less, Redditeurs manage Rust. Fun to see which is thriving and which is still niche!
deleted 3y ago
[deleted]

corytheboyd 3y ago

It’s a hard job that requires a lot of learning, failing, adapting, and growing. It’s frustrating, but getting good can only be done through endless grind. There are no cheat codes. After encountering and overcoming the roadblocks mentioned in the article, you grow keen to that class of problem, and next time, more quickly figure it out and move on. An apprentice woodworker is going to fuck up a cut and have to spend hours rebuilding. An aspiring musician is going to pour hours into mediocre music that nobody listens to. A new software engineer is going to get lost in the sea of complexity built on top of the rapid growth and death of fads and doctrines and tools (good and bad) that is decades deep. It’s fucking hard. I do think the pay reflects that, though perhaps is a biiiiit inflated. Regardless, shit ain’t easy. That being said, people generally quite enjoy sharing their knowledge, and helping the next generation of software people ramp up and kick ass, so there may be hope yet :)

starkparker 3y ago

I empathize with a lot of this. With experience and knowledge it's easy to recognize why and how these things happen, to point them out, and to call the author wrong. But I also remember being new to tools and not understanding how arbitrary they seem to be, in that they can understand what I want to do with uncanny precision but simultaneously refuse to do it. Things like exiting vim are the gold standard of this.[1] But: > Either support the feature, guide the user toward a better solution, or do nothing. The first two examples _explicitly_ guide the user toward better solutions. That's much more than many tools do. If the Python repl behavior isn't "guide the user toward a better solution" in both letter and spirit, I'd love to know why. There are much lower-hanging fruit than these examples, which makes a good point harder to agree with. 1: One of the first-page Google results for me on quitting vim is somehow this HN comment thread from 2017, in which the Python repl behavior catches strays with almost identical arguments as this article. https://news.ycombinator.com/item?id=14403297 https://news.ycombinator.com/item?id=14403297

Frummy 3y ago

>Exiting Python In early versions of COBOL exit was frequently used to go out of loops and out of sections and so on. Maybe a message is nice for someone still trying that while learning modern stuff, but I admit it’s farfetched/unlikely.

devilirium 3y ago

Change what you want and can.

prepend 3y ago

> But it does neither. It acknowledges your intent and refuses it. It’s saying “I know exactly what you want to do, but you’re doing it wrong. Do it right next time.” Programming languages follow rules and programmers should follow the rules. Just because mistake is common doesn’t mean the language should incorporate it into its functioning. That makes inconsistent behavior and is a pain in the long run because instead of learning and following logic, programmers have to guess what’s a common enough error that the language compensates. And over time the language drifts and is hard to work with. It seems easier to me to just suck it up and learn the right way to do things in a language.

williamtrask 3y ago
> “Just because mistake is common” A good example of why having a language that is squishy to common errors is valuable. I still understood your point even though it’s grammar wouldn’t compile.
- prepend 3y ago
  Humans aren’t programming languages. So programming languages don’t need to do everything humans do. It’s ok for things to be different. It’s cool that I understood what you meant when you said “it’s grammar wouldn’t compile” but I would definitely expect a compiler to barf unless you entered “its grammar.”
  - shpx 3y ago
    Programmers just haven't been able to make computers as good at language as humans are at language because they're not good enough at their jobs. There's no inherent reason that programming language statements need to perfectly follow regular grammars and have exactly defined vocabularies (functions) that compile to ASTs, etc. that's just the highest level of language technology we've invented. It has essentially no error recovery mechanisms because it's hard/tedious and error is hard to model using logic. Being frustrated that this is the case is expressing an underserved need in the market. You're aware of the limitations and have grown to be okay with them because otherwise you'd probably hate programming, but that doesn't mean we should all always be okay with them forever.

IshKebab 3y ago

This rant is spot on and it's disappointing (but not surprising) that there are so many commenters here that don't get it. Honestly a few years ago I'm not sure I would have got it. It definitely seems to be specific developers/communities that suffer from this "UX doesn't exist" sort of attitude. I have also run into Rustfmt issues when trying to format single files (necessary for Phabricator's arc lint) and they have an unreleased "version 2" which we dutifully used from source... for 5 years. It turns out their plan is to never actually release this. Python also seems to fuck over its users quite a bit. Two examples: 1. Setuptools has broken editable installs so that static tooling (IDEs, linters, type checkers etc.) can't work with editable installs. Because who would want to edit Python code with an IDE, amiright? Facepalm. 2. On Windows there is no python3.exe. Say goodbye to portable instructions/scripts. Why you ask? Well there's some obscure situation if you have multiple Python installs in your PATH and by some miracle that hasn't totally trashed your system already (relevant XKCD) that it would trash your system slightly more. So we won't ever fix that. And please don't point out that if you install Python from the Microsoft store it does install python3.exe.

sevagh 3y ago
>This rant is spot on and it's disappointing (but not surprising) that there are so many commenters here that don't get it. Honestly a few years ago I'm not sure I would have got it. Nailed it. A few years ago, I was deep enough in the zeitgeist of Rust (or whatever project) that I would maybe even be offended by a blog post like this; bro, do you think you're better than Rust? Keep up like the rest of us! After years of doing actual things (and not meta-learning), when there's something that makes no sense that ruins my day, I hate it.

bvisness 3y ago

All this time after writing this article, I’m now realizing a better way to sum up the issue: It’s like when you ask “can I go to the bathroom” and the teacher says “I dunno, CAN you?”

lacrimacida 3y ago
Your rant is very valid by the way. I didn’t have these particular problems but you captured the essence of similar experiences I’ve had with other tools. Just the thougt of tinkering with something im not familiar gives me the goosebumps, maybe a little nausea, shortness of breath. Maybe it’s some form of PTSD gradually accumulated over the years. In the end it’s no big deal if you don’t expect things to work logically and things to work from the first try.
- ryandrake 3y ago
  I think it's a totally valid rant too. We get so used to our tools laughing at us saying "Ha ha ha! You didn't say the magic word!" And then a few searches or manual lookups later, you learn the magic word and use it, the tools say "Ha ha ha! We've deprecated that function!" And slowly through our careers, we just start accepting it as an inevitable fact of programming.

deleted 3y ago

[deleted]

stavros 3y ago

https://archive.is/AYTEM https://archive.is/AYTEM

deleted 3y ago

[deleted]

avalys 3y ago

I have a similar pet peeve in software, what I refer to as ‘Don’t Suck’ Buttons. A ‘Don’t Suck’ Button is a setting, turned off by default and usually hidden in a corner of the UI or configuration file, which fixes a common issue that new users experience, and/or turns on the behavior that everyone wants from the product in the first place. The best examples of ‘Don’t Suck’ Buttons involve settings with no obvious disadvantage to turning them on. They’re just turned off by default and the software makes you go through extra effort to tell it “No, I don’t want you to suck.” Usually these originated from some kind of automation, new protocol or new feature that started out as experimental and was locked behind a setting, then became universally relied upon but somehow never enabled by default. I used to have a list of examples of these. One that comes to mind from my TV: “Allow HDMI Devices to Control this TV”. If you have an Apple TV or something, it won’t change the volume or be able to turn the TV on or off automatically unless you know enough to go into settings and tell the TV “Don’t Suck”.

amluto 3y ago
> “Allow HDMI Devices to Control this TV” It would IMO be nice to have a default-off option to disable CEC on a specific port. Or to disable certain CEC features.
- lucasban 3y ago
  For example: If I leave my TV set to the input that my PS5 is on, turning the TV on will turn on the PS5. Because the PS5 takes a few seconds to turn on, if I try to switch to another app or input, the PS5 will switch the input back when it finishes waking up. Ideally, I’d allow CEC for all functions except turning the PS5 on. If I want it on, I’ll use the controller or media remote.
- thedanbob 3y ago
  I had to disable CEC because my Chromecast would randomly turn on the TV in the middle of the night. Disabling on a single port would be great.
johnfn 3y ago
One common reason these exist is because a lot of people got used to the state where the "Dont Suck" button didn't exist, and for those users changing their workflow would be even more annoying. I do agree it's not a great state of affairs, though.

thrwggrdxvgf 3y ago

[flagged]

invalidator 3y ago

My personal peeve: $ git log directory --stat fatal: option '--stat' must come before non-option arguments Come on, Git, you know what I want. Just do it without making me repeatedly edit the middle of the command.

__s 3y ago

If you think these are examples of why programming is hard do I have news for you Python's error message is a compromise, they could've just printed the unknown variable error Rust has unstable features to prevent tooling running into issues like ci failing everytime there's a minor version update

naikrovek 3y ago

I agree with the authors conclusion that we make this stuff hard on ourselves. No one hates software developers more than other software developers, and no one understands usability less than a software developer. This is one of those things I thought would get better over 30 years but has just continually gotten worse.

interstice 3y ago

I have run into this with JavaScript, Shopify and numerous applications. Usually it’s because an internal ideology or future plan js incompatible with a currently working featured. It’s mildly annoying when there is no recommended replacement. It’s very annoying when there are a bunch of suggested alternatives that don’t work. The worst is when the attitude is “you shouldn’t be trying to do it this way in the first place” when there really is no good alternative.

laidoffamazon 3y ago

I like these examples, particularly in the Rust ecosystem because they mirror my frustration with Rust exactly - code examples fail in embedded documentation because of nightly channel differences, libraries that assume dependency on one stdlib or another, it's a massive cognitive load on top of the already obvious load of the borrow checker.

deleted 3y ago

[deleted]

LtWorf 3y ago

What a bad article! He wants a function to work as a keyword! He wants comments word wrapped by default, when this would break comments that contain stuff like packet fields schemes. Terrible ideas, and he complains they aren't the default. Well that's because they aren't good ideas and he hasn't thought about it long enough to figure it out.

deleted 3y ago

[deleted]

zubairq 3y ago

Haha, made me laugh out loud at how true this statement feels, even though it is probably not true: "If you don't enjoy programming, don't worry, it is not your fault. Thousands of people around the world work hard day and night to make programming as miserable for you as possible."

stgr_codes 3y ago

This is literally Typescript vibes all around... Awful dev experience, it's a fucking joke and people seem to like it...

octacat 3y ago

Yes, and rm knows that I want rm -rf. But there are rules...

octacat 3y ago

The example with experimental features is soo weird. It is like the author knows why experimental features exist but trying to play confused to fit the narrative. OK, nighty builds. So, some features could be coded, but haven't been tested for a long enough time to say "this feature is rock solid and the behaviour is good for all combinations of code". In the formatter, we probably would not wanna change the behaviour of a flag once it goes stable (and in the formatter there are always several ways to do anything, because it is just how code is). So, there are more or less two options when adding new features: only merge a feature branch when you are 100% happy (that could make releasing hard) or have a feature behind a flag and document it is an experimental. In the real world - having feature behind a flag is good. For some reason people assume that open source projects have a huge team, and all their time is free. So, adding a new feature to a formatter is "easy and trivial" (and make that feature stable is "trivial" too).

deleted 3y ago

[deleted]

garaetjjte 3y ago

I guess the author loves PHP?

kazinator 3y ago

> There are two reasonable things that Python could do here: There is a third one. Since exit is a binding to a function, it should print that function. >>> print <built-in function print> >>> exit Use exit() or Ctrl-D (i.e. EOF) to exit What? I expect <built-in function exit>

deterministic 3y ago

If you deprecate an API used by other developers, then you should not work on API’s used by other developers. It’s that simple. Yes it might save a bit of time for you, but it also potentially waste orders of magnitude more time for other developers. Developers who will positively hate you for forcing them to fix something that is not a problem for them! Instead keep the old API working and make the path to upgrade easy and smooth. Your API users will love you for it.