8 ms·

I'm hardly afraid but I just think it's poor ergonomics. Same as the move from xset m 0 0 to xinput --set-prop 'pointer:Logitech USB Receiver' 'libin

• skohan 5y ago
  What's wrong with camelCase? It's easier to type than snake
  • thrwyoilarticle 5y ago
    There's a tendency away from snake_case and towards kebab-case in things you interact with via CLI. Even moreso towards nocase. Programs like Powershell eschew ease of use in CLI for readability in scripts.
    • pvaldes 5y ago
      Snake_case is problematic for including filenames in TeX also. This is a big no for me, even if I find it more readable than the other.
    • JadeNB 5y ago
      > Even moreso towards nocase. Nocase (did I break a rule by writing it that way?) seems great when you're enmeshed in the domain and you can see the implicit separators, but then someone looks at your naming from the outside and you're guaranteed to have an 'expertsexchange' in there somewhere.
      • thrwyoilarticle 5y ago
        oh, fsck
    • rk06 5y ago
      Powershell is case-insensitive, so camelCase is only a writing preference
      • thrwyoilarticle 5y ago
        It's still verbose in places
  • chrismorgan 5y ago
    camelCase is objectively harder to read than snake_case or kebab-case, though familiarity can mitigate that.
    • skohan 5y ago
      I'd argue it's at most a tiny bit harder to read, and a lot easier to type. On balance I'd rather avoid making a pinky key one of the keys I have to use the most.
      • daneel_w 5y ago
        "On balance I'd rather avoid making a pinky key one of the keys I have to use the most." And you use something else than your pinky finger for the shift key specifically when typing capitalized letters for camelCase?
        • skohan 5y ago
          At least it's where they sit naturally on the keyboard. And the shift key is wider specifically so you don't have to be accurate with your pinky when you're pressing it. The underscore is one of the least ergonomic keys there is. And you need both pinkies to do it
          • daneel_w 5y ago
            I might be misunderstanding. On all layouts I'm familiar with the underscore key is directly next to one of the shift keys, or left of backspace. Neither layout requires the Vulcan death grip. Shift should always be under your pinky fingers to avoid contortions.
            • skohan 5y ago
              On the US layout it is next to the zero key on the top row.
      • frenchyatwork 5y ago
• nomorecommas 5y ago
  Long option names are more descriptive, more easily distinguished, and easier to remember. Your shell should be intelligent enough to provide tab completion for option names, assuming it is configured to.
  • Angostura 5y ago
    > Long option names are ... easier to remember ... Your shell should be intelligent enough to provide tab completion They are so easy to remember that you need to configure your shell to remember them for you?
    • deleted 5y ago
      [deleted]
  • Jiro 5y ago
    Long option names are more difficult to remember because a long option name can be spelled multiple ways and it is difficult to remember which spelling is correct.
  • forgotmypw17 5y ago
    >Your shell should be intelligent enough to provide tab completion for option names, assuming it is configured to. Wait, are you saying that I need to change my shell or config to make up for another tool's poor design? No, thanks.
  • kaba0 5y ago
    IMO, powershell got it right. Yeah, it’s syntax is strange, but it has standard flag usage with proper autocomplete, and you can shorten any flag the way you want (eg. fuzzy match) if it is unambiguous.
• martin-t 5y ago
  I find this attitude misguided. More descriptive names are more ergonomic for things you only use rarely but they need to be combined with much better autocompletion than most shells provide by default.
  • foxfluff 5y ago
    You state that as if that were objective.. but that's not my subjective experience at all. Somehow I have a hard time remembering these long names, (is it --conf or --config or --config-file or --config-path? -c would've done it for me. --set or --set-prop or --set-property or --prop or --property?), and I need to look them up in a man page anyway, and I make more typos typing them, and shell completion rarely works well if at all. I also find it harder to read and edit long lines that wrap. Somehow these short letters stick much better for me, and the effort for finding them in the manual is the same, although in case of extra complexity as with xinput, it's even worse with the long names. I don't use either command often, but it's hard to forget xset m. The only thing I remember about xinput is that it's a horribly long lithany of things which I need to look up every time, and the syntax still feels weird.
    • me_me_me 5y ago
      the most used options for properly written tools have both short single char option like -c and long-form version --config if you need verbose self-describing option. If you are using cli tools of github written by a random person, then no wonder you will see non-standard approaches to UX.
      • sidpatil 5y ago
        PowerShell takes an interesting approach in that it accepts any truncated variant of a long-form flag as a short form, provided it isn't ambiguous (i.e. if the interpreter can't decide which long-form flag to expand a short-form flag to.) For example, if a command features a "-ConfigFile" flag, valid short-form variants include "-C", "-Co", "-Con", "-Conf", and so on. But if the command featured an additional flag "-ConfigURL" for example, the aforementioned short-form flags would be ambiguous.
