4 ms·

For command line utilities I'll take correctness over usability any day.

• fosco 10y ago
  Agreed, this is great engineering and design. As expected, it does exactly what you tell it to.
• raverbashing 10y ago
  You're right, correctness is important. And also wrong by thinking usability gets in the way of correctness Usability helps with being correct Vast majority of uses of cal apply to dates > 1900 (and I'd say a significant amount is > 2000) 'cal 16' should require a flag saying "Yes, I know what I'm doing, this is the actual year" and/or print the corresponding year for this century (being explicit, when printing, to which year it refers to)
  • gkya 10y ago
    > Vast majority of uses of cal apply to dates > 1900 (and I'd say a significant amount is > 2000) According to what? Your use? > 'cal 16' should require a flag saying "Yes, I know what I'm doing, this is the actual year" and/or print the corresponding year for this century (being explicit, when printing, to which year it refers to) The command wants a year number as input. '16 is an ambiguous abbreviation that gains meaning only within context. As the command can't ask you what you meant, the default behaviour is sane.
    • d0mine 10y ago
      Yes, 'cal 16' is ambiguous (is it 0016, 1916, 2016? Different software may return different answers). Without an explicit flag that should be used in a script, the dwim behavior (2016) seems more appropriate for the interactive use.
      • gkya 10y ago
        cal 16 unambiguously refers to 16 a.d. Don't forget that we include an apostrophe before a shortened year.
    • raverbashing 10y ago
      > According to what? Your use? Do you know anyone or any use case that requires calculations of years between 0-99 and uses cal? Yes, it is quite obvious that most uses is for years > 1900, you're free to do a study yourself if that's what you want. > As the command can't ask you what you meant, the default behaviour is sane. Not from an usability point of view.
    • deleted 10y ago
      [deleted]