[HN Gopher] You can't do that because I hate you
___________________________________________________________________
You can't do that because I hate you
Author : nivethan
Score : 84 points
Date : 2023-12-28 20:01 UTC (2 hours ago)
(HTM) web link (bvisness.me)
(TXT) w3m dump (bvisness.me)
| eurleif wrote:
| >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 wrote:
| 1 may be more persuasive but it's 2 that makes me wish someone
| a very bad day every time that message prints.
| mrblampo wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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/Refe...
| andrewaylett wrote:
| Except they didn't -- the result of a statement is turned
| into a string, and the string is printed. There are
| standard ways of turning objects into strings, and the
| `__repr__` function on the `exit` object returns that
| string. If you call that object then it raises an exception
| that triggers a REPL to cleanly quit.
|
| The code is here: https://github.com/python/cpython/blob/3.
| 12/Lib/_sitebuiltin...
| edflsafoiewq wrote:
| If it actually exited, you might incorrectly conclude that
| exit would work the same way in a script.
| imron wrote:
| > A world where that's the standard would be chaos.
|
| We saw this play it with web browsers in the late 90s early
| 'aughts where they'd do their best to render what they
| thought you meant if your html was wrong, and it was indeed
| chaos.
|
| Strict systems with strict inputs makes for a better overall
| ecosystem.
| dale_glass wrote:
| I'd have done both the hint and the actual result. Like this:
| >>> print <built-in function print> >>> exit
| <built-in function exit> Hint: Use exit() or Ctrl-D
| (i.e. EOF) to exit >>>
|
| This way, it does do the thing you literally asked for, but
| also does help a newbie out.
| ssgodderidge wrote:
| > does help a newbie out
|
| ... or a long-time dev that switches languages fairly often
| :)
| dmurray wrote:
| It should print the first to stdout and the second to stderr.
| That's completely consistent with how stdout and stderr are
| usually used.
|
| The regular Python REPL doesn't distinguish between stdout
| and stderr (perhaps it should!), but you can embed it in
| things like Jupyter notebooks that do.
| gruez wrote:
| > It should print the first to stdout and the second to
| stderr. That's completely consistent with how stdout and
| stderr are usually used.
|
| That makes sense from a unix tool perspective, but not from
| a python repl perspective. The repl's behavior is to print
| the result from the last executed statement. For the exit
| function, the __repr__ method was overwriten to print the
| message. That way when you type in "exit", the last value
| would be exit (the function), and the overwritten __repr__
| method causes the help message to be printed. There's no
| way to have it print to both without adding in some repl
| specific hacks. >>> exit Use
| exit() or Ctrl-Z plus Return to exit >>>
| exit.__repr__() 'Use exit() or Ctrl-Z plus Return
| to exit'
| dmurray wrote:
| How about def __repr__(self):
| import warnings warnings.warn("Use exit() or
| Ctrl-Z plus Return to exit") return
| super().repr()
| andy99 wrote:
| Vim iirc has a similar hint telling you to exit when you try
| something that should exit. I don't remember how it's
| triggered, ctrl-q maybe (edit, ctrl-c). I see the point, if you
| know what someone is trying to do, better to just do it, or
| ignore it, not give a condescending "nudge". Though personally
| the hint doesn't bother me.
| nneonneo wrote:
| Yeah, and it's also useful to teach newbies about the usual
| syntax for doing things rather than introducing special-case
| magic. It would be _weird_ to just quit after writing a bare
| "exit".
| valyagolev wrote:
| 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.
| zem wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| Hizonner wrote:
| Wait what? It would never occur to me to try to use a
| question mark as a command option at all. That's what "--
| help" is for. I'm actually surprised any program at all
| recognizes either form of the question mark.
|
| ... but don't get me started on people who think it's ok to
| use a single hyphen to start a multicharacter option, or
| don't let you put multiple single character options after the
| single hyphen...
| nneonneo wrote:
| Windows uses /? as the standard help flag, so maybe there
| are tools that are ported from that convention?
|
| -h/--help are all I ever see in macOS CLI tools, in any
| case.
| JohnFen wrote:
| > It would never occur to me to try to use a question mark
| as a command option at all. That's what "--help" is for.
|
| -? has been a common switch for decades. I've been
| implementing it (along with the synonyms -h, --help, etc.)
| in all of my programs since about the '90s.
| zem wrote:
| i agree about the help flags, but not about `exit`, given
| that `exit()` is implemented as a function and not a repl
| builtin. python functions do not get run unless called with
| `()` and it's not worth introducing that inconsistency in
| there.
| avg_dev wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| jgilias wrote:
| 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!
| ambicapter wrote:
| > "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 wrote:
| 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 wrote:
| other posts pointed out the issue, it breaks certain markdown
| formatted comments (mainly tables).
| v9v wrote:
| 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 wrote:
| 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 wrote:
| "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 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| >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.
| fifticon wrote:
| 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 wrote:
| 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.
| LeifCarrotson wrote:
| > I really really wonder who decided to implement that window
| in that maddening way??
|
| They implemented it in a test environment with either an
| emulated device pulling packages from the host, or pulling
| packages over a gigabit network from a local cache on their
| LAN, or on a high-speed fiber connection where it took far less
| than 5 minutes to retrieve the list.
| Guvante wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Writing this sort of rant in English is meta-hilarious.
| shepherdjerred wrote:
| 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
|
| [1]: https://github.com/rust-lang/cargo/pull/10344
|
| [2]: https://github.com/rust-
| lang/cargo/commit/3842d8e6f20067f716...
| flimsypremise wrote:
| 5 years to get a wrap_comments feature stable? I sometime
| wonder if people read the things they write?
| JohnFen wrote:
| > you can continue to write about how much free software sucks.
|
| I think that's unfair. He wasn't writing about how much free
| software sucks, he was writing about how some of the rust
| tooling sucks.
|
| Even in the larger context, everything he wrote applies just as
| readily to proprietary software. These sorts of issues are
| everywhere.
| LoganDark wrote:
| 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 wrote:
| > 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
| jbirer wrote:
| 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 wrote:
| 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!
| corytheboyd wrote:
| 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 sometimes. 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 :)
___________________________________________________________________
(page generated 2023-12-28 23:00 UTC)