4 ms·

it's the same mentality that brought us the git design - the easiest, least typing options are rarely, if ever the thing you want to do. Instead, these invocat

it's the same mentality that brought us the git design - the easiest, least typing options are rarely, if ever the thing you want to do. Instead, these invocations give cryptic messages, throw errors, or sometimes, even break things. The most common and helpful things are hidden deep behind multiple flags and command line arguments in manuals that read like dictionaries more than guides. I'm always at a complete loss as to how such decisions are made. For instance, "git branch -vv" is the useful output you would like to see, every time, that should be "git branch". Why not make the current output, "git branch -qq"? Is a humane interface too much to ask for? Apparently... I know people defend this stuff, but as a senior engineer in programming pits for 30 years, they're wrong. Needless mistakes and confusions are the norm. We can do better. We need to stop conflating elitism with fucked up design.

godelski 2y ago
> Why not make the current output, "git branch -qq"? Is a humane interface too much to ask for? Apparently... Yes, it is too much. You have the wrong mentality, and I hope this can help make your life easier. Programs are made so that the simplest option is the base option. This is because there is a high expectation that things will be scripted AND understanding that there is a wide breadth of user preference. There's an important rule DON'T TRY TO MAKE A ONE SIZE FITS ALL PROGRAM Customization is at the root of everything. We have aliases that solve most of the problems and small functions for everything else. You default to an non-noisy output, showing only __essentials__ and nothing more unless asked. Similarly, you do no filtering other than hidden files. This way, everyone can get what they want. Btw, this is why so many people are upset with default options on things like fdfind and ripgrep. For your problem with git, there are 2 solutions you have. # alias git branch using git git config --global alias.branch 'branch -vv' # write a simple function and add to .bashrc or .zshrc or .*rc git() { case "$1" in branch) shift command git branch -vv "$@" ;; *) command git "$@" ;; esac } > We need to stop conflating elitism with fucked up design. The design isn't fucked up, it is that you don't understand the model. This is okay. You aren't going to learn it unless you read docs or books on linux. If you learn the normal way, by usage, then it is really confusing at first. But there is a method to the madness. Things will start making more sense if you understand the reason for the design choices. (In a sibling comment I wrote the abstraction to command patterns that makes the gp's confusion odd. Because systemd follows the standard) Side note: if you try to design something that works for everyone or works for the average person, you end up designing something that is BAD for most people. This is because people's preference is not uniformly distributed, meaning the average person is not representative of any person in the distribution. This is because anything that is normally distributed has its density along the shell while a uniform distribution has a uniform density all throughout it.
- nativeit 2y ago
  Fully this. For all its foibles, Linux was built to never presume too much, and its users tend to be power users who will almost certainly have dotfiles to tune their systems to their needs. In the context of making choices that will necessarily be universal, I admire how thoughtfully most standard Linux packages have been designed to never interfere with the users’ intentions.
  - godelski 2y ago
    And to all the linux noobies[0], you'll be a hell of a lot more efficient if you learn the philosophy of the design early. It will make it so that you can learn a new command and instantly know how to use several options. It will dramatically reduce the number of things you have to learn. I also HIGHLY suggest learning a bit of bash scripting. Take a look at the manual https://www.gnu.org/software/bash/manual/html_node/index.html and bookmark "Bash Pitfalls" https://mywiki.wooledge.org/BashPitfalls Live in the terminal as much as you can. It is harder at first, but you will get huge boosts in productivity quicker than you would know it (easily <2 weeks). It sucks doing things "the hard way" but sometimes that comes with extra lessons. The thing is, those extra lessons are the real value. [0] no matter how many years you've been using it there's no shame in being a noobie
  - kristopolous 2y ago
    Making things customizable doesn't mean the defaults should be useless. zsh, tmux, emacs, vim and bash, out of the box, for instance, have both pretty nice defaults and are highly customizable. I know it's hard to make things like this but let's do it anyway.
    - noumuon 2y ago
      Sounds like entitlement. Ever consider there are more users than yourself?
- kristopolous 2y ago
  You're fundamentally misunderstanding things. If every person has the same point of confusion than they are not the problem, it's the thing they're confused by. There's better ways to do things and calling people naive for suggesting the obvious is the problem. And about your side note: no. For example, when people checkout a branch, they want to track the remote branch 99.9% of the time. It should be the default. The default journalctl should show where things have failed, that's why people are invoking it. Also there's plenty of counterexamples that do these things. "ping host" genuinely pings the host. "ssh host" genuinely ssh's into the host. You don't need to specify say, the encryption algorithm, that you want a shell, use say, "--resolve=dns" to specify the hostname resolution... It has sensible defaults that do what most people intend. Under the model you advocate for "ssh host" would simply open up a random socket connection and then you'd have to manually attach a virtual terminal to it and request the invocation of shell separately, stacking each piece on top of the other, before you log in. This design could be defended in the same way: Some people do port mapping, tunneling, SOCKS proxies, there's too many use cases! How can we assume the user wants a shell? Answer: because they do. Most things are reasonable like certbot, apt, tune2fs, mkfs, awk, cut, paste, grep, sort, so many reasonable things. Even emacs is reasonable. But systemd and git are not and the users are not the problems. Choices were made to be hostile to usability and they continue to be defended by being hostile to usability. Things like lex and yacc are inherently complicated and there's nothing to do there. Other things are intentionally complicated. Those can be fixed.