• Dudeman112 5y ago
  I could infer a lot about the second and what those params mean and what they do. The first one is some magical incantation.
  • foxfluff 5y ago
    Sure. One could also make "move-down-one-line" be the incantation to move the cursor down a line in vi, but I prefer j. Ergonomics isn't all about making everything self-descriptive for someone seeing the thing for the first time. It's about making things comfortable to actually use. If it's so long and complicated that you can't even remember how to do it, it's not very comfortable to use. Even if I could remember, xset m 0 0 is still far more comfortable. And fwiw you still don't know what 0, 1 in accel profile do; you need to look that up or take a wild guess, and if you want to use that command, you'll also have to know how to look up the device because chances are yours is not the same as mine. So it's not any less magical in the end, just more verbose. The "cool" thing about the xinput command is that you don't even find accel profile in the man page. You gotta look elsewhere if you want to understand what it is and what it does and what the parameters are. xset m? Yes, that is documented in the man page.
    • Gigachad 5y ago
      It should be based on frequency of usage. I can tell you that moving down a line in vim is a little more common than toggling the mouse acceleration. I would never even type such a command. I would just copy paste it once.
      • foxfluff 5y ago
        Yeah well, given that mouse acceleration tends to be on by default, I need to turn it off every time I'm on a fresh install or computer I haven't used before. The last time I needed that was yesterday. I don't want to waste time searching for a command to copy-paste when it could just be made short, simple, memorable and ergonomic. I could type xset m 0 0 faster than I could open a browser and ask google how to disable acceleration with libinput. And again: you can't just copy-paste the xinput command unless you're lucky enough that it matches your device. On my new computer, the device has a different name than on my old laptop even though it's the same damn mouse.
• zibzab 5y ago
  I've a feeling you will hate powershell
  • akersten 5y ago
    Needlessly long parameter/command names and the bizarre insistence on capital letters are the #1 and #2 reasons I detest PowerShell. Like GP, I resent that Linux tools are moving in that direction.
