1. 7

  2. 1

    This article touches on a problem, that I don’t know good solution to. One that is especially important for tools related to security. Trying to put it in words:

    Yesterday’s defaults may not be good today’s defaults. (In case of security, this may be old algorithms becoming defeated, and new ones being invented. In other cases, it may be because the tool and its usage patterns are now better understood than before.) To make a tool more user friendly (including safer to use), the tool’s defaults should be changed to new ones. But there are scripts using the old defaults out there in the wild (a.k.a. backwards compatibility). Is there no way out, other than keeping the old flags, and watching the tool become an ancient artifact? (see dd, etc.)

    Now that I think of it, it feels like this is probably the same problem as API versioning. If yes, could some known approaches to API versioning be reused for command-line tools?

    Some more thoughts that come to my mind:

    • git officially has the separation between “plumbing” and “porcelain” tools, where scripts should officially only use the “plumbing” tools (IIRC), theoretically introducing a boundary: “plumbing” tools are low level, can have ugly API (not exposed to regular users), keeping strong backwards-compatibility for scripting; “porcelain” ones are high level, for users, and thus in theory the API (flags) can change, striving for user-friendliness… however I still find git definitely far from user-friendly; does it mean this approach didn’t/can’t work?
    • nix (of NixOS) is a new command (old one was called nix-env), and as such, can try and introduce a new elegant API, after the community learnt a lot using the old, organically evolved/accumulated API. This is kinda a “new API version”; is there some way we could do this for other tools? Or is this doomed to failure in most cases because people are too used to “muscle memory”? Could there be some way to overcome this hindrance? How to even introduce/name the new APIs and deprecate old ones? Call the tools grep2 or what? (Hm, makes me think of python2 & python3, maybe it shows it can work?) In other words: in case of nix, is this a once-in-a-lifetime chance at introducing a new API, or is there some way how this could be repeated in future, once nix itself starts to become “old and grumpy”?

    Are we doomed to struggling with troublesome command-line interfaces like those of gpg, git, dd, etc.? Now that I think of it, Oil Shell seems to be at least one ambitious experiment at breaking the status quo in case of bash. Maybe that will tell us something more about the problem space when it gets completed?

    Do you know of any command-line tool, where a new, redesigned interface was introduced successfulky, more than once?

    1. 2

      This touches on implicit vs explicit behaviors. Everybody loves implicit behaviors. Especially in their GitHub marketing readme. See how easy it is to do this thing! But then it becomes harder to revise later. If you make the user tell you what they want, every time, there’s less misunderstanding. But then they write their own scripts, and then you’re even more locked into supporting old options.

      1. 1

        Very interesting observation. Just to be clear, in my eyes it is still more of a related thing (as you wrote, “touches on”), than an answer to my questions. Also, from what you write, it sounds to me as if implicit behaviors were kinda “bad”; personally, from a user perspective (though not necessarily script-writer one - so, maybe, plumbing vs. porcelain again?), when the implicit (default) behaviors are good, I would keep arguing it is actually a “good” UI - by which I mean the kind where you don’t even realize it’s there (as in good GUI - the best ones are those where you don’t even think there’s any UI - it “just works”, “just does what I thought it would”). Anecdotally, this reminds me of a wiki-like website I built for a group of friends for collecting songs lyrics once; I put quite some effort in it, and then heard one friend call it “just a simple website” when talking to another. I felt offended at first (hey, I put so much effort in it, and you call it simple!); it took me a while to realize this was the ultimate praise, as it meant they felt it was simple to use.