3 ms·
That is true; and it is generally considered a failure of UI design, especially if these differences show up side-by-side in the same system. That graphical cod
by azernik 10y ago
That is true; and it is generally considered a failure of UI design, especially if these differences show up side-by-side in the same system. That graphical coding tools have these problems is in part my point - many hops up this chain, pavlov bemoaned the lack of GUI coding tools, and I pointed out whether a UI is good and whether it's text-based are orthogonal properties
As an example of how it's possible to make a consistent UI among diverse applications: both Android and iOS have had a lot of effort put in to make app developers converge on consistent idioms; early Android did not do this, and was widely panned for it in the UI design community. The way iOS did this from the start, and Android does it now, is by having the "owner" of the system publish libraries that implement these standard UI idioms.
In the Unix and command-line world this has mostly been the province of GNU, which published the widely (but sadly, still not universally) used getopt_long, which was a big step forward for usability by imposing some level of uniformity on at least the syntax level of command-line args; more universal adoption of them would be great. There's still a problem of word choice and abbreviation choice, which hasn't yet been standardized across commands (quick, which of these recurses onto subdirectories! grep -R, grep -r, sed -r, cp -r, cp -R, less -r, less -R)
- EdiX 10y agogrep -R, grep -r, cp -r and cp -R all recurse into subdirectories. Sed and less don't because what would that even mean?
- azernik 10y agosed and less can both look at multiple files (sed with --in-place, and less always). sed -r is extended regexp (as opposed to -E in grep - why? who knows), less -r is to disable control character filtering, and less -R is to disable control character filtering for color codes only.