• formerly_proven 5y ago
  Cue nmcli (CLI for Gnome's NetworkManager) which uses UUIDs for everything and (at least a while ago) did not accept partial-but-unique UUIDs. Basically goes "nmcli connection up 5095665a-d82c-4ae6-8964-283623387941".
  • gertlex 5y ago
    Weird, I haven't had to do this. Most(/all?) connections have nice names you can see with `nmcli c`... and so I can do `nmcli c up id DroidNet` and that's pretty dang nice. Pretty sure this worked with Ubuntu 14.04 (though, nmcli has gotten much more featureful since then) (The ability to shorthand connection->c and similar is great, too; obviously not unique to nmcli)
  • apricot 5y ago
    By this point, I'm pretty sure there are people at gnome who compete to see who will make the stupidest suggestion that gets put in production.
    • MonkeyClub 5y ago
      It's a Gnomespiracy to determine whether worse is actually better.
      • 8bitsrule 5y ago
        Fits right in with COP26. (Could Of Punted?)
  • prionassembly 5y ago
    apt-get install nmtui # it's better
    • O_H_E 5y ago
      nmtui is a life saver tbh
• apricot 5y ago
  The problem is we're optimizing for "easy to learn" rather than "easy to use".
  • jjoonathan 5y ago
    In a world of broken promises and tool churn, minimizing tooling investment isn't laziness, it's a defense mechanism. This is a lesson I had to learn the hard way, multiple times.
    • forgotmypw17 5y ago
      I've learned this lesson too, and I now avoid using any tools that have broken backwards compatibility in the past 20 years.
  • foxfluff 5y ago
    That may be a part of the problem but honestly I don't feel like all these new crazy interfaces are easy to learn either. I mean how do you come up with the lithany xinput calls for? You need to understand the syntax for specifying a device. You need to know that you're to set a libinput property, and you need to know the name of that property, and it's not documented in xinput man page, and of course you need to know the values to pass which again are not documented in xinput man page. You can play with --list-props and then take your search elsewhere because it is completely opaque and doesn't explain what the properties actually do. I suspect the number of people who figured all that out without having to find it by googling / arch wiki / whatever is very very low. Now I'm not gonna say xset is the easiest interface to figure out, but the syntax for setting mouse acceleration is right there in the synopsis, and if you search down the man page, you'll learn a little more (and also if you just run xset without arguments, it'll tell you how to set mouse acceleration). It might not be the best designed tool but it's something I learned back in the day as a teenager just by looking at the man page. I think the real issue is that people nowadays are designing these interfaces to be consumed by interactive configuration tools, GUI apps, and desktop environments; they're more dynamic, more complex, more flexible, but not easier to figure out, not for you on the command line. The command line is just a last resort. Second class citizen if you will.
• Pxtl 5y ago
  imho, the fundamental problem is using space as a delimiter. Also, case-sensitivity is a disaster for ergonomics. If you had comma-delimiting like in an algol-derived language, you wouldn't need to quote things with spaces. edit: also, code is read more times than it is written, so optimizing for readability over brevity is generally a good move.
• ansible 5y ago
  Well, if you think that's bad, behold the recent trend in network interface names on Linux. We started out with 'eth0', 'eth1', etc. Which adapter was which could change when adding and removing a network card. That was bad, so that prompted the evolution. Now we have 'enp1s0', 'enp0s31f6', 'enp13s0' and many similar variations. These are supposedly more stable across device changes. As it turns out, it wasn't. But wait, there is more! Now we have the "predictable names" scheme that produces interface names that are even longer, and not even slightly easier to remember. Read about the whole sorry saga here: https://wiki.debian.org/NetworkInterfaceName https://wiki.debian.org/NetworkInterfaceName I do get that it is not an easy problem to solve, especially in the face of removable network interfaces (like USB Ethernet / WLAN). But surely this is not the best we can do.
  • nocman 5y ago
    Missed the 's', it's: https://wiki.debian.org/NetworkInterfaceNames https://wiki.debian.org/NetworkInterfaceNames
  • foxfluff 5y ago
    I was actually ranting about this on IRC last night (yeah now my laptop has two enp* interfaces and enx[MAC]).. One thing I like about OpenBSD is that buses are scanned and drivers probe in order and there's no race between drivers coming up. Unless your hardware is physically tampered with or broken, all interfaces come up with the same name across reboots. Linux isn't like that (even if you don't touch your hardware, interfaces could swap across reboots), so you need to do something about it. As is typical on Linux, the default is unergonomic and if you want something nice, you're on your own to make it so. If you already have userspace daemons responsible for device insertion and naming, it really wouldn't have been so hard for it to e.g. automatically add a config file / database entry for each interface the first time is seen. So the devices that came up as eth0 and eth1 are still eth0 and eth1 on the next boot; if I unplug eth0 and add a new card, the new one would be eth2 because eth0 is still reserved for the first card I had.
    • ReleaseCandidat 5y ago
      > add a config file / database entry for each interface the first time is seen. Ubuntu did that with their persistent-net.rules udev rule. That was a part of the PITA of the old naming.
• throw10920 5y ago
  These changes are meant to make it easier to read and understand command-line incantations (and to make them more explicit, which is always good), because the command-line paradigm, being text-based, imposes an unavoidable trade-off between ergonomics and understandability/ease-of-use. It sounds like you prefer ergonomics - although I wouldn't be surprised if most users would prefer ease-of-use. Of course, if one doesn't write a CLI to begin with, this trade-off doesn't exist - you can have your cake and eat it too.