deleted 2y ago
[deleted]

godelski 2y ago

> Why not make the current output, "git branch -qq"? Is a humane interface too much to ask for? Apparently... Yes, it is too much. You have the wrong mentality, and I hope this can help make your life easier. Programs are made so that the simplest option is the base option. This is because there is a high expectation that things will be scripted AND understanding that there is a wide breadth of user preference. There's an important rule DON'T TRY TO MAKE A ONE SIZE FITS ALL PROGRAM Customization is at the root of everything. We have aliases that solve most of the problems and small functions for everything else. You default to an non-noisy output, showing only __essentials__ and nothing more unless asked. Similarly, you do no filtering other than hidden files. This way, everyone can get what they want. Btw, this is why so many people are upset with default options on things like fdfind and ripgrep. For your problem with git, there are 2 solutions you have. # alias git branch using git git config --global alias.branch 'branch -vv' # write a simple function and add to .bashrc or .zshrc or .*rc git() { case "$1" in branch) shift command git branch -vv "$@" ;; *) command git "$@" ;; esac } > We need to stop conflating elitism with fucked up design. The design isn't fucked up, it is that you don't understand the model. This is okay. You aren't going to learn it unless you read docs or books on linux. If you learn the normal way, by usage, then it is really confusing at first. But there is a method to the madness. Things will start making more sense if you understand the reason for the design choices. (In a sibling comment I wrote the abstraction to command patterns that makes the gp's confusion odd. Because systemd follows the standard) Side note: if you try to design something that works for everyone or works for the average person, you end up designing something that is BAD for most people. This is because people's preference is not uniformly distributed, meaning the average person is not representative of any person in the distribution. This is because anything that is normally distributed has its density along the shell while a uniform distribution has a uniform density all throughout it.

nativeit 2y ago
Fully this. For all its foibles, Linux was built to never presume too much, and its users tend to be power users who will almost certainly have dotfiles to tune their systems to their needs. In the context of making choices that will necessarily be universal, I admire how thoughtfully most standard Linux packages have been designed to never interfere with the users’ intentions.
- godelski 2y ago
  And to all the linux noobies[0], you'll be a hell of a lot more efficient if you learn the philosophy of the design early. It will make it so that you can learn a new command and instantly know how to use several options. It will dramatically reduce the number of things you have to learn. I also HIGHLY suggest learning a bit of bash scripting. Take a look at the manual https://www.gnu.org/software/bash/manual/html_node/index.html and bookmark "Bash Pitfalls" https://mywiki.wooledge.org/BashPitfalls Live in the terminal as much as you can. It is harder at first, but you will get huge boosts in productivity quicker than you would know it (easily <2 weeks). It sucks doing things "the hard way" but sometimes that comes with extra lessons. The thing is, those extra lessons are the real value. [0] no matter how many years you've been using it there's no shame in being a noobie
- kristopolous 2y ago
  Making things customizable doesn't mean the defaults should be useless. zsh, tmux, emacs, vim and bash, out of the box, for instance, have both pretty nice defaults and are highly customizable. I know it's hard to make things like this but let's do it anyway.
  - noumuon 2y ago
    Sounds like entitlement. Ever consider there are more users than yourself?
kristopolous 2y ago
You're fundamentally misunderstanding things. If every person has the same point of confusion than they are not the problem, it's the thing they're confused by. There's better ways to do things and calling people naive for suggesting the obvious is the problem. And about your side note: no. For example, when people checkout a branch, they want to track the remote branch 99.9% of the time. It should be the default. The default journalctl should show where things have failed, that's why people are invoking it. Also there's plenty of counterexamples that do these things. "ping host" genuinely pings the host. "ssh host" genuinely ssh's into the host. You don't need to specify say, the encryption algorithm, that you want a shell, use say, "--resolve=dns" to specify the hostname resolution... It has sensible defaults that do what most people intend. Under the model you advocate for "ssh host" would simply open up a random socket connection and then you'd have to manually attach a virtual terminal to it and request the invocation of shell separately, stacking each piece on top of the other, before you log in. This design could be defended in the same way: Some people do port mapping, tunneling, SOCKS proxies, there's too many use cases! How can we assume the user wants a shell? Answer: because they do. Most things are reasonable like certbot, apt, tune2fs, mkfs, awk, cut, paste, grep, sort, so many reasonable things. Even emacs is reasonable. But systemd and git are not and the users are not the problems. Choices were made to be hostile to usability and they continue to be defended by being hostile to usability. Things like lex and yacc are inherently complicated and there's nothing to do there. Other things are intentionally complicated. Those can be fixed.

deleted 2y ago

[deleted]