All of lore.kernel.org
 help / color / mirror / Atom feed
From: "DJ Chase" <u9000@posteo.mx>
To: "Alejandro Colomar" <alx.manpages@gmail.com>,
	"Ingo Schwarze" <schwarze@usta.de>
Cc: <g.branden.robinson@gmail.com>, <linux-man@vger.kernel.org>,
	<groff@gnu.org>
Subject: Re: Standardize roff (was: *roff `\~` support)
Date: Sun, 14 Aug 2022 19:43:51 +0000	[thread overview]
Message-ID: <CM60BZSRVXB6.19YICCPQBUCTD@grinningface> (raw)
In-Reply-To: <738eadd5-5495-d848-ef08-544e97fc1452@gmail.com>

On Sun Aug 14, 2022 at 12:32 PM EDT, Alejandro Colomar wrote:
> On 8/14/22 16:49, DJ Chase wrote:
> > On Sun Aug 14, 2022 at 9:56 AM EDT, Ingo Schwarze wrote:
> >> You appear to massively overrate the importance end-users
> >> typically attribute to standardization.
> > 
> > That’s probably because *I* massively overrate the importance of
> > standardization (I mean I literally carry a standards binder with me).
> > Still, though, it’s rather annoying that end users — especially
> > programmers — don’t value standards as much.
>
> (Official) standardization isn't necessarily a good thing.  With C, it 
> was originally good, in the times of ISO C89.  Now, it's doing more 
> damage to the language and current implementations than any good (it's 
> still doing some good, but a lot of bad).
>
> [Snipped because I’m not going to quote the whole email — see previous
> message for argument]
>
> I think it's better to let natural selection to work out its way.  If a 
> feature is good, other implementations will pick it, and maybe even 
> improve it.  If a feature is not good (or it's not needed by other 
> systems), it will not be portable.

True; prescriptive standards can certainly make some things worse. As a
further example, ISO 8601 sucks. I mean, its core specification is
great, but there are so many different ways that are allowed that the
full standard is almost completely unparseable. It also uses a slash
between the start and end times of a period instead of something
sensible, like, I don’t know, an en-dash! Which means that periods can
be written with a slash (because that’s the standard) but also with an
en-dash (because that’s how ranges work in English), but also that one
can’t properly write a period in a file name or URI.

Still, though, I think descriptive standards can be net-positive. The
POSIX shell utilities comes to mind. Sure, they certainly have some
issues, but because it’s a trailing standard, implementers are free to
fix them.

Do you think that a descriptive/trailing standard could be beneficial
or would you still say that it could mostly hinder *roff
implementations?

Cheers,
-- 
DJ Chase
They, Them, Theirs

  reply	other threads:[~2022-08-14 19:43 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-29 11:45 [PATCH 4/6] xattr.7: wfix Štěpán Němec
2022-07-29 20:58 ` G. Branden Robinson
2022-07-30 14:15   ` Štěpán Němec
2022-07-30 17:53     ` Alejandro Colomar (man-pages)
2022-07-30 17:59       ` Alejandro Colomar (man-pages)
2022-08-01 13:28       ` Alejandro Colomar
2022-08-11 12:48         ` Ingo Schwarze
2022-08-11 20:17           ` G. Branden Robinson
2022-08-12 14:30             ` Ingo Schwarze
2022-08-12 22:10               ` *roff `\~` support (was: [PATCH 4/6] xattr.7: wfix) G. Branden Robinson
2022-08-13  4:23                 ` G. Branden Robinson
2022-08-14 14:15                   ` Ingo Schwarze
2022-08-14 22:21                     ` G. Branden Robinson
2022-08-13 17:27                 ` DJ Chase
2022-08-14 13:56                   ` Standardize roff (was: *roff `\~` support) Ingo Schwarze
2022-08-14 14:49                     ` DJ Chase
2022-08-14 16:32                       ` Alejandro Colomar
2022-08-14 19:43                         ` DJ Chase [this message]
2022-08-15 11:59                           ` Alejandro Colomar
2022-08-16 11:48                             ` Ingo Schwarze
2022-08-14 22:35                       ` G. Branden Robinson
2022-08-14 22:58                         ` DJ Chase
2022-08-15  0:20                     ` Sam Varshavchik
2022-08-16 12:52                       ` Standardize roff Ingo Schwarze
2022-08-16 23:46                         ` Sam Varshavchik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CM60BZSRVXB6.19YICCPQBUCTD@grinningface \
    --to=u9000@posteo.mx \
    --cc=alx.manpages@gmail.com \
    --cc=g.branden.robinson@gmail.com \
    --cc=groff@gnu.org \
    --cc=linux-man@vger.kernel.org \
    --cc=schwarze@usta.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.