Re: use-cases promote thinking of limited application

[L A Walsh]

On 2021/08/22 19:14, Koichi Murase wrote:
> I'd guess Ilkka has asked the use case for this particular output
> format, i.e., the quoted fields inside a single word.  If the purpose
> is organizing the data, I would naturally expect the result in the
> following more useful format in separate words without quoting:
>
> <adsf>
> <456 789>
> <foo bar>
> <123 456>
>   
----
   Exactly -- "you" would expect that "some other format" would
better meet the specific use-case - which is often used as a reason
to not implement the specific feature.

   Example (with a different util): with 'ls', I wanted it to
list the filename and  file-size (in bytes or scaled with a binary
prefix) in a multi-column format similar to "ls -s" (except that
"ls -s" shows the 'allocated size' not the actual file size. 

   To get bytes I tried "--block-size=1" and found it ignored the
user-specified block-size.  I asked for ls to be "upgraded"(fixed) to use
the block-size. (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49994).
However, they wanted to know my "use-case" and I was informed that
my use-case (of having ls list name+size) was "too rare" to justify
fixing the problem.  Oi!


>   
> > Anyway, in my experience, asking 'why' or for 'use-cases' seems more often
> > a way to rule out or determine relative importance, but is almost always
> > an inaccurate way to do so.
> >     
>
> I think it is still valid to ask the known/existing use cases when
> someone doesn't know the existing use cases, which doesn't rule out
> the other use cases.  In particular, I think Ilkka has asked about the
> intended use case, i.e., the original motivation of adding this
> feature in Bash 5.1.  It doesn't rule out other usages.
>   
Perhaps not, but it often rules out a need to address a specific
use-case until others run into similar or more onerous examples
of the problem.